Comment by mxxx | Hacker News Reader

Comment by mxxx | Hacker News Reader

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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

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

Reply on news.ycombinator.com