Comment by jacques_chester | Hacker News Reader

Comment by jacques_chester | Hacker News Reader

jacques_chester

Everything old is new again.

This used to be called Service-Oriented Architecture.

Before that, client-server computing.

Before that, online terminals.

No, it's not exactly the same. History in our industry, as Mark Twain said, doesn't repeat. But it sure does rhyme.

My main concern is that people have a problem with Completely Legitimate Architecture X, and then stumble on Completely Legitimate Architecture Y. What was a nightmare in CLA-X is a cakewalk in CLA-Y.

Then come the blog posts (previously the CACM articles). The books. The conferences. The whole grand crusade springs to life and promises to evict the horrid evils of CLA-X, now that the scales have fallen from our eyes.

Then after a while, CLA-Y becomes the norm and CLA-X fades into infinite obscurity. CLA-Y is unquestioned, unexamined. Just how things are done. Why? Because.

Then one day a bright programmer notices that if they rearrange the pieces like so, they solve a number of well known problems with CLA-Y. Not improve, not ameliorate. Solve!

And somewhere, a 32-year-old curmudgeon called Jacques Chester begins to write a long post about how this is actually just CLA-X, with a different name ...

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

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

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.

> 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?

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

In the late 90s, the concept of video on the web was just starting. Problem was, the technology wasn't there - even Flash videos were a nightmare. Dial-up connections struggled to download large images, let alone videos. Hence, video startups of the 90s struggled and largely failed.

But technology did change. Faster upload and download speeds, camera phones with video, consistent browser APIs that rendered video more quickly. And now YouTube worked, not because it was a new idea, but simply because the technology necessary for it to work now existed.

Same could be said of static HTML. With a combination of Angular, Jekyll, S3 and websockets you can have a very quick site. This is not just a matter of fashion, but also the supporting technology.

Reply on news.ycombinator.com