Comment by dspillett | Hacker News Reader

Comment by dspillett | Hacker News Reader

Parent Full thread

> I would expect real adoption of JS to begin when ES6 features (generators, classes, etc) become available.

The adoption of server-side JS implementations (node particularly) is already "real" I think - the growth in its popularity seems to be very quick compared to other platforms when you consider how short a time has passed since node was first made available.

I agree that one of the things constraining that growth is the ease with which a nightmare of callbacks gets created, which can be a problem for later maintenance/improvement, and some of the newer language features will help that - but I think many will avoid using those features until they are commonly available client side too (there are many out there still using relatively old browsers, and a lot of projects don't have the luxury of being able to ignore them).

I think a major thing that is making those consider node hold back a little is the very thing that has made it successful: the rapid growth and evolution which is still on-going. I suspect that there are many experimenting with it but waiting until things settles down (which the core no doubt will for a while soon) before committing to using it for major projects.

> but I think many will avoid using those features until they are commonly available client side too

Why would you do that? If you have a few more advanced features on the server side that doesn't run on the client why wouldn't a team take advantage of them just for server-side code. Maybe the fear is server-side code ends up getting run on the client, but I feel like the separation would be pretty obvious that should be easy to avoid. Node.js allows you use the same language on the frontend and backend but it's not like people are justing moving code around between the two without regard for what context it's running in.

Actually, there's a couple of up-and-coming node.js frameworks which do encourage using much of the same code on client and server. Some of the ReactJS stacks do, for example.

The thing is, it turns out that what people want is proper separation of frontend and backend, not separation of client and server. Outside of single-page apps, there's a fair bit of "generate this page for me" stuff required as a baseline, but also a lot of places where if it's possible, rendering (and animating) on the client-side provides a better experience. GitHub's repository browsing is an example, as is Twitter's entire site, as is Google's Instant Search.

So running the same view logic on the server and client is a good thing, as it results in not having to write it once for each environment. The controller glue for tying it to the model changes, but that can easily be switched out per environment without changing the view's code, and is often generic enough that it can be implemented at least in part by a library.

With traceur you can write in ES6 and transpile it to ES5 so I will imagine that ES6 will really take off over the next 2 years.

Reply on news.ycombinator.com