17 ms·

Enough with the JavaScript already

402 points by gulbrandr 13y ago

deleted 13y ago
[deleted]
- saurik 13y ago
  This was clearly a talk you were supposed to watch, not attempt to read the slide deck through later. Many of my talks are like that, and to avoid people complaining online "your slides suck" even though the people at the talk usually were in agreement that "that was an amazing talk", I always go out of my way to use presentation technologies that are as random and esoteric as possible to make certain that when I am asked "can we have a copy of your slides" the answer is "I guess, but it will be really hard and of no use to you".
- camus 13y ago
  Nicholas Zakas is a famous JS dev that worked at Yahoo. And the slides have nothing to do with a rant against JS , if it is why you hate them.That's the context.
- ExpiredLink 13y ago
  Martin Fowler refuses to publish the slides of his talks because they only make sense in the context of his talks. Seems to be a good decision.
siddboots 13y 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 13y 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.
dreen 13y 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 13y 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 13y 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 ;-)
  - dreen 13y 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 13y 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 13y ago
Who's the superman?
cliveowen 13y 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.
- electrotype 13y ago
  Dart ( http://www.dartlang.org 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.
  - rartichoke 13y 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.
    - Cthulhu_ 13y ago
      Does Dart support Chrome version 2 [0] or Firefox 3.0.8[1]? Since IE8 stems from that age, March 2009[2] [0] https://en.wikipedia.org/wiki/Google_Chrome#Release_history https://en.wikipedia.org/wiki/Google_Chrome#Release_history [1] http://en.wikipedia.org/wiki/Firefox_release_history http://en.wikipedia.org/wiki/Firefox_release_history [2] http://en.wikipedia.org/wiki/Internet_Explorer_8 http://en.wikipedia.org/wiki/Internet_Explorer_8 It's not reasonable to support an outdated browser version with an inferior Javascript engine, or to single out Internet Explorer as a browser for which older versions should still be supported, imho. (disclaimer: I'm building a webapp that has to work in IE 8)
      - rartichoke 13y ago
weixiyen 13y 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.
- nbevans 13y 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 13y ago
    What's nasty about Obj-C?
    - stefantalpalaru 13y ago
      The syntax and the APIs.
      - tres 13y ago
        I understand that the Smalltalk like syntax of Objective C can be difficult to understand at first glance; however, once you've worked with it a bit, the syntax becomes quite expressive -- each argument is labeled; something like using named arguments in Ruby, but it's not optional. Not sure what you mean about the APIs being nasty. Can you elucidate?
        stefantalpalaru 13y ago
        https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html#//apple_ref/occ/instm/NSString/localizedCaseInsensitiveCompare https://developer.apple.com/library/mac/#documentation/Cocoa...:
16s 13y 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 13y 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_ 13y 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).
  - chewxy 13y ago
    I work in advertising. I have seen Ghostery rack up close to 300 trackers before. Piggybacked pixels... they're everywhere
    - hobs 13y ago
      How does one even collect the data from 300 trackers?
      - WiseWeasel 13y ago
        Your 300 affiliate marketing partners run software from their affiliate network which automatically analyzes their tracking pixel server logs to determine how far the traffic they steered made it through your purchase process based on the pixels they requested (unique for each page) and the unique ID in their cookies. Then, their affiliate network collects the sales commissions and pays out the affiliate partners.
krosaen 13y 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.
- deleted 13y ago
  [deleted]
- jhh 13y ago
  have you actually done this? I was wondering if this is a feasible and good way to use knockout!
  - krosaen 13y 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-applications-the-seven-frameworks-throne-of-js-2012/ 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-s-basic-hummus 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.
- joshuacc 13y ago
  Angular is also quite good about allowing you to enhance only parts of server-rendered pages.
jrochkind1 13y 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-techniques http://www.infoq.com/presentations/web-development-technique... http://www.reddit.com/r/programming/comments/1eiykw/web_development_youre_doing_it_wrong/ 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.
ebbv 13y 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.
- chewxy 13y 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.
  - marknutter 13y ago
    People don't use javascript because it's a beautiful, well thought out language. They use it because it runs everywhere.
    - chewxy 13y ago
      Here's the painful part: Douglas Crockford wrote a book called Javascript, the Good Parts. If Javascript were limited to The Good Parts alone, it has the potential to be a beautiful well thought out language. It would be quite close to a beautiful well thought out language
      - city41 13y ago
        What's stopping you from only using the "good parts" in your own code? How is JS a bad tool? It runs reasonably fast, works everywhere, is a small, simple language that's surprisingly powerful. What if Eich had been influenced by C instead of Lisp when creating JS? All things considered, it could have been way worse than it is, and the truth is JavaScript lets you get in there and do good stuff. Not sure why we are still hating on this environment.
deleted 13y ago
[deleted]
bytelayer 13y 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 13y 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.
- marknutter 13y ago
  I will never understand the utility of posting slides from a talk online without the audio.
  - amorphid 13y ago
    I found the slides to be quite informative.
    - acjohnson55 13y ago
      I agree, but I definitely see the grandparent's point. These slide decks are annoying as hell. They're inconvenient for quoting, reading on-the-go, and they can leave out a whole lot of context. This is a trend that really needs to go.
  - jasonlotito 13y 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 13y 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 13y ago
Airbnb's Rendr seemed to be a nice solution to this problem https://github.com/airbnb/rendr https://github.com/airbnb/rendr
joeblau 13y 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 13y 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.
- protonfish 13y 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.
hrktb 13y 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 13y 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 13y 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.
ChikkaChiChi 13y 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 13y ago
To say it in the words of @fat: hi haters https://pbs.twimg.com/media/A_G3NghCIAEAGbM.jpg:large https://pbs.twimg.com/media/A_G3NghCIAEAGbM.jpg:large
deleted 13y ago
[deleted]
d4vlx 13y ago
To bad you have to pay $399 to watch the videos. http://velocityconf.com/velocity2013/public/sv/q/479 http://velocityconf.com/velocity2013/public/sv/q/479 I realize it costs money to run a conference but that seems excessive.
- youngtaff 13y ago
  Here's the version from SF Web Perf - http://www.ustream.tv/channel/sf-web-performance-group-meetup http://www.ustream.tv/channel/sf-web-performance-group-meetu...
  - d4vlx 13y ago
    Awesome, thanks.
ghostdiver 13y ago
I see one problem: - Entire generation of programmers may not have any knowledge about how computer works
- kenster07 13y ago
  No? If that were to happen, it would be a problem with the programmers more than anyone else.
  - ghostdiver 13y ago
    with JavaScript, there is no need to know how computer works, so why would anyone learn(deeply) about that?
    - kenster07 13y ago
      You act as though Javascript will take over the programming world -- I can confidently say that it won't
      - camus 13y ago
        mind you it will ... ( and i'm not pro javascript ).
- gnaritas 13y ago
  That's not a problem, it's an opportunity for those that do, and there will always be those that do.
Duhck 13y 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 13y 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.
  - Duhck 13y 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/ http://www.stevesouders.com/blog/2010/06/01/frontend-spof/
hvs 13y ago
Amusing, this article was submitted 2 weeks ago and got no comments. https://news.ycombinator.com/item?id=5973914 https://news.ycombinator.com/item?id=5973914
- ExpiredLink 13y ago
  Bad timing?
metaphorm 13y 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.
aaronsnow 13y ago
This deck is really hard to flip through on an iPhone. Nothing a little JavaScript couldn't fix.
- quacker 13y 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.)
steveklabnik 13y 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 13y ago
  Is it ironic that this slideshow complains about Javascript but requires it to be viewed?
  - sequoia 13y ago
    no, it's not
  - GnwbZHiU 13y ago
    this slideshow doesn't complain about JS, it's giving you suggestions on how to use it well.
pcole 13y 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_if 13y 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.
- camus 13y 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_if 13y 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.
kenster07 13y 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 13y 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 13y 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.
- steveklabnik 13y 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 13y ago
wereHamster 13y ago
Store state in the DOM? Really?
- joshuacc 13y ago
  For the sort of small-scale interactions Zakas was talking about, that's a perfectly reasonable thing to do.
lnemeth 13y ago
Very nice, but unfornately, it seems we lost a lot of information from just watching slides...
gokulk 13y ago
If you use it in the right way, there would be no problems.
andrenotgiant 13y 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 13y 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 13y 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 13y 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 13y 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.
  - andrenotgiant 13y 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.
cromwellian 13y ago
On many sites, the (cached) load of 500k of gzipped JS is dwarfed by the amount of HTML, CSS, and images loaded.
tracker1 13y 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.
speedyrev 13y ago
OK, who clicked through all 84 slides?
chestnut-tree 13y 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/ http://officialandroid.blogspot.co.uk/
umsm 13y 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 13y 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 13y ago
Bird gotta fly, fish gotta swim, hater gotta hate. I love JS!
adambom 13y ago
Did anyone else think this was pedantic?
gwu78 13y 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.
- camus 13y 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 ...
deleted 13y ago
[deleted]
coldnebo 13y 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?
GnwbZHiU 13y 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 13y 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 13y ago
I don't always read Hackernews, but when I do I read it with this - http://nojs.herokuapp.com http://nojs.herokuapp.com
- priyadarshy 13y ago
  its flat design, or should I say no design. prettier than hn
yawaramin 13y ago
Ironically, slides are hosted on a JS implementation of presentation software.

402 points by gulbrandr 13y ago

deleted 13y ago

[deleted]

saurik 13y ago
This was clearly a talk you were supposed to watch, not attempt to read the slide deck through later. Many of my talks are like that, and to avoid people complaining online "your slides suck" even though the people at the talk usually were in agreement that "that was an amazing talk", I always go out of my way to use presentation technologies that are as random and esoteric as possible to make certain that when I am asked "can we have a copy of your slides" the answer is "I guess, but it will be really hard and of no use to you".
camus 13y ago
Nicholas Zakas is a famous JS dev that worked at Yahoo. And the slides have nothing to do with a rant against JS , if it is why you hate them.That's the context.
ExpiredLink 13y ago
Martin Fowler refuses to publish the slides of his talks because they only make sense in the context of his talks. Seems to be a good decision.

siddboots 13y 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 13y 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.

dreen 13y 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 13y 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 13y 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 ;-)
- dreen 13y 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 13y 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 13y ago

Who's the superman?

cliveowen 13y 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.

electrotype 13y ago
Dart ( http://www.dartlang.org 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.
- rartichoke 13y 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.
  - Cthulhu_ 13y ago
    Does Dart support Chrome version 2 [0] or Firefox 3.0.8[1]? Since IE8 stems from that age, March 2009[2] [0] https://en.wikipedia.org/wiki/Google_Chrome#Release_history https://en.wikipedia.org/wiki/Google_Chrome#Release_history [1] http://en.wikipedia.org/wiki/Firefox_release_history http://en.wikipedia.org/wiki/Firefox_release_history [2] http://en.wikipedia.org/wiki/Internet_Explorer_8 http://en.wikipedia.org/wiki/Internet_Explorer_8 It's not reasonable to support an outdated browser version with an inferior Javascript engine, or to single out Internet Explorer as a browser for which older versions should still be supported, imho. (disclaimer: I'm building a webapp that has to work in IE 8)
    - rartichoke 13y ago

weixiyen 13y 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.

nbevans 13y 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 13y ago
  What's nasty about Obj-C?
  - stefantalpalaru 13y ago
    The syntax and the APIs.
    - tres 13y ago
      I understand that the Smalltalk like syntax of Objective C can be difficult to understand at first glance; however, once you've worked with it a bit, the syntax becomes quite expressive -- each argument is labeled; something like using named arguments in Ruby, but it's not optional. Not sure what you mean about the APIs being nasty. Can you elucidate?
      - stefantalpalaru 13y ago
        https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html#//apple_ref/occ/instm/NSString/localizedCaseInsensitiveCompare https://developer.apple.com/library/mac/#documentation/Cocoa...:

16s 13y 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 13y 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_ 13y 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).
- chewxy 13y ago
  I work in advertising. I have seen Ghostery rack up close to 300 trackers before. Piggybacked pixels... they're everywhere
  - hobs 13y ago
    How does one even collect the data from 300 trackers?
    - WiseWeasel 13y ago
      Your 300 affiliate marketing partners run software from their affiliate network which automatically analyzes their tracking pixel server logs to determine how far the traffic they steered made it through your purchase process based on the pixels they requested (unique for each page) and the unique ID in their cookies. Then, their affiliate network collects the sales commissions and pays out the affiliate partners.

krosaen 13y 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.

deleted 13y ago
[deleted]
jhh 13y ago
have you actually done this? I was wondering if this is a feasible and good way to use knockout!
- krosaen 13y 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-applications-the-seven-frameworks-throne-of-js-2012/ 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-s-basic-hummus 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.
joshuacc 13y ago
Angular is also quite good about allowing you to enhance only parts of server-rendered pages.

jrochkind1 13y 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-techniques http://www.infoq.com/presentations/web-development-technique... http://www.reddit.com/r/programming/comments/1eiykw/web_development_youre_doing_it_wrong/ 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.

ebbv 13y 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.

chewxy 13y 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.
- marknutter 13y ago
  People don't use javascript because it's a beautiful, well thought out language. They use it because it runs everywhere.
  - chewxy 13y ago
    Here's the painful part: Douglas Crockford wrote a book called Javascript, the Good Parts. If Javascript were limited to The Good Parts alone, it has the potential to be a beautiful well thought out language. It would be quite close to a beautiful well thought out language
    - city41 13y ago
      What's stopping you from only using the "good parts" in your own code? How is JS a bad tool? It runs reasonably fast, works everywhere, is a small, simple language that's surprisingly powerful. What if Eich had been influenced by C instead of Lisp when creating JS? All things considered, it could have been way worse than it is, and the truth is JavaScript lets you get in there and do good stuff. Not sure why we are still hating on this environment.

deleted 13y ago

[deleted]

bytelayer 13y 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 13y 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.

marknutter 13y ago
I will never understand the utility of posting slides from a talk online without the audio.
- amorphid 13y ago
  I found the slides to be quite informative.
  - acjohnson55 13y ago
    I agree, but I definitely see the grandparent's point. These slide decks are annoying as hell. They're inconvenient for quoting, reading on-the-go, and they can leave out a whole lot of context. This is a trend that really needs to go.
- jasonlotito 13y 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 13y 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 13y ago

Airbnb's Rendr seemed to be a nice solution to this problem https://github.com/airbnb/rendr https://github.com/airbnb/rendr

joeblau 13y 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 13y 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.

protonfish 13y 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.

hrktb 13y 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 13y 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 13y 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.

ChikkaChiChi 13y 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 13y ago

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

deleted 13y ago

[deleted]

d4vlx 13y ago

To bad you have to pay $399 to watch the videos. http://velocityconf.com/velocity2013/public/sv/q/479 http://velocityconf.com/velocity2013/public/sv/q/479 I realize it costs money to run a conference but that seems excessive.

youngtaff 13y ago
Here's the version from SF Web Perf - http://www.ustream.tv/channel/sf-web-performance-group-meetup http://www.ustream.tv/channel/sf-web-performance-group-meetu...
- d4vlx 13y ago
  Awesome, thanks.

ghostdiver 13y ago

I see one problem: - Entire generation of programmers may not have any knowledge about how computer works

kenster07 13y ago
No? If that were to happen, it would be a problem with the programmers more than anyone else.
- ghostdiver 13y ago
  with JavaScript, there is no need to know how computer works, so why would anyone learn(deeply) about that?
  - kenster07 13y ago
    You act as though Javascript will take over the programming world -- I can confidently say that it won't
    - camus 13y ago
      mind you it will ... ( and i'm not pro javascript ).
gnaritas 13y ago
That's not a problem, it's an opportunity for those that do, and there will always be those that do.

Duhck 13y 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 13y 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.
- Duhck 13y 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/ http://www.stevesouders.com/blog/2010/06/01/frontend-spof/

hvs 13y ago

Amusing, this article was submitted 2 weeks ago and got no comments. https://news.ycombinator.com/item?id=5973914 https://news.ycombinator.com/item?id=5973914

ExpiredLink 13y ago
Bad timing?

metaphorm 13y 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.

aaronsnow 13y ago

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

quacker 13y 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.)

steveklabnik 13y 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 13y ago
Is it ironic that this slideshow complains about Javascript but requires it to be viewed?
- sequoia 13y ago
  no, it's not
- GnwbZHiU 13y ago
  this slideshow doesn't complain about JS, it's giving you suggestions on how to use it well.

pcole 13y 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_if 13y 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.

camus 13y 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_if 13y 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.

kenster07 13y 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 13y 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 13y 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.
steveklabnik 13y 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 13y ago

wereHamster 13y ago

Store state in the DOM? Really?

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

lnemeth 13y ago

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

gokulk 13y ago

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

andrenotgiant 13y 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 13y 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 13y 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 13y 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 13y 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.
- andrenotgiant 13y 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.

cromwellian 13y ago

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

tracker1 13y 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.

speedyrev 13y ago

OK, who clicked through all 84 slides?

chestnut-tree 13y 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/ http://officialandroid.blogspot.co.uk/

umsm 13y 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 13y 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 13y ago

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

adambom 13y ago

Did anyone else think this was pedantic?

gwu78 13y 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.

camus 13y 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 ...

deleted 13y ago

[deleted]

coldnebo 13y 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?

GnwbZHiU 13y 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 13y 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 13y ago

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

priyadarshy 13y ago
its flat design, or should I say no design. prettier than hn

yawaramin 13y ago

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