5 ms·

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

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

stephenr 10y ago
> terrible "wilderness years" of server templates wat.
- deleted 10y ago
  [deleted]
- lumpypua 10y ago
  That's fine, it's: > terrible "wilderness years" of server templates and jQuery where things go off the rails.
  - yellowapple 10y ago
    I reckon > terrible "wilderness years" of ... jQuery is the part where things go off the rails (and literally off the Rails).
    - the-dude 10y ago
      Didn't Rails originally ship with Prototype? I liked Prototype.
- deleted 10y ago
  [deleted]
pjmlp 10y ago
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.
- seanp2k2 10y ago
  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.
  - pjmlp 10y ago
    > 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.
  - TeMPOraL 10y ago
    > 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.
  - arethuza 10y ago
    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.

stephenr 10y ago

> terrible "wilderness years" of server templates wat.

deleted 10y ago
[deleted]
lumpypua 10y ago
That's fine, it's: > terrible "wilderness years" of server templates and jQuery where things go off the rails.
- yellowapple 10y ago
  I reckon > terrible "wilderness years" of ... jQuery is the part where things go off the rails (and literally off the Rails).
  - the-dude 10y ago
    Didn't Rails originally ship with Prototype? I liked Prototype.
deleted 10y ago
[deleted]

pjmlp 10y ago

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.

seanp2k2 10y ago
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.
- pjmlp 10y ago
  > 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.
- TeMPOraL 10y ago
  > 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.
- arethuza 10y ago
  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.