Comment by carsongross | Hacker News Reader

Comment by carsongross | Hacker News Reader

Parent Full thread

Money quote from the article:

The new admin would make a return to more classic architecture with some modernizations. Our approach would be ERB views and server-side rendering, with the use of Turbolinks, and a lightweight custom JavaScript binding system. This allowed us to tackle problems of code duplication and developer productivity in a single blow.

As always, the devil is in the details and I'm looking forward to seeing what their JS binding system looks like, but the pendulum appears to be swinging back towards server-side rendering and models, even amongst the cool kids.

I have been working on a small library for doing HTML partial AJAX programming, using fairly straight-forward HTML attributes and traditional server side rendering (plus some goodies like custom HTTP header support, timers, etc.):

http://intercoolerjs.org

I'm using it successfully in a few projects and very much enjoy the simplicity of the whole approach when contrasted with full MVC systems.

Can we please drop the "cool kids" cliche? It's a tired generalization.

Clearly at this point both architectures work, it's childish to see this as an argument for server-side rendering. Obviously it works, so do client MVC systems.

The value in this article is the humble detailing of their mistakes that many of us also experience in our careers.

I think part of that is a reaction to how many people jumped on to the client-side JS framework bandwagon very early, because it was "the next big thing", but before the tools were ready for production.

I've had to deal with more than my fair share of crappy, hacked-together Ember apps that were developed like this. There have been too many breaking changes to upgrade, performance is bad, an they're full of hacks to work around deficiencies that existed back then.

Even though we actually have production-ready frameworks now, that sort of thing can leave a bad taste in your mouth. Especially when you see the same mistakes made by people jumping onto the Meteor bandwagon, for example. But it's defintiely something to try and get over :)

Ember now feels like a complete framework, but fundamentally any Ember app will be tightly coupled to Ember the framework.

In many ways this is the same as Rails Apps have traditionally been very much tied to Rails.

Having worked on many Rails Apps that have grown beyond the scope of the framework, the apps I build today are as decoupled as possible from the framework.

I hope that the Ember community can grow in that direction too, and at a distant look, it feels like Web Components will be that method of decoupling.

Right now I tell everyone that I'd never render HTML (or JS) on the server, and I hope that JS frameworks will keep maturing with my clients' needs, so I don't have to renege on that approach.

Can we please drop the "cool kids" cliche? It's a tired generalization.

Worse, 'cool kids' implies doing something because someone else is doing it rather than because it's the right thing to do in your organisation. It smacks of cargo cult behaviour - copying actions and hoping to get the same end result without understanding why.

I think it's actually the exact phrase we should be using. I work with helping beginner programmers learn to code and if they want to know "javascript" (they don't even know what that means) they are always asking for ember/angular/node and when I ask why they want to use these technologies or what project they are working on that would benefit from that style they blank. It's definitely cool kid syndrome.

    >and a lightweight custom JavaScript binding system

I wonder what the reason was for not using a smaller binding library like Knockout vs rolling their own.

Reply on news.ycombinator.com