Hacker News Reader

Comment by mattmanser | Hacker News Reader

Hmm, degraded development experience of doing everything on the client?

Bit of a bizarre claim there given the state of templating these days. Sounds more of a prejudice than an actual problem.

Also json tends to be much lighter than HTML and if you're taking an optimistic view of updates you can assume the action's been a success and even immediately update the display without waiting for the server to create some simple HTML, so it's arguably a worse user experience due to the lag.

View on HN

With all of the backbone and node.js hype going around, people tend to forget that client-side development is developing on the client's side. Sooner than later you will have to deal with

* nondeterministic testing,

* interactive testing (leaving machines on to run interactive testing at night),

* most of the bugs will live on the client side,

* you'll have to support each and every machine's quirks (you can't pretend everyone are on at least core i5 and chrome, people WILL have machines that do javascript client side template rendering SLOWLY).

* you'll have to find ways to diagnose problems at the client's site, and you will maintain a fleet of various computer configurations to run sanity on.

* which will also cause you to start investing in pairwise testing

* i can go on

DHH is COMPLETELY right. Just because the universe is not ready enough for client side "SPA"s (universe=browsers,internet)

I'm laying my arguments out of experience - I've been a long time Ruby/Rails/.Net/JVM server side dev as well as enterprise software dev (enterprise desktop/workstation application suites, as complex as visual studio and the sorts). I have several node.js projects in production and I'm also doing a couple of projects with Backbone.

Your arguments are a checklist of responsibilities for anyone running any web software, whether the actual DOM elements are being rendered on the server or the client.

I agree that you do most of these arguments when most of your content render on the servers too. However, you DO have limited resources (time, money, people), and these points become more and more painful as you push towards client side.

Still, I insist that some of these arguments are client side specific. Once instance is javascript template rendering speed. Another is, that you would prefer getting statistics on your speed of rendering at the server's side where it is easily controllable and deterministic, rather than shuffle around to close that loop and build a usage service to report back usage and statistics to from the client's side.

I give my arguments from pain and experience in both sides, and I still do both sides despite of the arguments (since it is not always my own choice).

You can still do unit testing of your client-side code if you wrap everything in components that separate state from rendering. The rendering itself you can only test with a human looking at the page anyway (or by comparing to reerence renderings). Extjs uses this approach. I can easily unit-test my forms written on top of extjs.

Fundamentally this is a bikeshedding debate. Whether you're programming on the client or server, the tools are equally capable. The big difference is the server puts you closer to the data, and the client pus you closer to the user. Either way you're struggling with latency, and you do different trade-offs, and either way you reach your goals.

Great! You may have put it better than me with the closer to server - closer to user analogy. So to complete my goal I'll ask a question.

You already are at the server. It cost you almost nothing to manage yourself there (monitor, analyze, etc).

Do you have the resources to handle the complexity of being closer to the user? Is a "true" client side SPA worth it over what 37 are doing?

In terms of value for development investment, I'm not entirely sure, which is what I think David refers to as pleasure of development!

I used to build stuff on the server, then i switched to extjs, with the server only exposing a bunch of json-rpc web services. It's not as big a deal as people paint it out to be. Extjs abstracts away browser differences well enough that i rarely come across issues that aren't reproduceable for me. If they're reproduceable for me in my browser, they're easy to fix.

Now, extjs is a DSL, it's closer to flex development than to traditional web development. It has a learning curve with a pay-off at the end, and the pay-off is easier ui development. If you're building ui the traditional way, but client-side, ymmv. Still, anything to do with rendering glitches is something you'll have to debug by eyeballing it, regardless of where you render your ui. There's no way of automatically logging misplaced floats.

P.S. There's also less to monitor. Typically you'll monitor for performance and security. Performance depends on the browser and pc specs, not the server's load, and security has nothing to do with the client. So, really, there's just not much to monitor. You can attach error handlers to automatically report exceptions to the server, but i've not had a need.

Very true. This is why I'm sticking with a server-heavy design (i.e. Rails) for my main projects. I agree with all of your arguments about the difficulties of testing. And I'd add that there's a distinct lack of tools for testing client-side. Sure, you can get unit tests for client-side JS, and you can run integration tests in Selenium etc.. But the client-side testing ecosystem is tiny and immature compared to that for server-side testing. This will all change, but for now, I don't envy anyone who has to test a heavily client-side app.

We've found that the additional overhead of sending HTML vs JSON is negligible in most cases. The additional speed gained by just sending JSON across is not worth the programming enjoyment hit of doing everything client-side.

When you get below 50-100ms per action, things are generally fast enough that this is not a key problem any more. The user cares greatly if you can go from 800ms to 100ms, but not so much if you can go from 100ms to 70ms.

I have to agree here. A major problem with client-side json is the need for additional documentation and likelihood of things breaking because of simple html edits.

For example, if you are populating a bunch of divs inside a parent div with the data returned using json, you would describe this using something like jquery selectors. Now if someone else comes and moves around the div during a redesign, he must go through whole bunch of js to make sure his shuffling of the divs around won't break the jquery selectors populating the data from json.

Now think about having a parent div that is simply populated with returned HTML from server-side and it seems way easier than using json to populate the data.

That's nonsense, the same issue would apply on the server side templates. If you go around messing with DIVs without an idea of the consequences, you will get in trouble regardless of your templates being on the server or client. If you try to have the designer do a redesign without testing the application afterwards, you're always in for trouble.

you will get in trouble regardless of your templates being on the server or client

My view is that you will get in significantly less trouble because manipulating an HTML template that is rendered on server side is much easier to manage and adapt to a new design than finding nitpick jquery selectors across the app that depend on a specific div structure.

Btw, my post doesn't imply anywhere that a designer should redesign an app without testing. Therefore, your argument about testing is garbage.

Rather than "finding nitpick jquery selectors" I use a client side framework (backbone.js) with a lot of Views which makes my development faster vs using server side templating, so I cannot share your opinion.

Programming enjoyment is, of course, subjective, but for your team the enjoyment is ruby, understood :)

What browsers are you getting the 50-100ms numbers? Similar results on mobile (with a 3G connection)?

50-100ms is the time it takes to generate the response on the server. On top of that you have to add the ping time between you and server and whatever other network overhead there is.

That's why it's great to be closer to 50ms so you'll stay under 100ms even with the network overhead.

How does this impact if you are aiming to build a JSON API too?

Double work.

Not with Rails, afaik. Assuming the routes are consistent, you simply add a 'respond' for JSON and send the relevant chunk of the model. Easy as pie.

That assumes, of course, that the viewmodel used to render the server-side view is identical to the model you'd return serialized into JSON. That's mostly true, but not always.

How about HTML versus MessagePack ( http://msgpack.org/ )?

Exactly what I thought. But you have to remember that 37 is the quintessential Rails shop - client-side logic is not their sweet spot.

So it's only natural that for their flagship product they'd rather keep pushing the limits of their comfort zone rather than go all out client-side, no matter how natural that choice might be for a "web app".

Stacker sounds like AJAX as it was done in 2006, except trigger by pushState. Maybe I'm misunderstanding it though. I'd be curious what the performance penalty is on mobile.

Well, it's really stacker + pushState + MAX cache.

But why would there be a performance penalty? Doesn't this result in the client doing _less_ work all around? Less work than the multi-page approach...and less work from the client-side templating approach, no?

Seems it's a highly refined version of what was done in the "old" days. I remember doing something similar for an old project in ASP.NET. (Well more similar to pjax)

As to performance on mobile, i think it might all depend on how large the html fragments are.

Your comment ignores the next section in the article, detailing how they are caching templates with a high level of granularity, and actively removing template logic that impedes efficient cacheing.

The article goes on to state that delivery times for cached segments of HTML are under 50ms in most cases. While I agree that it would be possible for them to improve the user's perception of the app performance even further via JSON or client-side updates, with the level of performance they described that type of improvement is unnecessary and introduces additional vectors for bugs to creep into production code.

When you have a persistent page (that you update with HTML5 push-state) you suddenly have to worry about issues like memory fragmentation. If you do lots of small updates to build a page from a template + JSON every time the user navigates it's easy to hit some situation where everything starts lagging for no clear reason.

If you simply swap out a large part of the page with some HTML right out of an Ajax request you don't have to worry about any of that.

Let's be fair - poorly designed code causes memory bloat whether you're on the client or on the server-side.

Also, garbage collection efficiency in browsers is a metric of fierce competition among browsers. It's superb already, and it's getting awesomer by the minute. It's a safe choice for the future.

And when you do everything client-side, you have to worry about memory leaks. Where the state is, is where the memory pain is.

Reply on news.ycombinator.com