Hacker News Reader

Comment by andrzejkrzywda | Hacker News Reader

It may help, if we focus on some specific examples of CLA-X and CLA-Y.

Rendering html on the backend was the only option for years, as the clients didn't have the computation power. Now, we're getting to the point, where rendering client-side becomes possible.

We're not rendering html client-side for fun. It makes the UI more responsive, while keeping the overall architecture more simple. There's a cleaner separation between the client and the server.

We can (and we do) have separate teams working on client/server. It wasn't that easy before.

I'm 33, if that makes my comment more legit ;)

View on HN

> We're not rendering html client-side for fun. It makes the UI more responsive, while keeping the overall architecture more simple. There's a cleaner separation between the client and the server.

Except the time to first user activity is delayed. Speed is an important criteria to responsiveness.

The architecture problems can be solved without pushing it all to the client. It's a standard service-oriented architecture. Where the processing happens is mostly irrelevant.

> Except the time to first user activity is delayed. Speed is an important criteria to responsiveness.

Not if the client receives the requested page pre-rendered. The client should then render subsequent pages.

That would jeopardise the "overall architecture more simpler" which is the selling point of the article.

If there is a way to describe a conversion of data (json, whatever) to particular html that will work both client and server side, then sure. Prerender the initial page server side, and then do updates on the client. But if there is no integrated way, you end up failing DRY. Can Node do this?

Right, so it's a balance thing. But these tend to move in circles. Right now it seems like the client is the place to do most of the work and nothing about that can be changed.

As it so happens I'm working on an application with this sort of an architecture -- lots happening on the client, with command objects passing back and forth. So I'm not saying it's pointless.

If I have a point, it's that this isn't as revolutionary as it might at first appear. And if there's a larger point, it's that as an industry we have the collective memory of a goldfish on crack.

> "if there's a larger point, it's that as an industry we have the collective memory of a goldfish on crack."

Which is probably more a reflection of our age-ism and the fact that 'hot new approach' is typically embraced as 'hot' and 'new' by people who were in primary school the last time it was popular.

That said, as long as people are throwing out 'the way' for something else, I think that counts as a revolution. Regardless of whether the new thing is actually new.

Neither democracies nor republics were particularly 'new' in the late 18th century. But their popular re-application was still a pretty big deal.

So it's actually a grandfather-grandson dynamic, just compressed into 15 year cycles.

> clients didn't have the computation power

I highly doubt so.

In early 2000s desktop browsers were already quite powerful, ran Flash applets and had XMLHTTPRequest, so client-side webapps were perfectly technologically possible. Yet almost everyone generated HTML on the server side.

I even remember one webforum using pure XML "pages" and XSLT on client-side to build HTML. It's just that this overall approach (client-side apps, not XSLT) wasn't popular for some reason, until recently.

A few reasons:

1. Because about 90% of web users were on awful Microsoft browsers which was extremely slow at processing JavaScript, and made a very bad job of rendering CSS. Now, 80-90% of users are on a modern browser.

2. Google's methods of indexing and scoring content changed - it now parses JavaScript, gives value to speedy pages, is good at detecting keyword stuffing, etc.

3. Always-on internet is now pretty much a given, even on phones.

4. There are more developers, trying more things, sharing more experience.

5. Tools. In 2006, we had Drupal, Wordpress, Plone, and a few other odds and ends. These days, we have Varnish, nginx, Jekyll, CloudFront, MongoDB, etc. There are a lot more options, without having to spend a fortune or build everything yourself.

Microsoft browsers were the first ones that could do AJAX.

Indeed. The first AJAX development I did in the early/mid-2000s was IE-only because the other browsers didn't have the correct support.

Yeah, this wasn't Microsoft bashing. Just pointing out that, for whatever reason, the state of browsers during that period limited what could be done with static HTML and AJAX.

>We're not rendering html client-side for fun.

Everyone I know who is doing it is doing it because "that's the future". No logical or technical reason at all, just following the current fad.

>It makes the UI more responsive, while keeping the overall architecture more simple

It does neither of those things. Most javascript apps are much slower than the equivalent app using server side rendering of html. Look at how incredibly slow and clunky twitter is for example. The architecture of a typical fad javascript app is a nightmare compared to virtually anything else, super crazy "enterprise" java monstrosities are the only things I've seen that are more complex.

>We can (and we do) have separate teams working on client/server. It wasn't that easy before.

It could have been, we have that. Our client team does html, css and javascript. The server team does haskell and postgresql. The only thing you need to do this is a template engine that separates code from markup.

Reply on news.ycombinator.com