Enough with the JavaScript already

http://fr.slideshare.net/nzakas/enough-withthejavascriptalready

by gulbrandr • 13 years ago

402 218 13 years ago

fr.slideshare.net

siddboots• 13 years ago

Slide 19 seems broken for me.

I remember from last time someone posted this that slide 19 was like slide 18 but with all of the features over in the JS box. In this version, both slides are identical.

lukifer• 13 years ago

Though I would like to see the talk in its fullness, and I am a full-on Javascript fanboy, I have to agree with the core thesis. In 99% of cases, there's no reason to do all rendering client-side, especially on content-centric sites. And devs do sometimes get too dependent on kitchen-sink libraries, rather than rolling their own native JS to address their own specific need.

dreen2• 13 years ago

Why store state in DOM? Isn't that bad practice?

I remember reading DOM access is the slowest part of JS [needs verification]. So you want to trade performance for few dozen kilobytes of assets that can be cached?

lewispollard• 13 years ago

Because then you can create a fallback if Javascript isn't enabled - use a server side language to manipulate the DOM on page load to give the same state as if the Javascript were there

bad_user• 13 years ago

I'm not exactly sure what you're talking about, however mobile phones have awful bandwidth and awful browsers with not enough memory to cache everything they can.

In the context of websites, you also want the experience of new users to be the best it can be.

Basically, caching is nice, but it only works efficiently for applications that users visit often and that don't rely on links going viral, such as GMail. However, if you rely on caching for providing an acceptable user experience in cases where you rely on links going viral (such as Twitter), then you're screwed. Twitter has a mobile optimized web page that's much, much lighter than their desktop version and they did it for a good reason ;-)

dreen2• 13 years ago

Let me rephrase then; storing state in DOM may be ok for small pages with some insignificant JS on top to provide progressive enhancement, but from web app point of view its totally unfeasible and saving a few KB is IMHO not worth it.

bzbarsky• 13 years ago

DOM access is the slowest part of JS in the same way that Window API access is the slowest part of a C++ app on Windows.

"DOM access" covers everything from "WebGL calls" to "stroke a path in canvas" to "hey, redo the layout of the whole page" to "hey, store this string in a database" to "add an attribute to this element", depending on who you're talking to. Some of these are slow (redoing the layout of the whole page). Some are not too bad (e.g. in a current Firefox on Mac typical WebGl calls are about 2x slower than a corresponding GL call from a C program last I measured).

Now obviously storing data in a DOM attribute is slower than storing it in a JS property, because there is more overhead: DOM attributes can dispatch mutation notifications, can affect styling, etc. If you don't need any of those things, you might be paying some cost that you don't need to pay. This typically starts to matter once you're doing a _lot_ of attribute sets, though. A typical attribute set in a modern browser is in the <100ns range on modern laptop hardware.

Gravityloss• 13 years ago

Who's the superman?

cliveowen• 13 years ago

I wonder if there'll ever be an alternative to Javascript. I'm not talking about those things that eventually get translated to Javascript, I'm talking about a native platform well thought-through and based on a typed language that isn't a mess. Yeah, I know: it's not Javascript that's broken, it's the DOM. I'd argue that both should be replaced by something else, otherwise the future will be 90% native mobile apps, which isn't a bad prospect if you can afford to develop and iterate for two different leading platforms.

AndrewDucker• 13 years ago

Absolutely. Write in whatever language you like, compile to asm.js - that way you're running in the browser, at about half native speed.

Toenex• 13 years ago

__at about half native speed.__

Which may well the right trade off for many apps.

PommeDeTerre• 13 years ago

Asm.js is not an alternative to JavaScript, though. It is JavaScript, just a really mangled and ugly subset of it.

cliveowen was clearly talking about "an alternative to Javascript" and "not [...] those things that eventually get translated to Javascript". Anything targeting Asm.js is merely targeting JavaScript.

The "half native speed" claim is quite dubious, at best. Even if it were realistic, that's still quite a horrible decrease in performance relative to native code. It's not as bad as the typically much worse disparity, but it's still not good at all.

discreteevent• 13 years ago

"Write in whatever language you want" - For languages that need a VM (most garbage collected languages for example) you would need to port the VM to asm.js. That's a job in itself. Then when a user hits your site they would need to upload all the asm.js for the VM at least the first time (think about that on a sketchy mobile connection). On top of that the performance of C++ to asm.js is about half native. The performance of e.g. a ruby interpreter running in a VM that was ported to asm.js could be a long way off native. The performance of e.g. Ruby might be acceptable on a server where you can throw more horsepower at it. But on a client? Client code is the most performance critical there is. The user expects instant feedback when they swype. Even if there was a native Ruby VM (for example) on the client it still might not meet your performance requirements not to mind one that runs in asm.js. It was the movement back to the server side with web programming that enabled the diversity of language use in the 90s. On the client the same old restrictions apply i.e. we would need something to make those VM's faster than their native versions, not slower.

chongli• 13 years ago

Asm.js is a non-starter for most of the high-level languages out there due to its lack of GC.

exizt88• 13 years ago

What's wrong with the DOM? (Sorry if this is a stupid question)

camus4• 13 years ago

Nothing wrong. But i guess DOM manipulation can be painfull sometimes. But if you are going to develop a web app you'll have to use the dom.

ycitm• 13 years ago

Crockford has some very interesting things to say about it:

http://yuiblog.com/blog/2006/10/20/video-crockford-domtheory...

minopret• 13 years ago

What's wrong is what the DOM is and what it isn't. The DOM is the Document Object Model data structure along with the parametrized routines that operate on that data structure. It exposes every way in which the apparent simplicity of XML is far from the reality. Then the operations that it provides do little to manage the complexity. They are only relatively "primitive" operations, like getters and setters for the data structure, plus a few things like "getElementsByTagName". That gets a set of elements from which you then should or must exclude what you don't want. If you want a convenient wrapper for the DOM API, you have to find or build one.

electrotype• 13 years ago

Dart ( http://www.dartlang.org ) is a attempt by Google. Of course, probably no browser except Chrome (and Opera?) will ever have the Dart VM built-in, but Dart also compiles to javascript for those other browsers.

rartichoke2• 13 years ago

An issue with Dart is it does not support IE 8. IE 8 still ships with Windows 7 and it is quite popular.

It's not reasonable to throw away all IE 8 traffic just to get Dart's features.

weland2• 13 years ago

Objective-C is really nice. I don't like Apple, but their development tools are actually fairly good, and the whole API in iOS is, if not necessarily a beautiful piece of engineering (which is subjective), at least thoroughly-documented and easy enough to learn and use. Android is terribly documented and very messy to develop on.

But yeah, it sucks that you can't do cross-platform development unless you like to be tied to a web platforms, which tends to result in inferior user experience.

AndreasFrom• 13 years ago

http://www.xamarin.com compiles C# to native apps for Android, iOS and Windows Phone.

matwood2• 13 years ago

Your best bet on Android is to download the source and use that as your documentation.

w1ntermute• 13 years ago

Android is terribly documented and very messy to develop on.

I keep hearing this FUD, but I have no idea where it's coming from. I've never had any problems with the Android documentation. The most annoying part of Android development is probably Eclipse, but I'd rather have a resource intensive IDE that's cross platform than one that only runs on OS X.

In fact, the Android platform has some amazing opportunities for those who are willing to look past the mainstream views on it. Because it's ignored by so many companies/developers, all you have to do is pick an iOS app that is popular and clone it - you are pretty much guaranteed to get lots of users.

chii• 13 years ago

The mistake, perhaps, is that people (us) are trying to shoe horn an application into a Document object model - its in the name for christ sakes! Document! Not application object model!

Slackwise• 13 years ago

Not just the DOM, HTTP as well. We're shoehorning state into a stateless system, and inventing new crap like WebSockets to overcome limitations of a system designed for document retrieval. The web has turned into the biggest hack ever.

Zash• 13 years ago

This!

protonfish2• 13 years ago

Document = application interface. It's a great way to abstract the back end from the front end. Unless of course you mush your business logic in with your interface code.

xradionut2• 13 years ago

I develop applications that skip the browser(s) and HTML. But it's not totally cross platform. But then again I don't develop for Joe Public most of the time either....

youngtaff2• 13 years ago

Google were planning to do some interesting experiments with JS and the DOM - they're hinted at in the Blink announcements but can't remember seeing any more about them yet

flyinRyan2• 13 years ago

Yeah, I know: it's not Javascript that's broken, it's the DOM.

No, JavaScript itself is a ridiculous language. Every time I have to deal with it I grit my teeth. Right now I'm dealing with dates. Luckily JS has a built in Date class! Which, of course, does nearly nothing. If you call "getDay" you get a zero indexed number representing the day of the week. So since there's no formatting functions to print out dates, how do you get the month-day number? Oh, right, you call getDate...

If I didn't know better I would think this abomination were created by someone who thought the secret of PHP's success was being horribly defined.

dccoolgai2• 13 years ago

Try this: date.toLocaleDateString("en-US", {month: "numeric", day: "numeric"});

wasd• 13 years ago

Isn't this the objective of Dart?

weixiyen• 13 years ago

2013 - I stopped paying attention to every new framework or MV-whatever that comes out. What matters is the product and end user experience, and every single decision on how to go about making that product should be made with that thought in mind.

For me, it's not even javascript anymore. Objective-C and Java rule 2013 since web apps are not as pleasant to use on mobile.

nbevans4• 13 years ago

"Objective-C and Java rule 2013 since web apps are not as pleasant to use on mobile."

Or with some MVVM, Xamarin and some C# or F#... write once, compile for all mobile platforms. Never having to once touch the nastiness of Obj-C or Java.

coob• 13 years ago

What's nasty about Obj-C?

pjmlp3• 13 years ago

I rather use those 5 MB for my application.

oyvindeh• 13 years ago

For me, it's not even javascript anymore. Objective-C and Java rule 2013 since web apps are not as pleasant to use on mobile.

I think this is bad. Not because the technology isn't good, but because small companies (or idealistic organizations, or others with a small budget) will have to implement useful apps for several platforms. Perhaps they cannot afford it (or think it's too much hassle, or don't care).

E.g., say that there is a product made to make life easier for people with a certain disease. Perhaps some users will have to switch device in order to use it. And maybe there are other apps they need which are available only for their old device. (And don't forget that are other platforms than iOS and Android as well, including desktop.)

Web apps (either run on the web, or natively) solves this problem, even though I agree that JavaScript, with it's myriad of ways to shoot yourself in the foot, is not ideal.

Like another commenter pointed out, there are options for compiling to multiple platforms. But it often doesn't seem to happen that way, and perhaps it's not always possible or feasible.

16s• 13 years ago

All the includes are insane as well. Run Noscript or any other JS blocker and visit a few big sites and you'll see that you end up running JS from half the Internet.

I'm joking of course, but some sites have dozens of includes from other sites, advertisers, CDNs, etc.

non-sense• 13 years ago

Media sites are painful to visit with so many libraries and embedded widgets. Those pages load much faster after using Noscript to selectively load JS. Wish there was a built in repository where people could share whitelists.

Cthulhu_2• 13 years ago

I installed Ghostery but did not set up any filters; with just that, it shows how much external resources / from which external parties things are loaded. Some sites have like twenty external dependencies, and multiple analytics gathering scripts (which may get embedded via the iframes of advertisers).

chewxy4• 13 years ago

I work in advertising. I have seen Ghostery rack up close to 300 trackers before. Piggybacked pixels... they're everywhere

skeletonjelly• 13 years ago

TechCrunch is the worst I've seen. 13 for me. Any other higher ones?

krosaen2• 13 years ago

It's not really an either or thing. You can go too far with client side rendering. But progressive enhancement can only bring you so far in delivering an interactive experience - it's typical that his example is a simple tabs implementation - of course that's easy to do without much js.

That's why I like knockoutjs - it makes it easier to sprinkle in the data-bound rich interactive UI to the pieces of your page that need it and leave the rest as normal server side rendered content. It doesn't force you to go whole hog client side.

One key area of performance where js rendered UI helps a lot is in customizing an otherwise uniformly served (and cached) page. 95% of the page is uniform to everybody, so render that server side and cache the heck out of it (varnish or whatever). Then, bind the pieces of the UI after page load and customize them based on the user - their login status, their location, etc.

jhh• 13 years ago

have you actually done this? I was wondering if this is a feasible and good way to use knockout!

krosaen2• 13 years ago

yeah, a good description in passing in terms of using a framework as an "island of riches" here:

http://blog.stevensanderson.com/2012/08/01/rich-javascript-a...

we use this technique at food52.com, e.g this content page cached uniformly, login system, recipe saving widget, comment system all done in ko.

http://food52.com/recipes/22888-yotam-ottolenghi-sami-tamimi...

more interactive / sophisticated uses of ko coming in our new shop soon for the cart functionality.

joshuacc3• 13 years ago

Angular is also quite good about allowing you to enhance only parts of server-rendered pages.

jrochkind1• 13 years ago

Another presentation making similar conclusions, but with different arguments, that I recently saw on reddit (not sure if it made it to HN).

http://www.infoq.com/presentations/web-development-technique...

http://www.reddit.com/r/programming/comments/1eiykw/web_deve...

(back to me...)

I wonder if the pendulum is finally swinging back, to working with the affordances of the web, instead of fighting them. I hope so.

This might have an interesting relationship to the rise of mobile. It's still not possible to rival native apps with HTML apps on mobile (a controversial assertion, but one that is 'trending' too) -- so if you ARE building a web app, you've got to actually have reasons to prefer web apps. Even if that's just cost/speed of development. But if you've actually chosen to build a web app, maybe you're more likely to want to work within the web instead of fighting it. If you don't like the architecture of the web, you could have just written a native app instead.

ebbv3• 13 years ago

JavaScript is a tool. Once it becomes trendy idiots will always abuse a tool. It's not JavaScript's fault people are bad at web design and development. If it wasn't fucked up JavaScript these people were contacting you about it'd be something else, be glad you have a job.

chewxy4• 13 years ago

It does not however, preclude the possibility that the tool is in fact a bad tool, and that the tool is bizarrely the only tool we have.

They say poorly skilled people blame their tools, and that highly skilled people who know their tools well, will know how to use it well. That being said, see that circular saw over there that will occasionally bounce and cut off its user's fingers? I'm not gonna use it, no matter how skilled I am.

I for one am hoping for a replacement for JS (that isn't Dart, which feels like JS Patched). I have more than just a hairy experience with JS lately.

marknutter2• 13 years ago

People don't use javascript because it's a beautiful, well thought out language. They use it because it runs everywhere.

ebbv3• 13 years ago

Yeah JavaScript has problems, so do all programming languages. JS has some particularly egregious ones, but the abuses and problems the slide complains about are not a symptom of a defect with JavaScript. They would be the same problems with any other language being used by incompetents.

akdetrick• 13 years ago

I agree that it's a bad tool in many ways, but even if the language (and environments) were beautiful, the problem at hand is often the way that people use it.

In this case, a poor craftsman uses his tools to do the things that the browser already does for you.

I've seen some JS that reinvents lots of what the browser rendering engine should handle (recalculating & reflowing heights of elements every time something was added or subtracted from the DOM, for example). Expand this kind of thinking to an entire project, and you start to find yourself in the kind of mess described in the slides.

If/when Dart replaces JS, some of the enforced structure may help prevent badly organized or buggy code, but it won't fix poor assumptions of what concerns scripting should and should not handle.

nine_k• 13 years ago

Fortunately, JS is not the only tool we have. JS is a relatively fine compile target, and with asm.js, a pretty fast one.

So pick your favorite among CoffeeScript, TypeScript, Dart, GorillaScript, Elm, ClojureScript, etc, or try compiling your favorite language using LLVM.

Let a compiler take care of all the numerous rough edges raw JS has.

eagsalazar23• 13 years ago

Seriously your analogy is absurd. JS has a few rough edges that any decent editor will warn you about and that you automatically know to avoid after doing a lot of it for even a couple months.

This complaining that JS is unusable is just BS and whining by people who are simply shying away from something they don't know.

There are bigger things that can bite even experienced developers like memory leaks and bloat but that has little to do with JS since you can fall into those pitfalls in any language.

I'm not attached to JS and have pretty much switched to CoffeeScript. I like CS better but that doesn't mean JS is anywhere near as bad as you make it out to be.

munger• 13 years ago

I know you are just making a point with the circular saw metaphor, but for those wondering here is some good info on how to use a circular saw as safely as possible:

http://www.docstoc.com/docs/87338746/CIRCULAR-SAW-SAFETY-AND...

http://carpenterbooks.com/userFiles/556/frame_table_mw_pdf_2...

Even still, as the safety guide states, "Be careful, making one small mistake with a circular saw could be the last thing you ever do in your life"

roc• 13 years ago

But JS isn't just a tool. No programming language is.

JS is more a workshop that happens to contain, amongst its stations, a less-than-safe circular saw. And you can absolutely, productively use the shop without using the saw, or by using the saw, if necessary, with additional safety precautions.

And because some people use the saw willy-nilly, you're saying we should throw out the whole shop?

stiff• 13 years ago

We are all abusing the technologies originally developed for hypertext documents (HTTP, HTML, CSS, JavaScript) for building applications. If you today started working on a set of standards for handling what people currently build on the web proposing those technologies would be completely ridiculous, so ill suited are they for this job. And JavaScript is probably the worst of all, it is designed badly enough that there isn't even a standard way of defining modules or classes so you end up connecting shit structured in a 100 different ways.

xradionut2• 13 years ago

Amen!

The fact that it's still insanely easier to write desktop apps, using one or two languages and a layout manager vs. dealing with two decades of WTF! web programming makes me sad.

tracker13• 13 years ago

See CommonJS and/or AMD combined with a build tool Grunt...

You have component options around, mostly pretty new for building modular JS and building them for use in the browser as a single download. RequireJS in particular goes a long way towards helping with browser development. AMD lends itself more towards the browser, but there are build tools for CommonJS style modules as well.

If I were starting today, I'd probably have a reduced subset of what HTML is, with extension points for form inputs. The issue is that extensible/modular, skinnable and a centralized authority are points of contention for application building. I really liked Silverlight as a concept, I thought the package system was well thought out.

What I really didn't care as much for is how verbose XAML is. I can say most of the same about Flex+ActionScript. The problem is neither of these formats were open enough for browser vendors to simply have built-in support for them as a specification.

dsego• 13 years ago

I think the problem is that the original technologies were bad to begin with. And the development was ad hoc and without foresight. Just look at the history of the img tag (http://diveintohtml5.info/past.html). DOM was tacked on later, JS was developed in a couple of weeks, with Java-like syntax just bolted on for marketing purposes. And CSS is the worst. Why anyone considers cascading to be a feature is beyond me. I mean, what were they thinking, what was going through the person's head when they decided "yep, cascading, that's what we need, forget name spacing, variables or expressions, we need cascading". Oh boy.

tommorris• 13 years ago

Java is a tool too. But the years and years of people inflicting bad Java desktop UIs on the world might have been avoided if we had been more critical of it rather than going with what's cool and hip and new.

I think in a few years time, we'll look back on the current trend of client-side-all-the-things just as we now look back at Flash intro pages, pop-up ads and all that shit.

jgeerts3• 13 years ago

Nobody has ever liked the swing GUI's, everyone with a little bit of taste disliked it, were constantly looking to change their theme and it was really aweful for a developer to create a decent user interface with.

shubhamjain• 13 years ago

Not only idiots, it seems everyone is so obsessed with creating ajax navigation, rich controls, and one page apps. The one apt reason why I never open Google Plus is because every things takes years to load with their fucking javascript in everything.

Why can't sites be like StackOverflow, it only uses JS where necessary.

Domenic_S• 13 years ago

$LANGUAGE is a tool. Once it becomes trendy idiots will always abuse a tool. It's not $LANGUAGE's fault people are bad at web design and development. If it wasn't fucked up $LANGUAGE these people were contacting you about it'd be something else, be glad you have a job.

bradshaw1965• 13 years ago

The same comparisons were made when Flash was being misused. It doesn't take much to muddy an ecosystem. There were certainly other problems with Flash, but thinking that best practices for JS will filter through to most developers is unlikely.

bytelayer• 13 years ago

What I don't get is the sites that load ALL their content using JavaScript. Sure, I see the point in loading more content if the user scrolls down to the bottom of the page, but why would you do that straight away?

netmute• 13 years ago

Enough with the no-context-attached slides already.

Seriously, if you don't have a recording of the talk, or a transcript, at least provide an article or something.

marknutter2• 13 years ago

I will never understand the utility of posting slides from a talk online without the audio.

amorphid• 13 years ago

I found the slides to be quite informative.

jasonlotito• 13 years ago

It's useful for those that attended the talks. You generally don't need the audio, but just the highlights from the slides.

danneu• 13 years ago

One of the main reasons I come to HN is to learn how other people feel about certain things, predominantly from the comments section. Else it's just me in my cave.

It's obvious what point the slides were making.

The important part is that it said enough to inspire discussion and that it's qualified by its recency (posted last month) and by the experience of the person that gave the talk (front-end guy at Box).

larister• 13 years ago

Airbnb's Rendr seemed to be a nice solution to this problem

https://github.com/airbnb/rendr

joeblau• 13 years ago

I think the summary is more helpful than looking at the slides. Does anyone have a link to the video talk about this?

agentultra• 13 years ago

Javascript itself has warts and they are easily overcome. I've found that the biggest hurdle for me, someone who's written native desktop applications, are the libraries are a huge hurdle. I still don't understand the obsession with MV* "design patterns," in GUI code.

It's made worse by the fact that the model we have to base our GUIs off of is a based on hierarchal documents.

protonfish2• 13 years ago

Those bloated GUI libraries are part of the problem, in my opinion.

HTML is a great document definition language in the right hands but like JavaScript, its poor use can create a nightmare. You can fix this by learning to write clear and simple semantic HTML but if you have to work on legacy code that doesn't really help.

hrktb2• 13 years ago

Before "js everything", it wasn't just a plain simple pure web. It was flash and gifs and "dynamic html" that would break in half of the browsers, and you'd show a special version of your site saying "we're not paid enough to support your browser, go get another one".

Clients never were reasonnable in their demands, nor did most of the site owner have good and simple tastes and care about efficiency, nor did half of the internet care about user experience first above everything else.

Saying that the use of js has because heavy handed is cool and fun, but for any serious discussion there should be more acknowledgment of why we are in this situation in the first place. I'm not sure it's so much worse than 5 years before, at least we can read most things on mobile devices.

As a side point, I've done project on ultra weak platforms were every js had to be hand written to gain speed and memory space. I wouldn't try to do the same on some cookie cutter corporate site with a 600k slideshow loading on the front page, where having easily replacable components and tried and true pieces to test on the 20 combinations of browsers is far more critical that cutting 20k of compressed script.

ChuckMcM• 13 years ago

I think this is very true. When Java launched I re-did the Sun home page as an applet. Bill Joy suggested that in the future HTML would be gone and each web page would be its own Java applet. He was mistaken of course :-) But as I've watched the emergence of 99% js pages I am reminded of his insight. His reasoning was pretty straight forward, the reason PDF (and that thing Imagen/Xerox did (DDF?)) existed was that to convey the document creator's intent to the consumer over a fungible media like computers, required that the document be a program describing what it looked like, leaving it up to the end node to interpret that program and then do its best to recreate it for the end user. That was something ASCII could never do. So with web pages, especially interactive ones, they were destined to be "programs" rather an some form of semantic markup structure.

I have come to appreciate that this is a pretty profound concept (well for me anyway :-), having the end result sent as generalized instructions for reconstruction, rather than as a external representation of the constructed object.

jbooth• 13 years ago

It's funny, the whole java applet thing was actually a better solution than JS in a lot of ways (shipping compiled/compressed bytecode with a security manager), just way, way ahead of it's time, and with a terrible windowing/drawing toolkit that meant it would never be adopted.

_ap• 13 years ago

The first HTTP 1.1 implementation, CL-HTTP was written in ANSI Common Lisp.

Clients never were reasonnable in their demands, nor did most of the site owner have good and simple tastes and care about efficiency, nor did half of the internet care about user experience first above everything else.

My web browser today uses more memory than my computer had in 1996. The web isn't efficient today at all.

ohwp• 13 years ago

"at least we can read most things on mobile devices"

True but we don't need Javascript for it. I think that's what the article is about. We can make cool stuff without or with less Javascript.

ChikkaChiChi• 13 years ago

In every situation that you allow your engineers to develop for the technology instead of for their customers, this is going to occur.

Does the customer care that the latest MVVM JS tool is being used? Not unless your customers are only other developers. The customer cares about getting whatever widget you are selling them quickly and with as little thought as possible on their side to consume it.

DrinkWater• 13 years ago

To say it in the words of @fat: hi haters https://pbs.twimg.com/media/A_G3NghCIAEAGbM.jpg:large

d4vlx2• 13 years ago

To bad you have to pay $399 to watch the videos.

http://velocityconf.com/velocity2013/public/sv/q/479

I realize it costs money to run a conference but that seems excessive.

youngtaff2• 13 years ago

Here's the version from SF Web Perf - http://www.ustream.tv/channel/sf-web-performance-group-meetu...

d4vlx2• 13 years ago

Awesome, thanks.

Duhck2• 13 years ago

This slideshow lost all credibility when it said to put your analytics in the <head> tags. Sure some analytics providers might recommend you do that, but that is wrong and only serves to

A) Slow your site down B) Introduce a single point of failure into your webpage

All scripts should be loaded either async or at the end of the dom.

teamonkey• 13 years ago

If you load the analytics script anywhere other than the head, you potentially miss user input while the page is loading. For a slow-loading page, this could make you lose out on useful data. I realize that this argument is somewhat circular.

Duhck2• 13 years ago

You should avoid including script tags in the head because it introduces single points of failure in your app. Losing a few ms of 'analytics' time is better than providing your users with a broken site because your analytics scripts (or any other hosted JS files) didn't load and waited 5-15s to timeout (depends on browser).

Steve Souders gives a great talk on this: http://www.stevesouders.com/blog/2010/06/01/frontend-spof/

hvs• 13 years ago

Amusing, this article was submitted 2 weeks ago and got no comments.

https://news.ycombinator.com/item?id=5973914

ExpiredLink• 13 years ago

Bad timing?

aaronsnow• 13 years ago

This deck is really hard to flip through on an iPhone. Nothing a little JavaScript couldn't fix.

quacker2• 13 years ago

I've often thought touchscreen devices would be complemented well by a set of arrow keys. (On a desktop, you can flip through the slides with the left and right arrow keys.)

ghostdiver2• 13 years ago

I see one problem:

- Entire generation of programmers may not have any knowledge about how computer works

kenster073• 13 years ago

No?

If that were to happen, it would be a problem with the programmers more than anyone else.

ghostdiver2• 13 years ago

with JavaScript, there is no need to know how computer works, so why would anyone learn(deeply) about that?

gnaritas• 13 years ago

That's not a problem, it's an opportunity for those that do, and there will always be those that do.

steveklabnik2• 13 years ago

I don't know if I should laugh or cry: I had to temporarily disable NoScript for both slideshare.net and slidesharecdn.net to read these slides.

stephengillie• 13 years ago

Is it ironic that this slideshow complains about Javascript but requires it to be viewed?

sequoia• 13 years ago

no, it's not

GnwbZHiU3• 13 years ago

this slideshow doesn't complain about JS, it's giving you suggestions on how to use it well.

pcole• 13 years ago

If I had time to get something up and running where the html could be rendered on both client and server using the same code base in the early stages of a project then I would.

It all depends on the project of course but currently here is the order in which I tend to do things:

1 Write an api

2 Write web/mobile apps to consume it

3 Optimize by pre-rendering the html when needed if the project becomes popular enough or if it really needs to be crawled.

as_if2• 13 years ago

Funny thing is, I use JavaScript libs like Ext JS because they don't impose HTML/CSS on me.

I can write the whole application in JavaScript and I just have to mess with the DOM and it's ugly friends when in trouble.

camus4• 13 years ago

doesnt matter , they use it under the hood. and the fact that you have little control over how ExtJs actually uses the DOM will not make your app faster...

as_if2• 13 years ago

That's a two-edged sword.

If I rely on an API, which abstracts everything, I benefit of every performance improvements they make "under the hood".

If they are better with performance than me, I win. If I'm better with performance than them, I lose.

kenster073• 13 years ago

One can do a great many things with disciplined Javascript, and I shudder to think what Twitter was trying to do on their front-end that caused a 5x increase in load time compared to server-side template-rendering.

That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice versa.

gavanwoolery• 13 years ago

I agree - but moreover, I'd like to see a single, cohesive replacement for the whole web stack. One standardized language to handle styling, scripting, server-side, and the document (in fact, let's just get rid of the notion of a document - we are building dynamic applications now, not documents). I understand that one reason we have separate languages is in light of security, but I think this could be made even better with special permissions (like unix file permissions but for code functionality/access).

GeneralMayhem• 13 years ago

Client- and server-side code is separated in literally every application to use a network, because they must necessarily be run on different computers. In most applications they can be the same language (C, C++, Java, etc.), but they have to be separate programs. I think what you're mostly complaining about is the JS lock-in on the browser side, which is a legitimate complaint, but a different one.

re:HTML - What's the difference between a dynamic document and a dynamic application, really? With JS and CSS3, HTML is unrecognizable - pair it with something like Backbone.Marionette, and the only thing HTML is doing is defining your display in a structured way, more like the XML definitions of an Android view than an old-school document.

steveklabnik2• 13 years ago

You should check out ASM.js. It might not strictly be necessary to get a new universal language. It's a really interesting project.

breckinloggins• 13 years ago

That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice versa.

Possible steps in that direction:

- Google Native Client: run native code in a sandbox [1]

- asm.js: A strict subset of JavaScript that can be optimized to native or near-native speed [2]

I much prefer the asm.js approach. I agree that there's a need for NaCl, but if we look at the browser as a sandboxed virtual machine that everyone has, we should all agree on a bytecode specification for that virtual machine. We pick JavaScript "because it is there". Once all browsers speak native asm.js, then you can compile your client-side code in whatever language you want, even C/C++ (see Emscripten for example). [3][4]

[1] https://developers.google.com/native-client/

[2] https://blog.mozilla.org/mbest/2013/06/25/asm-js-its-really-...

[3] https://github.com/kripken/emscripten

[4] http://games.slashdot.org/story/13/03/28/2113234/emscripten-...

gsnedders2• 13 years ago

Basically, what Twitter did was load a bare wireframe that loaded JS, and then that made a request to the server to get the content. If you cut out the second request, you've instantly saved the latency before that second request is even made, as well as the extra roundtrip time.

wereHamster• 13 years ago

Store state in the DOM? Really?

joshuacc3• 13 years ago

For the sort of small-scale interactions Zakas was talking about, that's a perfectly reasonable thing to do.

lnemeth• 13 years ago

Very nice, but unfornately, it seems we lost a lot of information from just watching slides...

gokulk• 13 years ago

If you use it in the right way, there would be no problems.

andrenotgiant2• 13 years ago

Many sites already use Google's hosted javascript libraries for JQuery, Prototype, etc...

Could Google reduce load time in Chrome by building these into the browser, so that anytime they see the include pointing to Google CDN, they just skip it and let the pre-included library take its place?

tannerc• 13 years ago

Great idea, why limit it to just Chrome? Of course, implementing something like this would require a number of additional updates.

And this still doesn't directly address the issue due to custom, large scripts for site-specific functionality.

carlosdp• 13 years ago

This shouldn't be necessary. Google's CDN (afaik) sets proper cache headers so that the first time you download a specific version of a library, your browser should cache it until it expires. (correct me if I am wrong)

joshuak• 13 years ago

I like this in principle. I think it should be abstracted out to a simple package system or something though. When you go to a sight that requires JQuery, your browser checks the sha256 hash or something against it's canonical list of published packages. If one is available it installs that one, or uses the one already installed. If the sha hash doesn't match it goes ahead and downloads the one from the site.

However, is transfer time really the biggest issue here?

tnuc• 13 years ago

The number and versions of these libraries is just immense.

A lot of what the early versions of these libraries used to do is now handled by upgraded versions of javascript.

Adding JQuery etc. to the browser is a short term fix, that would become a problem further down the track.

andrenotgiant2• 13 years ago

I agree about the short term fix thing.

What I meant was, "_Would_ it actually save any time to do this." not "They should do it."

I am curious if there would be any speed gains, not just in data transfer but in javascript initialization and execution.

Also, it would be an interesting "aspirational algorithm" if they only did this for the best/latest versions of these libraries, encouraging developers to stay up-to-date.

olalonde• 13 years ago

A non negligible downside is that it would give some libraries an "unfair advantage" which might harm innovation.

cromwellian• 13 years ago

On many sites, the (cached) load of 500k of gzipped JS is dwarfed by the amount of HTML, CSS, and images loaded.

tracker13• 13 years ago

A few points of contention... First, it doesn't seem like TFA is opposed to JS, as the linkbait title would seem, but the overhead of some sites/libraries.

I think that jQuery is probably a bit larger than it may need to be. Most of this is to work around edge cases or missing features in supported browsers. I think that the biggest issue may well be cost(s), and trust. It would be entirely possible to have a jQuery-like framework that would bring in only those shims as needed as part of loading from a central source. Unfortunately, that has costs in terms of both maintenance as well as deployment/cdn. It's probably not worth it.

Second, you are getting a lot of unused features with most frameworks (like jQuery), however this can be mitigated by using a common CDN, where caching helps a lot. Using the google, or ms cdn for jquery is a no brainer for a public facing application. I think that jQuery is too useful to just be replaced with one-off components.

As to jQueryUI, when you compare what it does with other toolkits, it's actually very impressive. Just look at the load size for the JS for Bootstrap for example... and bootstrap doesn't do all that jQueryUI does.

More and more frameworks have checkbox build options to give more fine grained builds specific to your needs with less overhead. Also, as pointed out in a few slides, you can load certain scripts and features as an on demand or post-load approach.

For example ALL my scripts tend to be at the bottom before the closing body tag (unless it's a single page application). Even then, the analytic scripts are last... imho the page being served to the user is the most important thing... it should be mostly functional without JS. And in terms of scripts, in the larger sense analytics are pretty low pecking order... when you have 10k users an hour, missing 2-3 analytics loads is no big deal.

metaphorm• 13 years ago

I'm really perplexed by one of the central complaints in this slide deck. JS load time is just not a serious problem in my experience. The use of CDN's and the browser cache has made loading scripts almost irrelevant in terms of page performance. Its a problem for first time visitors who have a cold cache. And then it amounts to adding an additional 1-2 seconds of load time once and only once on their first visit. I really don't get bent out of shape by that. I'd be worried if that 1-2 second overhead was incurred with every single page load with every single user. that's just now what happens though.

speedyrev• 13 years ago

OK, who clicked through all 84 slides?

chestnut-tree• 13 years ago

There is a place for Javascript, but it feels like it's being excessively overused.

Anyone who browses with Javascript disabled (using, for example, the noscript browser add-on) will be aware how many sites, even those with mostly text content, fail to load without Javascipt.

Google's blogger/blogspot service is one of the worst offenders. Here's an example: the official Android blog from Google. The page simply won't load with Javascript disabled. Once it is enabled, you have a page of mostly text. This is simply bad web practice in my opinion.

http://officialandroid.blogspot.co.uk/

umsm• 13 years ago

I love how the tech community promotes something until it's over used and only AFTER everything breaks then we THINK about how / when we can use a technology...

rhokstar• 13 years ago

The reality is... JavaScript is here to stay. So stop your complaining, that's such as waste of time. Rather than complain, champion better solutions. Be bold and advance a new and more efficient agenda.

Arnor• 13 years ago

Bird gotta fly, fish gotta swim, hater gotta hate. I love JS!

adambom• 13 years ago

Did anyone else think this was pedantic?

gwu78• 13 years ago

JavaScript assumes a "web browser". What happens when we're not using a "web browser"?

A few days ago, I was actually downvoted for even suggesting that a user could disable JavaScript and that this might reduce her vulnerability to exploits. I'm always fascinated by the strength of the bias in favor of JavaScript.

I'm guessing that so many developers are now so heavily invested in JavaScript that if it were to become less popular they believe they would suffer somehow. They will thus defend this language with fervor. That's my guess.

Days ago we saw Dan Bricklin, who is no stranger to a world without a web browser and is responsible for the app that literally launched the PC into the mainstream, put in his plug for JavaScript. But we also learned he's written entire spreadhseet applications in JavaScript. It appears he's heavily invested in this language. It stands to reason he would defend its use.

On this thread someone mentioned that Bill Joy thought Java applets would power the web. Not surprising considering his company was responsible for Java, and he has called James Gosling, the father of Java, his favorite programmer.

I think when we look at JavaScript we need to ask ourselves who stands to gain the most from it. My belief is that it benefits developers more than users. It's aesthetically pleasing to most developers, but more importantly, programming in JavaScript requires less work than using a language with manual memory management that does not expect to be run inside another application (a "web browser"). JavaScript boosts productivity.

Users, I believe, do not see the same benefits. (e.g. I have seen Marissa Mayer while at Google state how important speed is to users. We might accept that speed is one benefit that users would recognize.)

Because the love for .js is so strong and criticism of it is not well received, I won't go into any more detail. But suffice it to say, if there are problems with using JavaScript, I believe it is not developers who would suffer the most from them. I believe it is users who would bear the burden.

camus4• 13 years ago

Well , now that developpers can do crazy stuffs with javascript they will never use it responsibly and will show every trick they know to the user, because they want or because their clients want it.

I remember the time when 100ko pages were considered too heavy. now devs dont even bother optimizing images and use 500 ko png logos...

It's not unusually today to see 2MO homepages ...

coldnebo• 13 years ago

There is a very important reason client-side js apps are appearing: managing stateful apps over a stateless protocol means spending about half of your time and complexity budget dealing with state transfer. Js clients bring us back to the days of true application programming. They use REST and HATEOAS in a very natural way that most app servers have not. Maybe it's time to let the server side handle what it's good at?

GnwbZHiU3• 13 years ago

A lot of JS usage on web browser is as a tool to manipulate DOM. A bigger part of the problem, I think, is the DOM API. Another big part of the problem is of course inconsistencies between browsers. Because of those 2 problems, our client-side code becomes complex. Changing JS with "$LANGUAGE_X" wouldn't help much. If the DOM API is much better and web browsers behave the same way, things would be much different.

matteodepalo• 13 years ago

Just because it's badly abused doesn't mean it's bad per se. Let's say you build your SOA: JSON API + Mobile App. At this point, if you plan to build a web app to browse your content, it's very hard to render pages server side without code duplication/collision with the API. If you go with the full js MVC approach you can reuse your api and just worry about the templating and event binding. Maybe this approach doesn't yet scale to the size of Twitter, but I hope the web moves towards fat clients optimization.

duylamnguyenngo• 13 years ago

I don't always read Hackernews, but when I do I read it with this - http://nojs.herokuapp.com

priyadarshy• 13 years ago

its flat design, or should I say no design. prettier than hn

yawaramin• 13 years ago

Ironically, slides are hosted on a JS implementation of presentation software.

Enough with the JavaScript already

Related Stories