7 ms·
First of all, thanks for the nice writeup. I hate that comments tend to hone in on nitpicking, but so it goes. My apologies in advance. > If you're just starti
by tspike 11y ago
First of all, thanks for the nice writeup. I hate that comments tend to hone in on nitpicking, but so it goes. My apologies in advance.
> If you're just starting out with a new web application, it should probably be an SPA.
Your reasoning for this seems to be performance (reloading assets), but IMHO the only good reason for using a single-page app is when your application requires a high level of interactivity.
In nearly every case where an existing app I know and love transitions to a single-page app (seemingly just for the sake of transitioning to a single-page app), performance and usability have suffered. For example, I cannot comprehend why Reddit chose a single-page app for their new mobile site.
It's a lot harder to get a single-page app right than a traditional app which uses all the usability advantages baked in to the standard web.
- AdeptusAquinas 11y agoThis is totally true. If you're just starting out, chances are you are not (or should not be) making any sort of application where the performance increases by operating as a SPA will be even be noticeable compared to a standard server app. Plus, I'd argue that you won't really understand what a SPA adds (or takes away) unless you are thoroughly familiar with the traditional model. Finally, at the end of the day traditional apps are just a lot easier to put together even compared to the latest SPA frameworks, especially if your server side tech is something like Ruby or C#. A beginner will be better served by getting something nice up quickly, before attempting to do it the 'purist' way and possibly getting discouraged by the difficulty.
- deleted 11y ago[deleted]
- joepie91_ 11y agoI fully agree with this. SPAs are for webapps, not websites. For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for. Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website.
- baddox 11y agoThe title and article are also for web apps, not web sites.
- tomjen3 11y agoMaybe not all my clients support javascript, but substantially all I care about do. I even take advantage of this on my blog by rigging a field in the comments section to not be visible for users but be visible for spammer bots, so that they will fill it out and the software can auto-reject it. Works very well.
- dorgo 11y agoI enable JS for sites I feel are valueable for me. The first impression is always without JS. If navigation-buttons dont work without JS - I just leave.
- oldmanjay 11y agoif you self-select into the group that isn't cared about, then do you expect your leaving to be cared about? i ask only because i'm puzzled as to the purpose of your reply.
- dorgo 11y agoI am too small a group to be cared about. But in my opinion only poor designed websites use JS for layout or navigation. And the way back to the search-engine is always just one mouse gesture away. JS = code written by someone with not neccessarily my best interests in mind running on my computer.
- sumedh 11y agoHonest question - What are you trying to prove by not enabling JS by default?
- bottled_poe 11y ago
- Silhouette 11y agoThis was one of the points that stood out for me in the article too, also because I strongly disagreed with it. There is nothing inherently wonderful about doing everything client-side. You get a much more limited range of languages and libraries to work with. You get to use overcomplicated build and deployment processes with ever-changing tools. You get to reinvent the wheel if you do want to use things like URI-based routing and browser history in a sensible way. In many cases you are going to need most of the same back-end infrastructure to supply the underlying data anyway. Also, it's tough to argue the SPA approach is significantly more efficient if it's being compared with a traditional web app built using a server-side framework where switching contexts requests exactly one uncached HTML file, no uncached CSS or JS in many cases, and any specific resources for the new page that you would have had to download anyway. Of course some web apps are sufficiently interactive that you do need to move more of the code client-side, and beyond a certain point you might find it's then easier to do everything there instead of splitting responsibilities. I'm not saying everything should be done server-side; I'm saying different choices work for different projects and it is unwise to assume that SPA will be a good choice for all new projects.
- arikrak 11y agoI often find many ajaxy effects on websites don't work work. For example, when I click to expand a comment in Quora, it often fails and I find it much quicker to just open it in a new page.
- thekingshorses 11y ago> I cannot comprehend why Reddit chose a single-page app for their new mobile site They should but not the way they are making it. It should be server side render for initial page (not just home page but any page). And mostly changing content through AJAX when you navigate between pages. SPA is hard specially when it comes to usability. One of the biggest issue I see with SPA is going back. Browser handles back history pretty good for non-SPA. Replicating similar behavior in JS in not easy. Reddit SPA should be like this with server side rendering. http://reddit.premii.com/ http://reddit.premii.com/
- Scarbutt 11y agoIf you need a backend, starting with a SPA has one strong point, decoupling, you can leave your backend unmodified and start writing that native iOS, Android client or desktop client when needed it.