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

I had a blast building hn-books (http://hn-books.com)

All static. I could have deployed the app on a thumb-drive. And it had advanced searching, a book listing and recommendation system, a fully-configurable countdown clock for your startup, and a few other things. It got to the point that whatever I could imagine, I could imagine building it as a static site. And I would prefer doing so.

This is truly separating the view from the data. The same back-end services (for hn-books I didn't even have a back-end!) could plug into zillions of variously-looking front-ends. And as it turned out, the Query String was a heckuva lot more useful than I imagined when I started.

Neat stuff.

ADD: One more thing. If, like most folks, you have a class of data that doesn't change very often, say lookup tables or in hn-books' case the actual database, there's no reason you can't deploy that information as a static file as well. You can pull JSON just as easily from a static file somewhere as as server, and it uses a lot less resources. For my newspaper23 site, I used a combination: 4 times an hour I rebuild the database and deploy as a JSON. Then the clients all just pull from that file. When combined with a CDN this has tremendous scaling potential. And it's very simple to do. Why thrash the database every time somebody visits your site when it's just returning the same stuff?

It sounds like the big jump here might not have been so much moving to Javascript/frontend-based apps, as moving away from a CMS towards a model where they write and control the whole app.

Every time I see posts like this, I come back to warpspire's "Dumb Software:" http://warpspire.com/posts/dumb-software/

"But wait until you see the light! Software today is intelligent! Asynchronous front ends generated from esoteric scripting languages running on clusters of distributed virtual machines around the globe! Death to repetition! It’s more productive! It’s scalable! It’s fault tolerant! I followed the light and it only ended in darkness."

I also don't understand comments like "we can make drastic changes in the UI without any change on the backend"

In Wordpress or a Rails App, I can change the entire UI without having to touch any "backend" code (controllers, models, functions, etc). Am I missing something here?

If their mobile site is any indication, were in for a rough ride.

Of course there may be more pressing issues mentioned in the article, but I couldn't read it as 20% of every single line is cut off.

I really think it's important tha

and approach. When it isn't consi

class. After all, there are only

size.

I have a hard time following this discussion and would be glad if someone could clarify a few aspects.

1. What is a "static client" in this context? From my understanding, a static client is a non-JS web browser that does one thing: render HTML code that is composed and served by the server.

2. People here talk about "(not) rendering HTML on the server". What's that supposed to be? I thought "rendering HTML" means that you take HTML and display it on a screen, which happens ALWAYS in the client and never on the server.

Anyone care to explain?

I wonder what were the reasons to actually change the whole stack/architecture and start to re-invent the world.

There are tons "traditional" frameworks that are mature, proven to be reliable and are full of features.

I've tried about a dozen of both various so-called "RESTful API" (server-side) and webapp frameworks (client-side), and my overall impression is things are far from being mature. Primitive todo-list apps are easy, but more complex things quickly run into lack of features, documentation or just bugs.

I've noticed this as well (and there was a post from Tarek Ziadé's blog a couple of days that mentioned it too) [1]

I've evolved to this approach - with the addition of WebSockets and a data binding layer (knockout) - to building the infrastructure for an algorithmic hedge fund over the last couple of years and it works extremely well.

Your backend components are free to do whatever they need to (in whatever language/technology) and publish data periodically. The web server simply dips into these streams of updates and transforms and routes them to the front end as needed. It's an extremely flexible and agile way to develop applications, I can't recommend it enough! In fact it's so nice to develop this way that I'm writing a book about the ideas and techniques I've used which I hope to post to HN in a couple of weeks when I've got the infrastructure and homepage up and running.

[1] Post: http://blog.ziade.org/2013/01/25/a-new-development-era-essay... Discussion: http://news.ycombinator.com/item?id=5120020

It's both simple and revolutionary.

It starts with saying "well, let's just render html on the client-side instead of on the backend". Suddenly you're in a new world of programming.

I do think this is the immediate future, especially as we utilize typed languages that compile to JS in order to create more complex applications than are feasible with JS alone.

I also think that there will be a swing back to an almost complete server-centric model after that, where all logic and rendering will take place on the server and be streamed to extremely dumb clients...like TVs with basic touch input. This will require a pretty intense infrastructure, but with some nice perks for hardware/software developers. For one, absolute control over an application...bump versions any time you like, easy access to debugging information (crash reports, etc.), watch user usage in real time, on and on. Hardware will also be insanely cheap. Users benefit from the practical equivalent of having a top-of-the-line computer embedded in their smartphones.

So...where's the examples. If the OP works with a lot of non-commercial entities, how does a data API trump the client just being able to create posts and static pages?

Most humanitarian groups want an easy to use CMS with some features, like donation modules, added in. Is the OP building out the content editors too? How is that not a CMS?

I've yet to work with a humanitarian group for which Wordpress was not more than they could handle on their own. When something breaks in their new-wave architecture, how day is it for them to fix on their own?

Edit: I realize the OP is talking about web apps, not just websites...WP is likely not a great option then. But that's why I'm asking for some examples of what they've done and why it justifies a "farewell" to old web dev

The product I'm working on right now is taking this approach. We're upgrading a legacy system. In doing so, we're writing a REST API and the components that we replace are all built to use the API rather than the old legacy data layer.

The goal to to completely replace the application with an API and several UIs, including a full web UI, a mobile UI, and also 'embeddable' UIs.

The API also serves as an integration point for other products in our suite. That allows us to scrape a dozen different SOAP services that are targeted to specific integrations and have those other products all utilize a single API that can do anything that the full product can do.

I'm really happy with this architecture.

Next thing you know, we'll install JS apps just as desktop apps!

...wait a minute.

What about security? How do you authenticate users?

One small issue dev friends I talk to still face is pricing and the need to convince clients that a move to a ruby or js based tech stack vs Wordpress is worth it. In the country where I live, wordpress is far, far cheaper to host than anything else.

That's not static. That's client-side dynamic.

Words have broadly agreed meaning, despite what you or Humpty Dumpty may think.

undefined

Client side rendering and single page applications are not the best solution for most applications. I posit that a partial page refresh approach using PJAX (or something like it) where the server always sends back HTML is a more efficient and rapid approach to development.

There was an article yesterday about how Airbnb was going through some serious gymnastics to get a fully rendered HTML page on initial request and then keep it interactive and client side rendered after that. Why bother? Just send back HTML all the time.

I worked on a very large (100+ developer) application that was fully bought in on Backbone + JSON api consumption. In the few cases where there was a lot of client interactivity (editable grids and drag and drop, most notably) the client side rendering approach made sense. For 90 percent of the application though, partial rendering of HTML from the server would have made things easier and less complicated (and faster!) The initial time to usable page is MUCH longer when you render static content, then make an ajax call to get the data.