4 ms·

This article is self-defeating based on its own content and the experience I have developed over the last 20 years. I beg the author to deal with a typical rea

by setquk 8y ago

This article is self-defeating based on its own content and the experience I have developed over the last 20 years. I beg the author to deal with a typical real world application. Not low scope startup stuff but the thousands of 500+ endpoint typical enterprise stuff that 80% of the market actually comprises. This does scale out to the startup and web stuff as well. This approach introduces a lot more pain from experience: 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. 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. 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. 4. They are incredibly difficult to test. Go try testing a big SPA with selenium for example. 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. Greg Navis knows what he's talking about.

jarym 8y ago
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 :)
- setquk 8y ago
  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?
  - jarym 8y ago
    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!
    - setquk 8y ago
      What sophistication is this I can't do trivially without it?
      - jarym 8y ago
        For example - take a grid like this one: https://www.smartclient.com/smartclient/showcase/?id=gridHeaderSummary 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=userDefinedHilites 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.
        setquk 8y ago
        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.
jhabdas 8y ago
KISS is one way of putting it. But another way is XP (eXtreem Programming) which suggests YAGNI so we don't have to pitch an entire system in 5 years because it takes just one person about 5 years to build it.
tpetrina 8y ago
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.
- Deestan 8y ago
  > The rest is not even wrong. Please elaborate. Your rude dismissal is not informative.
  - tpetrina 8y ago
    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.
romanovcode 8y ago
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.
- bestest 8y ago
  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.).
  - romanovcode 8y ago
    > 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.
    - bestest 8y ago
      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.
krona 8y ago
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.
- setquk 8y ago
  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.
mercer 8y ago
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).
bestest 8y ago
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.
- candiodari 8y ago
  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.

by setquk 8y ago

jarym 8y ago

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

setquk 8y ago
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?
- jarym 8y ago
  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!
  - setquk 8y ago
    What sophistication is this I can't do trivially without it?
    - jarym 8y ago
      For example - take a grid like this one: https://www.smartclient.com/smartclient/showcase/?id=gridHeaderSummary 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=userDefinedHilites 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.
      - setquk 8y ago
        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.

jhabdas 8y ago

KISS is one way of putting it. But another way is XP (eXtreem Programming) which suggests YAGNI so we don't have to pitch an entire system in 5 years because it takes just one person about 5 years to build it.

tpetrina 8y ago

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.

Deestan 8y ago
> The rest is not even wrong. Please elaborate. Your rude dismissal is not informative.
- tpetrina 8y ago
  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.

romanovcode 8y ago

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.

bestest 8y ago
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.).
- romanovcode 8y ago
  > 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.
  - bestest 8y ago
    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.

krona 8y ago

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.

setquk 8y ago
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.

mercer 8y ago

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

bestest 8y ago

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.

candiodari 8y ago
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.