Hacker News Reader

Comment by lobster_johnson | Hacker News Reader

The JavaScript situation is grossly exaggerated. It's doing very well. It's just that the people who aren't productive are also the ones shouting the loudest on HN. Meanwhile, a lot of people are being very quiet getting tons of stuff done really efficiently. (Source: Me, very happy React developer who is so glad we're finally out of the terrible "wilderness years" of server templates and jQuery.)

View on HN

I will rather take any server templates and jQuery over flavour of the month JS framework, and will keep doing that until my boss or customer tells me otherwise.

No need for JS for what can be done in plain HTML/CSS.

Offloading view changes to clients can both give a better experience (changes are reflected ~instantly vs a refresh and a round-trip to the server) and can scale much better (e.g. Server only used to process CRUD operations, CDN or nginx / Apache used to distribute static assets like the JS app, index html, CSS + images etc).

It can also potentially help with things like caching, but more traditional server-side templated designs can also use things like Varnish with the ESI feature, utilizing caching mechanisms in the framework / app (e.g. Memcache or whatever), etc.

I used to think SPAs were dumb, but now I love Rails 5 API-only mode + EmberJS + EmberData. It also makes server-to-server a breeze, because you already have your API. Mix in JSONAPI, swagger, and oauth and it's a pretty happy environment to build software in.

> changes are reflected ~instantly vs a refresh and a round-trip to the server

You can achieve that with a little sprinkle from jQuery.

For UI/UX rich experiences, taking advantage of OS animation frameworks and widgets, I would anyway advise native applications.

> and can scale much better

Offloading everything like that to client is antisocial behaviour. Seriously. This goes beyond "bad engineering"; for any popular website, this literally means saving a bit on your servers while causing lots of electricity being wasted by your millions of visitors. This is the computing equivalent of selling extremely fuel-inefficient cars to regular people.

It can give benefits but all too often I'm left looking at a spinner wondering what the hell is going on before eventually being presented with a simple page that would have been trivial to render server side.

c2.com being a tragic example of this.

At first I said to myself, "C2, wtf is this guy talking about I could load that on a calculator".

I was wrong. Load time was an abysmal 14 second(!) wait. I normally don't make jokes on HN but today I'll be pouring out a sip of dark roast for my metaphorical 'dead homie'.

Changes on the client still usually roundtrip to the server to get the data (via a Rest call these days, then parse the JSON response, then render and apply the diffs to the DOM).

And I don't buy the argument that javascript-based client apps scale better than servers rendered partials where there's been over a decade worth of solutions for scaling out the server layer. Also, you'd be applying a lot of the same techniques for scaling a pure API as something spitting out partial web views.

> terrible "wilderness years" of server templates

wat.

That's fine, it's:

> terrible "wilderness years" of server templates and jQuery

where things go off the rails.

I reckon

> terrible "wilderness years" of ... jQuery

is the part where things go off the rails (and literally off the Rails).

Didn't Rails originally ship with Prototype? I liked Prototype.

Reply on news.ycombinator.com