Hacker News Reader

6. Pre-rendering is a complete mess. Yes, if you try to pre-render Hello World application it will do fine. But in real world examples your main menu, for example needs to pre-render only the top links and not deep-links. Good luck doing that kind of stuff in Angular or React. Also Express on-premise pre-rendering of dynamic pages is terribly slow, 2 seconds to load an website if you have serious application.

It looks like you are either misguided or are doing something wrong.

This is not how React or Angular (or Express) works. Only the stuff that is required per-route (or whatever state) is "rendered" server-side. The rest is chunked away and retrieved when needed. From my experience, express rendered react apps never take longer than php / whatever rendered sites, given the data dependencies are retrieved from the same source (api, db e.g.).

> Only the stuff that is required per-route (or whatever state) is "rendered" server-side

Yes, the whole page, which includes the header, footer, menus etc.. What's your point here? I don't get it.

Correct. The whole page is rendered on the server. The way it would be rendered by a PHP script. There is no need to pre-render anything else, it's a SPA. The concept of pre-rendering is usually redundant in the context of SPAs.

Good points. I'll add that whenever I can do just server-side templating, it's so wonderful to have access to everything, from mature framework/language functionality to the entire database.

Whenever I do client-side stuff, I need to agonize over what libraries to pull in, and consider the api endpoints for data I need (and of course all sorts of security issues surrounding that).

Can't afford to start again every 5 years.

I Beg to differ, or at least add more perspective. I've noticed a trend over the past few years at large (>1$bn revenue) b2b and telecoms companies; teams in those organisations working on newer projects or initiatives start with the premise that the UI will be rewritten again in 3-5 years, and design accordingly. Maintenance concerns of that part of the project, for good or bad, melt away.

I think you need to ask the end users their opinion of this. This is a common failure mode in corporations of that size.

It's really not efficient throwing everything away every 3-5 years.

10 years is minimum cycle IMHO, possibly longer now that standards are relatively stagnant allowing incremental improvement. That's the point at which you can recoup the retraining investment and cover the hardware cycles easily.

At the end of the day the purpose of the software is to deliver a benefit and churn based rewrites pretty much pause all comprehensive development projects. They have no business value.

I have done enterprise stuff for about 20 years too. On the web side I discovered smartclient.com in 2008 and haven’t looked back. And yes I’ve had the IE11 on Citrix experience also :(

It’s an SPA, fantastic documentation, customers love it, and there’s an LGPL version of it.

My point is not to get you to use it - it is more that SPAs can work and work well in enterprise settings and for both dev teams and users.

PS: testing it with selenium is really easy - there’s a piece in the docs on how to do it :)

I use a GWT based application regularly which Smartclient appears to be. No thanks.

As for testing with selenium it's more the point that the entire thing is stateful so the user journeys are much more difficult to program which leads to horrible test coupling as you scale the suite out.

I suppose you have to ask: Do you have 22,000+ test cases?

There is a gwt version but I’ve never used it.

Yes in some cases we had lots of test cases. But that’s just a result of the sophistication afforded to us. Yes SPAs enable the sophistication but citing that as a weakness is like claiming that a car is worse than a horse and cart because there are more mechanical parts that can go wrong!

What sophistication is this I can't do trivially without it?

For example - take a grid like this one: https://www.smartclient.com/smartclient/showcase/?id=gridHea...

Now right-click on the grid headers and change the grouping, add a frozen column. How many unit tests is that?

Now go here: https://www.smartclient.com/smartclient/showcase/?id=userDef... and edit some of the hilites - again how many unit tests?

Now, 90+% of websites and webapps don't need this type of function. Enterprise use cases (especially for things where users are coming off of Excel sheets and the like) absolutely need this sort of stuff.

This is not new. ExtJS existed a decade ago.

But the performance was so bad that we threw it out of the window at evaluation time and wrote our own very light weight augmented view components which provided exactly this class of functionality.

For example, we render a bog standard table, then decorate it with some javascript which can collect a composite part of the table if there's a change of state. Basically a partial page refresh.

The code is tiny for this, the first hit is the view that the user wants to see with no RTT, minimal script load time (we use jquery to attach event handlers and that's it). After that we just suck the changed part of the page body down.

Fancy a 50ms RTT to a page hit? We do that.

which jQuery version are you using? are you using ALL of jQuery, or a custom build?

jQuery 3.3. We started with 1.2. Custom build. Quite thin.

We had same issue with Ext. We took a separate route to solve the same problem.

Hacking around with the DOM is just not fun - and back then every browser had its own set of quirks. Personally the approach you took probably required as many unit tests as an SPA unless you only had to support one browser for a very limited set of functions.

  This approach introduces a lot more pain from experience:

"From experience" — that's the thing. "YOUR" experience. As a JS DEV I've experienced a lot of good and bad examples. When things are done right, SPAs are a pleasure to work with and a pleasure to use.

  1. Having to maintain and upgrade SPA type frameworks is hell and you have to do that sometimes (think Angular upgrade hell). Can't afford to start again every 5 years.

That is true. But that is also true for the backend frameworks too. All major upgrades introduce breaking changes. That's not SPA specific. And a properly written SPA (or any other application) is very upgradable.

  2. The performance, and the article actually states it, is shitty at the best of times. All it takes is one client running mandatory IE11 on Citrix and you lose a customer.

Absolutely not. When done right, the performance is on-par with a regular backend-framework-served website.

  3. Most of the complexity is hard complexity that has to be there to process rules. Rules are way more complex than you want to run on a client in some cases.

This is too ambiguous to comment on. Butter is buttery?

  4. They are incredibly difficult to test. Go try testing a big SPA with selenium for example.

Absolutely not true. They are a blast to test. Once again, when done right.

  5. Security boundaries are terribly difficult to enforce when half of your application isn't inside your control. Having done desktop development for a number of years, the worst turds I've seen are in that space and the SPA brings them all to the web which is one of the most hacked up evolutionary disasters we have ever created.

  Really our responsibility as engineers, architects, developers is to give the user the best experience and that means the fastest and most reliable one. SPAs are neither. KISS is a mentality we should be using and I can build a better user experience without SPAs.

That is your opinion. You can build a better user experience without SPAs, I can build a better user experience with SPAs. Who's right then?

The comments you wrote are applicable to ANY application (not just SPAs) when it's not done right. But it looks like it's somewhat of a trend here to blame everything on badly developed SPAs.

The problem is that badly developed SPAs are a lot worse, heavier, slower, and more irritating than badly developed request-response "webapps". And God help you if you need accessibility.

They also have the same sort of problems that Flash used to have. And there, too, you can say, that it was possible to write better apps in flash than the best you can write in HTML. It really was. There were a few really nice examples.

But ... it wasn't happening. Vast majority of flash apps sucked beyond belief. Same is true for SPAs.

> Absolutely not. When done right, the performance is on-par with a regular backend-framework-served website.

Nope. It very much is not. Because an SPA doesn't start working until it's done 5-10 server round trips, the slowest part of any website interaction. Regular-backend-framework-served websites are functional after 1 server round trip.

This is the big problem I have with SPA developers. In order to save on server round trips you make more of them. Logic at the client side. That's the theory. But they actually need more roundtrips in almost all cases, and many more during startup. So they start slower, they run slower.

So I have 2 very big problems with SPAs:

1) the "flash problem": the website owners have "more control". And they invariably use it to create heavy, slow "beautiful" monstrosities that border on unusable.

2) even if written well, they are a lot slower. First at startup, and also once running. Server round trip are the overriding cost and SPAs actually do more of them. The actual amount of data in a request, as long as it's less than, say 20kb or so, doesn't actually matter.

> Nope. It very much is not. Because an SPA doesn't start working until it's done 5-10 server round trips, the slowest part of any website interaction. Regular-backend-framework-served websites are functional after 1 server round trip.

Incorrect. A server-side-rendered SPA will be just as functional as the regular-backend-framework-served website, that is functional after 1 server round trip, as in the html is served to the client.

This is the big problem with people who don't know how SPAs should be done. And you keep on circling the problems that should be blamed on poorly written applications and bad design choices, not SPAs as a paradigm.

The rest of your arguments seems to be based on the fact that you do not know how properly written SPAs are supposed to function, ergo the rest of your arguments is invalid, sorry.

Server rendering:

Request Reply

(maybe some images come next, but the site is functional. Ie. showing actual useful data, also images, css, ... are simply common between both app types. Both can be inlined if you want to avoid the cost)

SPA: html reply

request javascript reply

request javascript dependencies reply

request the actual useful data the site intends to show reply

(note that these requests NEED to happen even when cached, also SPAs are of course less cacheable than server rendering)

That's 4x slower minimum. In practice, unless you implement pipelining in your api (ie. fat chance) the request javascript dependencies and request useful data steps really have to happen 5x or 10x. This will turn what is already a disaster into a global catastrophe.

Also it doesn't matter what the best developers do, for the reputation of actual types of apps. It matters what the average (ie. very bad) developers do.

Not to mention parsing the javascript, and then generating the HTML and/or DOM tree. Sure, you can do SSR first, but then you're still doing SSR for the first load anyways.

Author here: 1. Yes, but you are watching sausage being made. Previously the platform owners would just come on stage and announce the new version of framework (think MFC, WPF, Android, Cocoa, UI Touch) and say "go play with it". The public wasn't aware of it being developed and all the challenges that went into development. Also, there is no platform owner on the Web. 2. Yes it is, but it will get better! It would never get better on its own because there isn't a single platform owner and especially if no one is using it.

The rest is not even wrong.

> The rest is not even wrong.

Please elaborate. Your rude dismissal is not informative.

I apologise if I came across as rude, I thought I was making simple informative statements. Here is the rest of the comment:

> 3. Most of the complexity is hard complexity that has to be there to process rules. Rules are way more complex than you want to run on a client in some cases.

I don't know how to address this since it doesn't depend on the boundary of server/client code split.

> 4. They are incredibly difficult to test. Go try testing a big SPA with selenium for example.

This is highly application and framework dependent. Not all SPA apps in all SPA frameworks suffer from this problem. We are using different testing frameworks and we wouldn't say we have any significant issues.

> 5. Security boundaries are terribly difficult to enforce when half of your application isn't inside your control.

Backend doesn't change if you are fully server rendered or fully SPA. I don't understand how this applies in general.

> Having done desktop development for a number of years, the worst turds I've seen are in that space and the SPA brings them all to the web which is one of the most hacked up evolutionary disasters we have ever created.

As I mentioned before, the difference is that unlike desktop development SPA world is still evolving and there is no thought leader in how to do this. If we were given back in 2012 a definitive framework with all build tools in place, that would look like the typical desktop framework. However, we are spectators in this evolving space. That is the nature of open development and open source. Compare that with WPF, WinForms or any other Windows platform UI development environment.

> Really our responsibility as engineers, architects, developers is to give the user the best experience and that means the fastest and most reliable one. SPAs are neither. KISS is a mentality we should be using and I can build a better user experience without SPAs.

I disagree with this, it is a general statement.