9 ms·

Extra complexity. If you're building something simple, it's often quicker or easier to reason about if you just put it together with a basic web framework. But

by mxxx 10y ago

Extra complexity. If you're building something simple, it's often quicker or easier to reason about if you just put it together with a basic web framework. But if you're doing anything reasonably advanced or specifically need the "application-like" feel of an SPA, I don't think there are really any compelling arguments against it. Maaaaaybe the size of the initial payload, but there are strategies to mitigate against that anyway.

mxxx 10y ago
Oh, actually, one thing that I'm not 100% sure about is accessibility.
- rch 10y ago
  That's the number one issue that comes to mind, particularly for government work.
sfeng 10y ago
Just to provide a counter point, I find it much simpler to work with SPAs. You can build a clean API which only deals with JSON, and ship a separate frontend which is deployed reliably to a CDN. I can see why 'one thing' would seem simpler than 'two things', but like functions and modules, often having more makes things simpler to grok.
- mxxx 10y ago
  I'd be inclined to agree with you once the application has reached a certain level of complexity. If you're doing anything vaguely complicated around how you fetch/display/mutate your server data, then it can be a much cleaner pattern to keep a REST/GraphQL API separate from your client logic. But on a super simple app (static site, basically), you have to deal with the overhead of the things that @aclimatt is referring to (browser history, routing, loading states etc) that basically come out of the box in your browser before you break them.
mozumder 10y ago
I mean, I was able to build my own single page app in a few hundred lines of javascript front-end code, and a few hundred more lines of javascript for some interface elements. See: https://www.futureclaw.com https://www.futureclaw.com This also includes server-side rendering of the initial page. I didn't use Angular or React or Ember or any other framework.. I just went ahead and made my own with ES6. The latest Javascript ES6 makes all of this easier. If you're worried about complexity, just ignore the existing frameworks and do it from scratch.
- couchand 10y ago
  That's pretty neat, sure, but you've also done a pretty good job proving @aclimatt right on a few points: Broken back button: check. Broken scrolling: check. Broken accessibility: check.
  - mozumder 10y ago
    A lot of that is platform dependent. You'll have to weigh how much these affect overall user experience on various browsers and how it affects your business. I don't recommend people optimize for all platforms, because you will spend forever on it. It's perfectly fine to say "Ok, my site is only for iPhone users on iOS 10+ and Windows Edge 12+." or some limited subset of users.
    - akie 10y ago
      It would be more honest to acknowledge the downsides, and say "this site is only for iOS 10 or IE Edge users without disabilities and who never use the back button".
    - Isofarro 10y ago
      I'm not convinced that introducing the limitations of native apps to a non-native platform is a benefit, or a feature that makes the non-native platform more competitive.
WalterSear 10y ago
It's certainly quicker to build something simple without it, but if the site needs to be maintained, things are much easier if your data is separate from your view.
wanderr 10y ago
Even if all your code resides on the backend, there's no reason why you can't maintain a similar separation between front end/display logic, and backend logic where data can be passed between the two layers but neither makes assumptions about the other.
morgante 10y ago
That's only really true if you're building your first SPA. Since I build so many SPAs, at this point I can spin up and work on a new one much faster than I could for a non-SPA.
- deleted 10y ago
  [deleted]

by mxxx 10y ago

mxxx 10y ago

Oh, actually, one thing that I'm not 100% sure about is accessibility.

rch 10y ago
That's the number one issue that comes to mind, particularly for government work.

sfeng 10y ago

Just to provide a counter point, I find it much simpler to work with SPAs. You can build a clean API which only deals with JSON, and ship a separate frontend which is deployed reliably to a CDN. I can see why 'one thing' would seem simpler than 'two things', but like functions and modules, often having more makes things simpler to grok.

mxxx 10y ago
I'd be inclined to agree with you once the application has reached a certain level of complexity. If you're doing anything vaguely complicated around how you fetch/display/mutate your server data, then it can be a much cleaner pattern to keep a REST/GraphQL API separate from your client logic. But on a super simple app (static site, basically), you have to deal with the overhead of the things that @aclimatt is referring to (browser history, routing, loading states etc) that basically come out of the box in your browser before you break them.

mozumder 10y ago

I mean, I was able to build my own single page app in a few hundred lines of javascript front-end code, and a few hundred more lines of javascript for some interface elements. See: https://www.futureclaw.com https://www.futureclaw.com This also includes server-side rendering of the initial page. I didn't use Angular or React or Ember or any other framework.. I just went ahead and made my own with ES6. The latest Javascript ES6 makes all of this easier. If you're worried about complexity, just ignore the existing frameworks and do it from scratch.

couchand 10y ago
That's pretty neat, sure, but you've also done a pretty good job proving @aclimatt right on a few points: Broken back button: check. Broken scrolling: check. Broken accessibility: check.
- mozumder 10y ago
  A lot of that is platform dependent. You'll have to weigh how much these affect overall user experience on various browsers and how it affects your business. I don't recommend people optimize for all platforms, because you will spend forever on it. It's perfectly fine to say "Ok, my site is only for iPhone users on iOS 10+ and Windows Edge 12+." or some limited subset of users.
  - akie 10y ago
    It would be more honest to acknowledge the downsides, and say "this site is only for iOS 10 or IE Edge users without disabilities and who never use the back button".
  - Isofarro 10y ago
    I'm not convinced that introducing the limitations of native apps to a non-native platform is a benefit, or a feature that makes the non-native platform more competitive.

WalterSear 10y ago

It's certainly quicker to build something simple without it, but if the site needs to be maintained, things are much easier if your data is separate from your view.

wanderr 10y ago

Even if all your code resides on the backend, there's no reason why you can't maintain a similar separation between front end/display logic, and backend logic where data can be passed between the two layers but neither makes assumptions about the other.

morgante 10y ago

That's only really true if you're building your first SPA. Since I build so many SPAs, at this point I can spin up and work on a new one much faster than I could for a non-SPA.

deleted 10y ago
[deleted]