
Enough with the JavaScript already - gulbrandr
http://fr.slideshare.net/nzakas/enough-withthejavascriptalready
======
hrktb
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
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
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.

~~~
hrktb
I think that in the mobile side it actually went the way you describe. In
japan docomo offered an open java platform (free to use, free to install, no
gatekeeper for standard apps). Mobile html was only useable for dead simple
things, there was no js of course, and any service with mildly complex things
to do or show would be better to implement in it's own app. It sounds
terrible, but the user experience wasn't that bad. The terrible toolkit part
was solved by Docomo shipping it's own UI toolkit (no J2ME compatibility, but
it was so much more useable), and I think at some point there was a way to
launch an app from the browser without installing it but I'm not sure my
memory serves me well.

The choice of java was made for security of course, and I never heard of any
serious breach in 10 years following the mobile tech news.

We get the same phenomenon I guess with the "go the mobile app" redirects on
websites that don't want to have x optimized versions of the same service.

------
krosaen
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
have you actually done this? I was wondering if this is a feasible and good
way to use knockout!

~~~
krosaen
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...](http://blog.stevensanderson.com/2012/08/01/rich-javascript-
applications-the-seven-frameworks-throne-of-js-2012/)

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...](http://food52.com/recipes/22888-yotam-ottolenghi-sami-tamimi-s-
basic-hummus)

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

------
weixiyen
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
"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
What's nasty about Obj-C?

~~~
stefantalpalaru
The syntax and the APIs.

~~~
tres
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
[https://developer.apple.com/library/mac/#documentation/Cocoa...](https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html#//apple_ref/occ/instm/NSString/localizedCaseInsensitiveCompare):

~~~
rainforest
Could you go further? What, in your opinion is wrong with NSString? How would
you fix it?

------
cliveowen
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
Absolutely. Write in whatever language you like, compile to asm.js - that way
you're running in the browser, at about half native speed.

~~~
PommeDeTerre
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.

~~~
frou_dh
Talk about JavaScript being replaced wholesale should be regarded as therapy.
Therapy to dull the realisation that JavaScript is now immortal because it
gained such massive reach and entrenchment. It's the web counterpart to C the
immortal.

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

~~~
nine_k
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.

~~~
pbsdp
> _JS is a relatively fine compile target ..._

No, it's not.

> _... and with asm.js, a pretty fast one._

And asm.js demonstrates why it's not, because asm.js isn't JavaScript. It's a
strictly defined ASCII-encoded bytecode that happens to be representable using
a subset of valid JavaScript.

At which point, one must ask, what bizzaro-world engineering justification do
we have for using a JavaScript subset as a first-order bytecode format? Why
couldn't the silly JS bytecode format be a second-tier target for legacy
browsers that don't support a proper format?

On top of which, why are we willing to throw away 2x+ performance (in the
_best_ case)? Is the iOS/Mac App Store not successful enough for us, such that
we absolutely refuse to try something other than adding more JavaScript to
every problem we face with web app deployment?

~~~
pcwalton
asm.js is JavaScript. It executes according to the semantics specified in
ECMA-262.

The 2x performance numbers for OdinMonkey are not "best case": they _include
compilation time_ and will certainly improve (they are better now already).

Regarding having a "real IR", throwing away backwards compatibility for
surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for
example. It failed.

~~~
pbsdp
> _asm.js is JavaScript. It executes according to the semantics specified in
> ECMA-262._

No, it's a strictly defined text-encoded bytecode that happens to be
representable using a subset of valid JavaScript. If you deviate from the
standard using valid JavaScript, you lose the gains.

Calling it "JavaScript" is just a semantic game. You can't output arbitrary
but fully 100% standards-compliant JavaScript from a compiler and expect
asm.js to do anything meaningful.

> _Regarding having a "real IR", throwing away backwards compatibility for
> surface syntax doesn't work on the Web. It was tried, with XHTML 2.0 for
> example. It failed._

The irony is that these things fail _because_ of the people who wish to
maintain the status quo, and then those same people point to the failure as
justification for maintaining the status quo.

It's not like you folks at Mozilla couldn't get support for a "real IR" from
Google/Chrome -- that's half the market right there. In fact, the actual
problem is that Google could never get support from _you_.

~~~
pcwalton
> If you deviate from the standard using valid JavaScript, you lose the gains.

That's true for lots of JavaScript optimizations. JS optimization is all about
speculation that the more dynamic features won't be used. Try adding calls to
"eval" within a JavaScript function in any modern JS engine and watch its
performance drop by an order of magnitude. Does that make functions that don't
use "eval" no longer JavaScript? After all, adding a call to the standardized
function "eval" negates the performance benefits of "eval"-less JS.

asm.js is just this principle writ large.

> Calling it "JavaScript" is just a semantic game.

No, it means that asm.js is backwards compatible. That is not a game; that is
the entire point. That is why asm.js worked in Chrome (with good performance
even!) from day one.

> It's not like you folks at Mozilla couldn't get support for a "real IR" from
> Google/Chrome -- that's half the market right there. In fact, the actual
> problem is that Google could never get support from you.

Because PNaCl is not a good idea for Web content. People have this idea that
Mozilla knows PNaCl is "better" than asm.js, but Mozilla wants to stick to JS
out of some sort of pride or NIH syndrome. This is not the case. Backwards
compatibility is the main advantage of asm.js, of course. But there are also
many others: LLVM IR is a compiler IR and was not designed for this; asm.js is
smaller when gzipped than LLVM bitcode; asm.js compiles faster than PNaCl;
asm.js can reuse the JavaScript infrastructure, leading to a smaller, simpler
browser; asm.js does not have the Pepper API which reimplements all of the Web
APIs in underspecified ways.

~~~
mindcrime
Maybe it's time to go back to the HotJava[1] approach and use Java bytecode as
the canonical "bytecode for the Web".

OK, to be fair, the browser itself doesn't really need to be written in Java.
But other than Javascript, (and maybe Flash, I suppose) Java bytecode probably
has the most penetration as a mechanism for delivering "programs" over the
web. Maybe we should just embrace it...

[1]:
[http://en.wikipedia.org/wiki/HotJava](http://en.wikipedia.org/wiki/HotJava)

------
jrochkind1
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.infoq.com/presentations/web-development-techniques)

[http://www.reddit.com/r/programming/comments/1eiykw/web_deve...](http://www.reddit.com/r/programming/comments/1eiykw/web_development_youre_doing_it_wrong/)

(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.

------
kenster07
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
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
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.

------
16s
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.

~~~
Cthulhu_
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
I work in advertising. I have seen Ghostery rack up close to 300 trackers
before. Piggybacked pixels... they're everywhere

~~~
hobs
How does one even collect the data from 300 trackers?

~~~
WiseWeasel
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.

~~~
hobs
Ah, gotcha, that makes more sense. I was like, 300 individual sites with
individual tracking on what page, what the, how the, etc. Thanks for the
clarification!

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

------
netmute
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
I will never understand the utility of posting slides from a talk online
without the audio.

~~~
amorphid
I found the slides to be quite informative.

~~~
acjohnson55
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.

------
steveklabnik
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
Is it ironic that this slideshow complains about Javascript but requires it to
be viewed?

~~~
sequoia
no, it's not

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

------
chestnut-tree
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/)

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

------
andrenotgiant
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?

~~~
tnuc
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
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.

------
ChikkaChiChi
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.

------
dreen
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?

~~~
bad_user
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
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.

------
d4vlx
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
Here's the version from SF Web Perf - [http://www.ustream.tv/channel/sf-web-
performance-group-meetu...](http://www.ustream.tv/channel/sf-web-performance-
group-meetup)

~~~
d4vlx
Awesome, thanks.

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

~~~
quacker
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.)

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

[https://github.com/airbnb/rendr](https://github.com/airbnb/rendr)

------
agentultra
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
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.

------
lukifer
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.

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

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

------
ghostdiver
I see one problem:

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

~~~
kenster07
No?

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

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

~~~
kenster07
You act as though Javascript will take over the programming world -- I can
confidently say that it won't

~~~
camus
mind you it will ... ( and i'm not pro javascript ).

------
bytelayer
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?

------
as_if
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
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
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.

------
rhokstar
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.

------
matteodepalo
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.

------
GnwbZHiU
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.

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

------
pcole
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.

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

------
umsm
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...

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

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

------
adambom
Did anyone else think this was pedantic?

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

------
Duhck
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
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
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/)

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

------
Gravityloss
Who's the superman?

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

------
hvs
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
Bad timing?

------
wereHamster
Store state in the DOM? Really?

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

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

------
speedyrev
OK, who clicked through all 84 slides?

------
DrinkWater
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)

