24 ms·

You probably don't need a single-page app

• noir_lord 8y ago
  > Frameworks like Rails, Phoenix, Lavarel, etc. have been around for a while and they are very stable. Laravel is stable in production but they break backwards compatability all the time and not always in major versions. Symfony is much better about it.
• exabrial 8y ago
  If latency drives your conversion, then SPA is [probably] not for you.
• elizabeth_olu 8y ago
  https://www.elizabethblog.com.ng/2019/02/donald-trump-reacts-to-new-evidence.html https://www.elizabethblog.com.ng/2019/02/donald-trump-reacts...
• ttty 8y ago
  Normally you'll always need to add something interactive, therefore js. To do that with server side rendering you'll couple the client side to the server side. For example the server has to send a tag with a class name that the client also is aware of that. Therefore you have 1 component, where half is on server side and half of on client side, which in my opinion is not maintainable.
  • hskaw 8y ago
    This is unrelated to the article. Many webpages, like HN, use JS but are not SPAs.
    • adtac 8y ago
      I think old.reddit.com's interface is more user-friendly than HN's. Why should I leave the page to write a comment? Avoiding JS just for the sake of avoiding is just blind fanaticism under the pretense of being faster and more lightweight. (The new reddit redesign is a resource hogging abomination riddled with needless SPA bullshit, but the old reddit design was pretty clean and minimal and yet an SPA.)
      • robjan 8y ago
        The old Reddit design isn't really an SPA. It's just server rendered with a bit of Ajax for interactivity
        • adtac 8y ago
          I think the definition is a bit murky there. I can do a _lot_ of things on a Reddit page without a refresh: add comments, delete comments, edit, sticky, report as spam, save, hide the post, view the contents of the post (if it's an image), crosspost to other subs, etc. I understand that a true SPA would never require a refresh for anything, but this comes pretty close.
  • nkozyra 8y ago
    You can get surprisingly far without Javascript, imo. Interactivity means a lot of different things, do you won't always need to have coordinating front and back ends
  • pmlnr 8y ago
    > Normally you'll always need to add something interactive Especially in news, articles, longreads, right? /s Most of the internet content would be perfectly fine without interaction, or with ordinary, oldschool POST forms
    • franzwong 8y ago
      News web site can return part of the page (e.g. news article) to decrease TTFB, and then load less important content (e.g. news recommendation) after. As author said, it is tradeoff.
      • pmlnr 8y ago
        ... or inline all in one html on server side and send it down at once?
    • jamespollack 8y ago
      ...? "Most of the world is fine with whale oil lamps, who needs electricity" Try a really good interactive article from the New York Times. You'll have a much more impactful experience than if you read a blurb about the same thing on your RSS reader.
    • ng12 8y ago
      That's why I think these conversations are so meaningless. My job would be a nightmare if I didn't use SPAs. It's all about the right tool for the job.
• nkozyra 8y ago
  While I've long been more comfortable with server rendered pages, I feel like we're oversaturated with this sentiment. I don't think it matters all that much. The message is build with what accomplishes your goals and works with your team's skills. The notion that SPAs are only good for certain types of applications or organizations doesn't make much sense to me. Building server-generated web sites works faster for me because I'm still more comfortable with it. SPAs make concessions but so do server generated apps.
  • sigfubar 8y ago
    > The message is build with what accomplishes your goals and works with your team's skills. Unfortunately most teams cannot be trusted to pick the right tool for each job without overcomplicating the planned implementation. Ego and the yearning to do “cool stuff” conspire to derail projects that could have been built without fuss using simpler tools.
    • marcinzm 8y ago
      >Unfortunately most teams cannot be trusted to pick the right tool for each job without overcomplicating the planned implementation. Ego and the yearning to do “cool stuff” conspire to derail projects that could have been built without fuss using simpler tools. Force them to only use simple tools and the good ones will move elsewhere because they know that being stuck on just the simple things is going to limit their careers. edit: And losing them will probably cost you more project velocity than you'd ever gain with different tools.
      • sigfubar 8y ago
        Good riddance! A project is undertaken to achieve some specified result, not to advance a career or learn some new tool. Don’t get me wrong: those lofty things are welcome when they occur as a byproduct of developing commercial software, but these cannot be the driving factor behind decisions that affect the bottom line.
        • 8y ago
• fxfan 8y ago
  I need a quick primer on how spa does seo? Do they "server-render" the individual instances of pages too?
  • hskaw 8y ago
    Try to use Discourse with JS off, for example.
  • empthought 8y ago
    Search engines execute the JavaScript...
    • Veen 8y ago
      Google does, but not reliably, especially for newer (ES6) JavaScript features. Bing and DuckDuckGo do not render complex JavaScript apps. Neither does Yandex, I believe.
  • armandososa 8y ago
    Yes. Take a look into Next.js which does this using React and it's really simple to start with.
  • 33degrees 8y ago
    In theory google can crawl SPAs, but in practice it doesn't work all that well. Server side rendering is one solution, a pre-rendering proxy is another.
  • nlh 8y ago
    Not by default. The big frameworks are first and foremost client side frameworks, which means in an extreme case the server is just sending down <html><script src=.../></html> (basically), and the client framework handles all of the rendering/data fetching. BUT — with a bit of work, you can set things up to do server side rendering. It requires you use Node at some point in your server stack, and you essentially call the library (on the server) and run their RenderToString function (each has a slightly different implementation). There are frameworks for this (next.js, nuxt.js) or you can roll your own - it’s not terribly complicated.
• tyingq 8y ago
  I'm more interested in the future of "you probably don't need a native app". It feels like browsers are closing the gap pretty well with things like IndexedDB, offline features, WASM, etc. Still a ways off, but seems like it's getting there. I do worry, though, that it's not really in Apple's or Google's best interest to move that along.
  • IloveHN84 8y ago
    Native will always be the best solution... Because it's native.
    • tyingq 8y ago
      Technically best doesn't always win the market. I'd love not writing 3 versions of every piece of functionality.
      • AnIdiotOnTheNet 8y ago
        How's that working out when there's more than one browser you have to account for? What's the difference between polyfill or some framework, and something like Qt or SDL? Or I suppose we could just all use chromium, but we could also just all use Windows.
        • tyingq 8y ago
          I have to write it for the web already. Writing a native Android and a native iOS app is additive if the web version is "good enough". There's no scenario where I only have to write two native apps. Perhaps there is for other people.
          • AnIdiotOnTheNet 8y ago
            Consider that maybe there are uses for software where the web isn't necessary and isn't even the first choice. You're a hammer, so everything is a nail. The reality is that the web is a horrible choice for a whole lot of things. It's a document platform with parts of an application platform shoe-horned in and bolted on, and the result looks like a garbage fire to people who come from the land of native software.
• patientplatypus 8y ago
  This feels like clickbait, but just as an aside there's nothing that says you can't do server side rendering and react. Next.js is what I'm using on my current project and it's server side out of the box. So you have text rendered in source like you would with a traditional server side app with the benefits of SPA. So at least one of his nitpicks sounds like he didn't do his homework.
  • maxencecornet 8y ago
    Of course you can use server side rendering with Next.js,but it adds some work/complexity With a server rendered website, you don't have to do anything
    • patientplatypus 8y ago
      I mean, not really? When you want a new page you create a react component in the "/pages" directory. "/pages/hello/index.js" routes to "mysite.com/hello", and "/pages/hello/there/world/index.js" routes to "mysite.com/hello/there/world". The pages are served from a node.js site. The newest version (8) comes with lambda rendering but you don't have to use it if you don't want. This is pretty simple to reason about honestly.
• PretzelFisch 8y ago
  I have always used SPA for line of business applications. The SPA SEO request seems like a red flag that the wrong approach has been taken.
• alexandernst 8y ago
  The main problem with SSR is that the moment you want to do something a little bit outside of the-happy-path of your framework o choice, you're knee deep into sh. Let me give you the simplest possible example. A form with multi-dependant inputs: you select an option from a dropdown, and depending of the choice you made, you see another dropdown with some options, or maybe an entire new set of inputs. Maybe there is a button that will open a popup with another form, dynamically generated based on what you choose. Or maybe there is data you must dynamically fetch from the server, based on some combination of actions that the user did. You can play the ".show()" and ".hide()" game with plain JS, but if you have more than 5 inputs, I promise you, you'll be really sorry for choosing that method. You can also "inject" somehow any SPA just into that particular view in your project, but then you'll be already dealing with the cons of both SPA and SSR. It doesn't pay off. I have been doing all types of FE and BE development, and what has given me the best results is making the BE a REST API and doing the rendering on the frontend. Just my 2 cents.
  • save_ferris 8y ago
    This is where the hybrid approach they mention in the article really shines. Embed front end frameworks where you need it, and stick to SSR where you don't. It doesn't have to be a binary choice.
    • alexandernst 8y ago
      Yes, that's what I said in my comment. But if you choose that path, you automatically have to deal with the problems from both worlds. "How do I configure webpack?", "Why is babel not working?", "How do I do _this_ or _that_ in React or Vue or whatever?". Going the hybrid approach is choosing to deal with the problems from both worlds.
      • save_ferris 8y ago
        But configuring webpack is usually just an initial set-up cost. I've never had to go back and rejigger webpack once it's set up. You might have to touch it again if you make major changes to how you serve assets or something, but these one-time costs are part of development. > Going the hybrid approach is choosing to deal with the problems from both worlds. This is true of any technology. Every framework, language, library, etc. comes with a cost in setup, design, maintenance, etc. For us, the cost of dealing with problems from both worlds is much, much lower than trying to shoehorn a SSR app with SPA-like functionality. By limiting the size and scope of the SPA, you avoid a lot of the really hairy state management problems that can arise when an SPA is trying to keep track of too much state.
• save_ferris 8y ago
  This. So much this. My company (4,500+ people) ordered all products in their portfolio (~12 web apps) to migrate to SPA front ends about a year ago as a way to stand out from our competitors, and boy has it been painful. Prior to that initiative, we had been using the hybrid approach mentioned in this piece, embedding SPAs only where necessary and sticking to SSR everywhere else, which worked really well. Since the announcement, our productivity has diminished dramatically since so much of our time is now focused on re-working functionality that already exists into an SPA, and it's completely unnecessary. Not only that, but extending these UIs will take more time in the future than their SSR versions due to the added complexity of the front end frameworks, and we're definitely going to make mistakes along the way that we weren't making before. It drives me crazy to think that some exec came up with SPA-ing everything as a sales pitch to clients, when 99.9% of our clients have no idea what an SPA is. And the amount of money being spent on turning already-working apps into SPAs is astronomical.
  • marktangotango 8y ago
    I don’t disagree here at all, but I would note that generally server side templating is often a mish mash of business logic, view logic, accessing query string and session parameters, and whatever server side Singleton/globals available in the template context, that becomes horrific spaghetti in no time at all. Compared to client side rendering discrete web requests with minimal templates; you usually get much better separation of logic, view, and code than the typical serverside solution. There is a happy medium where server side services are encapsulated to separate concerns in a similar manner, but it rarely happens, even with competent, experienced, well intentioned teams.
    • dangoor 8y ago
      This separation of concerns is also good if you have both a web app and native mobile app. The server side ideally puts forth an API useful for both;
      • sbov 8y ago
        Our controllers use APIs. This was common before SPAs became all the rage.
• danielovichdk 8y ago
  I tried the other day, yet again, to give it a go. You know, firing up VS Code and make an app with express, node, react bla bla bla. Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. The hundreds of possible directions you can go in, in terms of frameworks, packages and what not is ludacris. I stopped working when my node modules directory topped 60mb and I still hadn't made a data layer. Good luck fixing that. I'd rather keep my code and tooling simple and clean.
  • s_y_n_t_a_x 8y ago
    You could use Blazor to export to webassembly, but it includes the entire .NET runtime, so the payload is huge. It's a bit silly to say you quit when you topped 60mb in your node modules directly, something you never have to look at and doesn't represent what gets built in to the final app. There's tons of dependencies when dealing with the .NET toolchain. There are hundreds of directions you could go in, and I consider that a good thing. There are choices, but there are recommended paths for beginners as well. It sounds to me like you're hating on a toolchain that you don't have any experience in.
    • caseymarquis 8y ago
      While I'm excited about WASM and .NET on the frontend, I don't think Blazor is quite the solution I want. (Getting there though!) If Evan You, Anders Hejlsberg, and two computers were all locked together in a room for a month or so, whatever emerged from that room is what I'm looking for. Razor syntax has always felt clunky to me, and I tried very hard to like it when I first started with branching into web development from .NET. I'm hoping that someone will use WASM very effectively to create some XYZ framework that's revolutionary. Then, Microsoft can do what they did with Java and make a version of it improved by hindsight. I don't think that Razor syntax would be the basis for whatever that is.
    • danielovichdk 8y ago
      I understand the toolchain juuust fine. I have been making HTTP and browser applications for two decades. The technology landscape is absolutely ridiculous if you want to do things for the web. Each browser has its own standard, chrome is the new IE6, the industry is hacking together assembly languages to port from other technologies, preprocessors, minification, state and what have you not. The web today had been tweaked beyond recognition and while the industry is doing so, most of us forgot the beautiful platform that resides underneath. I love HTTP, HTML, CSS and JavaScript, I really do, but I really believe there is a huge tendency of amateurish approach towards making the web a better and more standardized place. Back in the day, we had much less choice, and that made working with the web a lot more joyful.
• wrestlerman 8y ago
  I have the same opinion. Building SPA is f* hard and time-consuming. But it depends. If you know how to build SPA fast, then, by all means, go that route. (As a solo dev or small team) I use Rails, but Rails views are a disaster. You can use a lot of different patterns/gems, but still, logic is highly coupled with the view layer. Personally, I like Phoenix approach with templates + views. But still writing script tags makes me cringe a little bit. But I wouldn't discourage people from using SPAs, though. If you are gonna have a lot of buttons, modals, different tables, charts, forms and stuff like that, I would go SPA. Or first serverside -> SPA. Especially, when you are working in the team, it's so much easier to tell one person to craft this json api and another to craft this design with a consumer for the json api. That become long... in short: if you have a small team or solo go server side 99%. If you have a big team or app that's gonna be very heavy UI -> go full spa or go server(mvp) -> spa
  • 64738 8y ago
    Take this with a grain of salt, as I only recently came across it and haven't used it, but the Trailblazer framework looks like it has a good way of getting logic out of the views.
    • fyfy18 8y ago
      I've been using parts of it on most Rails apps I've worked on for the last few years. The form object pattern (Reform) really helps when you need to update the same model in different places with different validations. For example maybe an Order only needs a price when it's created, but needs a invoice number (and some other validations) when marked as paid, but an admin should be able to override those validations at any stage. If you are doing something like that with standard Rails the model is going to end up as an untestable mess, where as the form objects can be tested on their own. My only complaint is that the creators of Trailblazer really don't seem to like Rails, so trying to get them to both work together can sometimes be a bit tricky. And the documentation is lacking if you want to do some more complicated things.
      • 64738 8y ago
• 1ste 8y ago
  Not very convincing. React was introduced in 2013 and angular 2 was created in 2015. The only server side rendering I'll be doing in the future is with the likes of nextjs or similar.
  • a_wild_dandan 8y ago
    Yeah, I start with an SPA and adapt to the use-case. It either needs to be a SPA, or SPA -> SSR is easy (via Gatsby/Next.js). The other direction though, seeing projects grow from SSR -> interactivity/SPA is usually a horrifying display of highly-coupled code spaghettification.
    • virtualwhys 8y ago
      > Yeah, I start with an SPA and adapt to the use-case. It either needs to be a SPA Aha, by mistake you corrected your grammar! HNers cargo cult everything, including grammatical mistakes like "an SPA" ( see literally everywhere in this thread). Just say it out loud, "I start with an SPA", does that roll off the tongue? No, neither does, "I'm going to buy an sailboat". However, "It either needs to be a SPA, ..." is totally natural. While this comment may not seem on topic/useful, it's a useful meta comment -- please don't take offense.
      • edwardhusarcik 8y ago
        SPA isn't pronounced "spa" but S-P-A thus an SPA is more likely correct. See "an FBI agent" for an example.
        • virtualwhys 8y ago
          Hah, the relief! That was driving me crazy, thank you for clarifying the usage. I've only seen it written and blindly assumed "spa", not S-P-A. Now I can read SPA posts without cringing...
          • edwardhusarcik 8y ago
• caseymarquis 8y ago
  For new development, I reach for SPA tools (like VueJS with Webpack) fairly quickly. The reasons for this are: 1. Reusable web components. 2. Clear separation of backend and frontend logic. 3. Using the latest version of javascript. I really like HTML/CSS/JS as tools for building GUIs, but I feel HTML/CSS specifically suffer from the inability to make components. I think there are definitely instances where there is no need for these tools. I would genuinely like to know how to manage the items listed above when this is the case. ie Recommended tools for when I go "SPA seems like overkill for this... what are my other options for this functionality?"
  • robin_reala 8y ago
    If you want to stick to JS, then Node + Express is a fine stack. You can always use React to add functionality to specific parts of the site if you find you need to later.
  • mattferderer 8y ago
    Once you know how to use the tools (Webpack with Hot Module Reloading, React/Vue/Whatever, Storybook, TypeScript), it is hard to work without them. They offer a ton of advantages, especially speed of development if you have a clear separation of frontend & backend logic. If you can mock your backend & develop the front end all by itself without any other code needed, you can go at crazy fast speed. You are also able to focus on UX/UI without needing to think at all about the backend. I feel there is a ton of value in this, whether or not your app is a SPA or not. I think tools like Gatsby will make building actual SPAs easier down the road. They offer huge speed advantages the longer someone is on the site. Though one could gain a lot of these with just preloading content & HTTP/2 as well. As the article said "It all comes down to tradeoffs". I would also argue what resources you have available & the value of speed on your site.
  • crooked-v 8y ago
    You may want to look at Next.js, which is an SSR/SPA framework using React components that also has a "render entirely to static files" build mode option.
  • whytaka 8y ago
• miguelrochefort 8y ago
  Building a SPA is not more difficult than SSR.
• valeriobo 8y ago
  Totally agree with the article, the spa hype has produced a lot of crappy slow web sites and crippled productivity of many teams for years. I think ppl in the industry are way too young and have the bad attitude to nod add tools in their belt but keep only the last one that has hype. Spa are like applet or Silverlight, just different tech, same goes for ws* vs rest api and so on...
  • AnIdiotOnTheNet 8y ago
    > I think ppl in the industry are way too young and have the bad attitude to nod add tools in their belt but keep only the last one that has hype. The current culture is to only keep a job for ~2 years before moving on, why wouldn't they adopt that attitude?
    • valeriobo 8y ago
      True, if you do not stay long enough to feel the consequences of your decision you do not learn from those years. We do not usually hire ppl that change job that often, but we are not in a silicon valley kind of enterprise
    • krferriter 8y ago
      Because studies have shown that's the only reliable way to get appropriate salary raises. If companies properly managed salaries for existing employees that wouldn't happen so much.
• ccalvert 8y ago
  I have modest skills as a developer. I was trying to convert an old static web site into something more interactive. Without really thinking it through, I started building a SPA. I got stuck on the SEO part. I found it innately complex, but the real trouble came from trying to bring together the disparate sections of the old static site while preserving and abetting SEO. One day I just ditched the SPA and rebuilt the whole architecture with NodeJs and Express. I was done in a few days. It could have gone even faster, but the original static site was really a mess with years of accumulated bad decisions embedded in it. I know this is just one data point and not really proof of anything. Nevertheless, the linked article made a lot of sense to me. Most of the bulleted points resonated with me, but none more than the SEO issue. There are solutions to the SEO issue, but I personally did not find them easy to implement. If I were part of a big professional team, and we really needed a SPA, I would have called this one differently, but I was working on my own, and I didn't really have the sense at first to see that I didn't need a SPA to achieve my goals. I was perhaps a bit too susceptible to the hype without enough experience to really understand the issues involved.
  • WrtCdEvrydy 8y ago
    React Server Side rendering with Next.js is the best of both worlds. You get streamed JS, with pre-rendered HTML for SEO.
    • zhobbs 8y ago
      I second this. I use Next.js with lambda, so I don't have to worry about servers. Works great...
    • ccalvert 8y ago
      Thanks. This does look interesting. It's hard to keep up with all the frameworks, but this does look like something worth investing some time in. I'll check it out.
  • qudat 8y ago
    As a FE engineer, SEO is the one area of SPAs that does feel like the wheel is being reinvented to accommodate its existence. It's unfortunate, there are solutions, but it's a little annoying to deal with.
• sametmax 8y ago
  Or microservices. Or nosql. Or containers. Or graphql. Free tech is not zero cost tech. Size your stacks to your actual needs.
  • fma 8y ago
    I happened to watch a conference talk on YouTube by the director of infrastructure at Netflix. He closed it out by saying, yes we open source everything, and yes this solution works for us. But just because we do it doesn't mean you should. Do what works for you. But in reality...I only need it because people on the other side of the interview table expects every engineer to have 3-5 years experience of x,y, z.
• petilon 8y ago
  I couldn't disagree with this article more. Developing SPAs is easier than server-render applications. The problem is React, Redux, and other such libs make this more complicated than necessary. React is all about surgically making the smallest possible change in the DOM to refresh the page. But is that really needed? Most of the time it is not. Why not re-render the whole page? This is what happens in the case of server-render applications any way, right? Turns out 99% of the time it is performant for the SPA to rerender the whole page. Instead of Angular and React, if you use simple libraries such as UIBuilder ( https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder ) and MVC router ( https://github.com/Rajeev-K/mvc-router/ https://github.com/Rajeev-K/mvc-router/ ) you can build simpler applications that work well and are super easy to develop and maintain. Each of those libs is less than 500 lines, so super easy to learn and use. This article says traditional web servers are stateless, but in the case of SPAs servers are stateful. The opposite is true. Traditional web servers have session state, but in the case of SPAs the servers can be stateless because all servers are responsible for is persistence and query/search. This article says maintaining browser history is a mess in SPAs. Not true. The same MVC architecture that works so well on the server can be done just as easily on the client, see this lib: https://github.com/Rajeev-K/mvc-router/ https://github.com/Rajeev-K/mvc-router/ This article says server-rendering has fewer more mature tools. That may be true. There are so many new tools for SPAs. But you can ignore them and build SPAs trivially using the libs mentioned above. This article says server-rendering is better for SEO. Not true anymore. Google and Bing crawlers now execute javascript to crawl your content. This is more work for Google and Bing but not more work for you. If you know how to do it SPAs are the easiest and best approach because all the server needs to do is implement persistence and query/search using a REST API. If you later need a native mobile client this approach is already more compatible with mobile than if the server renders HTML in addition to persistence and query/search.
  • s_y_n_t_a_x 8y ago
    You don't need React, Redux, and other such libs, true. But you're missing the point of them. It's to prevent the problems that cropped up after years of jQuery development. Too many side-effects and poor state management lead to very hard to find bugs. When you follow the redux (or whatever state lib) flow you prevent a lot of these issues.
• johnchristopher 8y ago
  > Gulp, CoffeeScript, BackboneJS, and SASS, all of which have been superseded by newer tools. Avoid the Javascript fatigue by not relying so much on Javascript! What ? These are all javascript things, right ?
  • burlesona 8y ago
    That was his point. The rails stuff he learned five years ago is all still considered good practice, but the JavaScript stuff he learned (listed above) is now considered antique.
    • johnchristopher 8y ago
      Oh, thanks. I somehow totally misread that and thought he meant those JS tech were still relevant.
    • buu700 8y ago
      I think the general point holds up, but why is sass in that list? I know some newer alternatives are used with React nowadays, but sass is still very much a best practice in general as far as I'm aware. (If he means SASS vs SCSS syntax, I recall using SCSS ~8 years ago, so it's an odd choice to include either way.)
    • jamespollack 8y ago
      So... people who hate learning should use SSR? Once you've used grunt, using gulp is not a big logical jump. Then to webpack. Whatever, they're just build scripts! Roll your own shell scripts if you want! A day to learn them, or a lifetime of being a hater.
• dsego 8y ago
  One problem we're having with the hybrid approach (Laravel + Mithril) is not being able to reuse common UI components between php & js rendered parts. Laravel has blade templates, and mithril is coded similarly to react. The other problem is deciding which to use when starting a new feature or section. A page may start out fairly static but end up needing a rewrite when the specs change and start requiring more dynamic UI elements.
  • scarface74 8y ago
    I would rather change a page if and when it is needed by a new feature than over engineer up front.
    • a_wild_dandan 8y ago
      And I would rather over-engineer a bit now to make feature additions trivial & rewrites unnecessary. Different stroke for different folks, I guess.
      • scarface74 8y ago
        But you don’t know what features you may need or whether the abstractions will make sense until you have two or three examples.
        • a_wild_dandan 8y ago
          Definitely, which is why I leave room for those unknowns with a some preemptive over-engineering. Worst case, those (well-known, general, popular) abstractions don't get used and the project works. Best case, they really save my butt and the project works. Worth it either way, imo!
    • hombre_fatal 8y ago
      Well, the thing is that you don't know if you're "over engineering" up front. That's the whole challenge. And rewriting down the road because of the wrong gamble can be very costly. Make the wrong bet enough times and you'll see that it's not over-engineering but just engineering for changing requirements. A classic example is thinking it will be simpler to avoid React and use a few .show()/.hide() toggles. Simple at first. Then as you take on complexity, you start to feel like the lumberjack who thought he could save time by skipping the axe sharpening.
• pcmaffey 8y ago
  The concept of a SPA is a total hack of web patterns. I predict in a few years we'll refer back to SPA's the way we do now to AJAX or DHTML. We're getting closer to the best of both worlds, where we SSR pages and then "hydrate" them with JS components. The tooling around this isn't great yet, but it's definitely all there.
• k__ 8y ago
  I simply prefer them because I think their architecture is simpler than some frontend/backend mixed HTML stuff. JAM-stack etc. just create static html/css/js and deliver it over a CDN of your choice, then hook into the services as you need them...
• subpixel 8y ago
  On the one hand, site like https://dev.to/ https://dev.to/ that are built in Rails and rival the speed and performance of any _static site_ support the argument that you can just use the tools you know. On the other hand, to get your Rails site to function that well takes a lot of work - it is by no means the starting point. Systems like Next.js and Gatsby.js and others are attractive in that A) they offer the ability to use both server-rendered and client-rendered React, and B) exceptional performance is the starting point. It's up to you to slow it down, not speed it up.
  • greenhatman 8y ago
    I think dev.to is an SPA. But not built with a framework.
    • subpixel 8y ago
      It's not, it's just very...dialed-in: https://www.youtube.com/watch?v=Afy7H04X9Us https://www.youtube.com/watch?v=Afy7H04X9Us
    • tpetry 8y ago
      It‘s a traditional server side rendered application. But they use a custom implementation like turbolinks and instantclick to change the sites content without a full reload.
• kyledrake 8y ago
  Agree with the article. I find server views to be substantially easier to work with. But more importantly, I also find server view rendering to be a faster, better UI experience. It's really frustrating having to wait several seconds for a SPA to load, or to have unexpected behavior when clicking the browser back button, or failing completely because some random hunk of JS garbage errored out, and it's one of the big contributors to why I don't really like using Facebook or Twitter anymore. They murder my browser with megabytes worth of slow SPA crap to give me less than a few kilobytes of meaningful data (and/or people screaming at each other). Gmail now takes 10-20 seconds for me to load at this point, on my high end laptop. I just want to switch to HTML mode by default. I definitely get edge cases like Slack, but honestly don't think SPA has been a positive development, overall. I think the web was better as a document/HTML oriented design.
  • todd3834 8y ago
    I don’t think this is about edge cases but SPA have been abused. Imagine using google docs as a server rendered experience. Or any of the apps in iCloud.com. There are use cases where it makes sense and use cases where it doesn’t. Most of your complaints are about poor implementation but if a large percentage of people poorly implement SPA then it still looks bad. I used to say you could make a very native experience with a hybrid web app for mobile. While this is absolutely true, most people don’t pull it off so I get the critism.
    • dhimes 8y ago
      Exactly. In many places slow networks are the problem, and quick spa's give a great user experience comparatively. The biggest lag in Google Docs is when it has to refresh from the server, and then it's like using windows on a 386.
    • mycall 8y ago
      I tell people don't implement SPA. Implement PWA. PWAs give you actual benefits that SSR doesn't provide (eg. offline).
      • 8y ago
• mduerksen 8y ago
  To add some use cases where an SPA would be the favorable choice: - Web-tech front-end for an embedded device. The device, which often has very limited CPU cycles, is not burdened by rendering. - Apps that are intended to be running locally and on multiple platforms (e.g. via Electron), as well as in browser.
• bzalasky 8y ago
  The answer to whether a single-page app is appropriate for a given project needs to consider product requirements, team structure and available resources. Libraries like React are awesome for breaking down complex (or even not so complex) UIs into story sized chunks that can be tackled by different engineers or even different teams. This is one of the biggest reasons to consider using them, IMO. Even in the case of relatively unremarkable CRUD application, if the backend is split across multiple services and teams it may be entirely reasonable to choose to build a SPA frontend with a dedicated team. On the other hand, if you're building a Rails app with a small team, and most engineers are working full-stack out of necessity, a SPA may not be appropriate. As companies grow, I've found roles tend to become more specialized. Your decision to build a Rails web app early on could be considered legacy cruft (by some) down the road because it can be difficult to break down and deliver a feature across the full stack if you're not accustomed to building web apps that way. There are tradeoffs to all of these approaches (including the hybrid approach). Ultimately, you need to do what's what right for your product and team(s), and make your technology choices intentional.
  • nabla9 8y ago
    If the team structure is the problem, you should disband the team and rearrange the structure so that it produces the result what you want. Trying to fit your product to the existing organization is not a good idea. Conway's law: "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."
    • quickthrower2 8y ago
      In theory, but you'd need Steve Jobs or Elon Musk level of clout to get that to happen. You'd need to be at the top of the organisation and pulling the puppet strings. Might be OK in a startup, but unlikely in a medium to large sized firm. There will be people who need to make you fail or they are out of a job - they'll care more about keeping their job and paying their mortgage than you do about SPA architecture (unless you are at the top and have the vision as to why what you are doing matters.).
  • 8y ago
• fma 8y ago
  So, a question coming from a guy who's been doing Java backend processing for a long time and thinking of making a side project. Was going to go the Angular route, but I'd like to have good SEO. I'd also like to get a POC/MVP up and running to build momentum...don't want to waste time on the front end when it's basic form submissions to kick off data processing. To show how long it's been since I've done front end...My last 'full stack' development had plenty of tables to style the application grin.
  • itronitron 8y ago
    In that case then do not use a UI framework such as Angular or React and instead just roll your own UI with HTML and JS, and style your CSS to make your MVP look fresh and new.
  • MarvelousWololo 8y ago
    A couple of weeks ago I tried the official Angular tutorial on SSR and found it super difficult. If you're willing to give React a try I would choose Next.js. It's pretty much a Node.js web framework that uses React for its views and has SSR out of the box. It has client side routing, so smooth page transitions, it was also fairly use to style the app with good ol css or sass. Ping me if you have any questions.
    • MarvelousWololo 8y ago
      Oh I forgot to mention: if you're doing this just so you could learn modern JS then rolling your own solution is all fine. Other than that I would avoid this at all costs.
• EGreg 8y ago
  Serious question: At https://qbix.com/platform https://qbix.com/platform we wanted to stick closely to the Web standards so we built a hybrid - although new pages would be loaded with AJAX, out of the box we made the “easy development path” cause every to page load from the server. This was because back when we started, search engines and other crawlers didn’t execute Javascript very well. We always kinda felt bad that we didn’t “fully” embrase the “new and best” SPA trend, but also felt good we were giving people choice and were more compatible with Web Standards. And now as time goes by I see more and more of our choices vindicated. Is this anti-SPA backlash just another fad? Or were we right to give people two ways to render the same page - one on dynamic navigation and one on refresh? https://qbix.com/platform/guide/pages https://qbix.com/platform/guide/pages
• ozim 8y ago
  I don't get 'SEO for free' argument. You don't SEO application, you SEO landing page and you don't want crawlers to crawl your app.
  • iamgopal 8y ago
    This. SPA for normal website, which required SEO, is pretty much overkill. When SPA actually applicable, SE are not allowed, let alone optimise.
  • Illniyar 8y ago
    Not quite. Lot's of applications have SEO for their main content. Social networks (reddit, twitter), marketplaces, shopping sites (some shops, like nike's, are quite complicated js-wise), forums (stackoverflow for instance)
  • antris 8y ago
    It's often a better user experience to let them click directly into the content they are looking for instead of making them run through a landing page.
• joduplessis 8y ago
  The massive problem with this approach is that more and more the requirements we see are exactly where SPA's shine: real-time elements, rich UI and eventually PWA implementation when/if. I agree that the traditional SSR has served everyone well - but I don't think we need to be stubborn about what has worked vs. what can work.
  • itronitron 8y ago
    There are a lot of hidden/implicit requirements when people think of SPAs. In order to do them right the interaction design needs to be worked out in detail with the developers so that everyone on the team knows all possible states of the application and how to best manage that.
• sheeshkebab 8y ago
  Coming from similar background as author (various legacy web apps with all the challenges of learning now useless js frameworks) - I’m now have a different opinion: SPA approach should be the default unless you have specific requirements to add html SSR (and even then google is pretty good at indexing public spa content too). So, respectfully disagree.
  • acjohnson55 8y ago
    You're disagreeing, but not providing any justification for why SPA should be the default. Why do you think this?
    • a_wild_dandan 8y ago
      I'll try adding to the conversation by at least justifying why I like SPAs: clearly decoupled front-end/back-end logic, likewise parallel updates/deployment from different teams, back-end mocking, minimal data updates for DOM changes, easy integration with microservices, powerful front-end tools to deal with client feature creep (e.g. interactive widgets), reusable UI components, easy migration to multiplatform desktop apps (e.g. Electron), possible single language for everything (JS, rather than a mishmash of JS/HTML/CSS/Python/PHP/etc), easy integration with hybrid or SSR stacks ( Next.js, Gatsby, etc). But all this is just rationalization for one simple fact: I'm vastly more productive building SPAs. I know the tools, and I can quickly deliver anything from simple sites to richly interactive experiences very quickly. I can go from SPA -> SSR (via, say, Gatsby) easily. But going the other direction from SSR to something interactive has been far more painful for me. That's why I default to SPAs and adjust from there.
• stevehiehn 8y ago
  Most of the projects I've been on there is a web app & native apps. So the appeal of a single page app is you will write the exact API/auth for all the clients. Would it be tempting to not use the same auth flow/api etc if you don't use a single page app? Not sure.
• zokier 8y ago
  This is a tangent, but is Github really still mostly ssr? It sure feels more spa-like these days, full with their own loading bar.
  • ec109685 8y ago
    They use turbolinks to hot swap the html.
    • asaddhamani 8y ago
      Turbolinks specifically?
  • nik736 8y ago
    Funny that even Software Engineers can't tell the difference between spa and ssr. How are clients supposed to benefit from spa...
• nkingsy 8y ago
  I have a list of widgets and a button to create a new widget. I don’t want a full page reload when I create a new widget. What are some elegant strategies for handling this with SSR? I’ve used turbo links and found it rather clunky. Haven’t seen a solution that lets me elegantly reuse server side components in JavaScript without going SPA.
  • colecut 8y ago
    Why does creating a new client side widget require a server call at all? Couldn't you have the widget in a JavaScript template and just clone it on the dom client side?
    • nkingsy 8y ago
      Cloning from a template would be the what, but I was wondering if there are tools designed for this. It's the kind of thing that could spike complexity and I would want an established pattern of delivering html solely for the purpose of javascript manipulation. It's not a hard problem, but a messy one.
      • colecut 8y ago
        I would use a simple "javascript templating engine" like mustache or handlebars, to easily inject dynamic content into your widget templates.
• cfv 8y ago
  You probably don't need a single-page app, right up to the point where it's a business requirement and you have to translate a GB worth of convoluted JSPs into one because the client likes smoothness in their flows, continuous saving, and all those nicely choreographed state transitions you just cannot get without having a framework hijack the History and File APIs from the browser's paws. Yes, a nice state machine-like flow with each thing happening only once at a given time is great, right until you get asked to make it so that clicking on a thing shouldn't reset all user input, and progress of a task should be communicated live, maybe while we also we want this app to just not show a blank screen like, ever, just comes and happens to you and that's what you kind of have to do now.
  • paulddraper 8y ago
    This is why it's important to understand the probable business requirements early. Website != Browser app != Mobile app != Desktop app != AR/gaming platforms If you know which of those you need, you can make an optimal technology decision. No one can expect to turn a wood-framed structure into a steel-framed structure. Nor build a steel-framed structure for the price of a wood-framed one. In this day and age, chances are better than not for anything reasonable involved, that this smooth interaction is a business requirement, but YMMV.
  • kochthesecond 8y ago
    not to mention the UX people coming up with neat animations and subflows with gradually revealed content.
  • woah 8y ago
    This is what HN is always missing on the anti-SPA rants. It’s almost always a requirement from the client. How many hours have been wasted on here by programmers writing overwrought comments about how we’re losing touch with the user because of all of our complicated frontend frameworks? No. It’s almost always because the client’s designer wanted a real-time updating hamburger menu or whatever.
    • wolco 8y ago
• ldiracdelta 8y ago
  One of the biggest reasons I reach straight for React is that I then have only one UI language. Instead of templating on the server in python or c# and then doing any UI updates in javascript on the client, I only have to write templating code in React and it runs on client and server.
  • dwaltrip 8y ago
    You switched from a C# or Python backend to node.js so that you can render React on the server, correct? Or are you doing something fancy to serve react.js rendered contents from a non-js backend? I agree that the hybrid approach of both server-side templates and SPA-controlled content looks difficult.
    • ldiracdelta 8y ago
      Personally, I don't use node.js as a backend. I normally use Django REST Framework (DRF). I may do server-side rendering of the client using express, still calling back into DRF for the data. The important piece for me is that I don't like the idea of generating a page in one language and then mutating the UI on the client side with another language. I just use one language for the whole UI.
      • dwaltrip 8y ago
        Thanks for sharing, that is an interesting setup.
• skinnyarms 8y ago
  How about build-time rendering? Server-Side rendering tightly couples your front-end to your application server. Scaling the site means scaling up that application server. A bug in one "page" of the app can cause the whole application server to go down. If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless services and progressive web apps. You can also re-use those services for multiple applications, making it easier to keep the business logic OUT of your pages and in an API layer where they belong. I agree that SPAs are not the solution for everything, but I think that server-side rendering is on it's way out.
  • bwilliams 8y ago
    > A bug in one "page" of the app can cause the whole application server to go down. That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. > If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless services and progressive web apps Your PWA point is valid but I don't think the microservices point is. Microservices add a ton of complexity and can easily become overwhelming. If you get to the point where your application can benefit heavily from microservices then congrats, you've made it. > I think that server-side rendering is on it's way out. If anything I think its on its way back in. So many companies bought into the benefits of client side apps and are now seeing the trade-offs that aren't very favorable.
    • jamespollack 8y ago
      > That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. What? The previous poster said coupling frontend / server tightly will result in crash of both if there is a server bug. Your response is that a bug in an unattached API could happen? Of course a bug in your API could crash your API. But at least then it's just your API that's crashed, not the (thousand) servers you're using to serve the front end and every device using them.
• nfRfqX5n 8y ago
  server rendering has a cost too. SSR is not easy. gatsby is mostly solving this in the react space.
• SimeVidas 8y ago
  You probably need a publication date for your article.
• chimen 8y ago
  What about separations in teams where designers don't mess with backend programmers code? Updates and parallel works on the frontend and backend projects without issues? What about servers that respond with minimal data and consumers that deal only with displaying the received data? Pushing code, re-compiling and restarting webservers all because a button had to be made green or its shadow changed? What about CI/CD, automated tests, automated migrations, builders and compilers consuming dollars and energy for that button change? I'm happy with building SPAs where it makes sense (myaccount/admin). The problem is Javascript and its ecosystem but you could very well go with Ember which is stable as...and be relevant for years.
• nailer 8y ago
  The term SPA is outdated and inaccurate ( most web apps have multiple pages) but until the DOM APIs include data binding: yes you do.
• buu700 8y ago
  Anecdotal: cyph.com started off as an SPA, mainly so we could share some components and styling with our actual application — and ever since we migrated to a static WordPress site with a handful of Angular Elements it's been both a lot easier to maintain and way faster for end users. (Sure, we could've gotten similar performance with server-side rendering, but at least with the current state of SSR tooling that would've been way more distraction from building our product than we could justify.)
• potench 8y ago
  “do I need a component library?” is the question I ask when deciding to use react or not. It’s a totally different question to ask do I need a spa or a server rendered app, both can be dead simple or heinously complex or reasoned away to prove a point... I 100% of the time want (1) to architect my UI as a collection of atomic, reusable components, (2) get page specific server rendered html per route, and (3) do JS in a sane way (manipulate DOM, manage client state, and support a series of interactions that do not reload the page.) So, what are my options? 1. React/node 2. Sacrifice one of the above.
  • brylie 8y ago
    I think all of your requirements could be met in a myriad of ways. E.g. Django templates/Handlebars can be organized as reusable components, many backend frameworks will render HTML per route, and there are several JavaScript client libraries including Vue and, dare I say, jQuery that will give you a sane way to do client interactivity without page refresh with varying degrees of declarative code style.
    • potench 8y ago
      I think this means you are sacrificing the component library requirement. There is not a sane way to intermix js,html,css as a single component with dependencies on other components with your approach. What you end up with is 3 very distinct/separate/unique/difficult to maintain solutions across css, js (probably 4 if you include js/html), html.
      • brylie 8y ago
        Vue.js and Aurelia offer examples of how UI components can be organized and composed, while allowing clean separation of structure, function, and presentation (divided along the lines of HTML, JavaScript, and CSS by design.) The main point is not to limit ourselves to a monotheistic worldview that convinces us, without substantive evidence, that "all other ways are wrong."
        • 8y ago
• lmilcin 8y ago
  All that complaining serves no purpose. SPA is just another tool in a belt. Where I think it shines is making rich apps that need complex flow and communication. This is where productivity is important and the process is complex and up until recently I would be advocating native desktop app. Now with advent frameworks that help me organize this very efficiently (I use re-frame/reagent with ClojureScript) I can create complex SPAs without the project collapsing under its own weight at some point. I don't want to say you should use SPA frameworks for anything, don't make your company website with SPA. What I want to say that if you have a complex process you can consider creating "enterprise" UI instead of trying to dumb it down to a series of billion simple forms. If you feel your business is overusing SPAs (is it so strange they want new shiny toy?) then as the technical person you need to educate them on pros/cons of the technology.
  • crooked-v 8y ago
    > I use re-frame/reagent with ClojureScript I personally feel like what's really missing here is something like a generic spec (not a generator, but a descriptive standard) for the structure and organization of CRUD-style JS/JS-derivative SPAs, something like what re-ducks (https://github.com/alexnm/re-ducks https://github.com/alexnm/re-ducks) did for the Redux world.
  • movedx 8y ago
    > All that complaining serves no purpose. It's not complaining. It's a profession's view on the state of (default) behaviour by most developers in the wild. It's a valid set of points as to what the default mode of operation seems to be, as a general rule, and why it might not always be the correct default mode of operation.
  • int_19h 8y ago
    The complaint is that it's a tool that used much more often than is necessary or even advantageous. Just like that old saying about hammer and nails.
• asaddhamani 8y ago
  I agree with this so much. These days, the first thing developers will do when making a new app is setup babel + webpack + react + redux, then make an API, all for mostly CRUD applications. Most applications don't require these frontend frameworks, and it just adds needless complexity in most cases. I've suffered due to this, and so I've recently made the move back to server rendered apps. And Rails with Turbolinks + UJS might not perfect, but it gets you like 80% of the way there for 10% of the effort.
• deleted 8y ago
  [deleted]
• rorygibson 8y ago
  1) CRUD / data entry systems: stay with request-response. 2) Complex webapps with snappy functionality that need to feel "native" - whatever that means: think about an SPA. Then realise that mostly what you need is (1). 3) Corporate homepages / brochure sites / product sites / blogs: use a static site generator like Hugo, Jekyll etc. It's amazing what you can do with a staticgen site now [Insert shameless plug for Trolley, my product, https://trolley.link https://trolley.link ]
• matchagaucho 8y ago
  Counterpoint... how many times have you clicked on a Show More link and thought to yourself "No, no... please don't redirect me to another page". Progressive reveal patterns are expected by end users. It's just lazy for a programmer to assume old-world CRUD patterns with server-side render.
  • aaaaaaaaaaab 8y ago
    Counterpoint: how many times have you browsed an infinite list of progressively revealed items only to accidentally refresh it and start scrolling again from the top. And of course the items are randomized by our latest AI-based clickdriver algorithm so you won’t be able to find the item you were looking at no matter how long you scroll ;)
  • Toutou 8y ago
    I can't see why the Show More content couldn't be rendered server-side, fetched with AJAX and plugged into the DOM with two lines of JS. SSR, no redirect nor refresh, progressive reveal af.
    • matchagaucho 8y ago
      That pretty much describes SPA behavior. The payload can be JSON or HTML... but the UX should not redirect.
• syllable_studio 8y ago
  I have experience building both SPA apps and server-side templated apps. They each have their strengths and weaknesses. Just as a SPA won't solve all your problems without any trade-offs, getting rid of a SPA framework also won't solve all your problems -- you'll probably need to re-invent some wheels and then discover that your new solutions are hard too. I think it's good to have a healthy dose of skepticism about new technologies. But it's also important to understand their value and not to hate them just because they're hard. I like that the author tries to find this ballance. Though, honestly, from my own experience, I would rename this title to "You might not need a single-page app." More than once, I've tried to build something without a SPA framework only to realize that if there is any interactivity at all, it's often just simpler to use a SPA framework in the first place.
  • wreath 8y ago
    > it's often just simpler to use a SPA framework in the first place. Simpler or more convenient? I've yet to see a production-grade React setup (for example) that is simpler than having either vanilla JavaScript or even jQuery to achieve the same interaction. The amount of tooling required to do simple interactions does not justify the technology for most applications IMO.
    • pault 8y ago
      How complex were the applications that used those production-grade React setups? As the number of possible states increases, your vanilla JS solution explodes in complexity when you have to manually define every state transition. The declarative nature of SPA frameworks means all you need to worry about is presentation of your data. If all you need to do is some form validation, then writing an SPA is a terrible idea. If you need to build a UI that functions more like a desktop app with long-lived sessions and complex workflows, trying to manage all of your DOM updates will be a monstrously difficult task. You'll basically end up implementing a slow, buggy version of react.
• sebringj 8y ago
  I think a more practical approach is to focus on a generic enough UI toolkit meaning detached from any specific tech stack that will give a feeling of continuity to customers as they move from static pages and SPAs and different flavors of ideas that IT tried along the way. One SPA to rule them all is ridiculous as it doesn't work that way with scale as you have independent teams working on various projects that will be hindered by a single approach in that everyone will have to understand x approach and also have stupid meetings about it.
• lloeki 8y ago
  Not only you probably don't need a single page app but you also probably don't need a client side lib to build and render your views... Server side view caching and 304 can go a long way and saves round trips, even at scale and is much more friendly to high latency/low end cpu user agents.
• Ericson2314 8y ago
  Porque no los dos? We pretender enough so if you turn off JavaScript you get old school and if you turn on you get SPA. All the basic widgets are server/client agnostic, and we have a combinator to special-case the server vs client code when needed. The types enforce client-specific functionality isn't used otherwise. We also have a "DOM puppet" backend which allows everything to be compiled to native code puppeteering browser APIs from a fair. Prerendering, that, and direct JS output all all supported through related typed abstractions. Soon we will compile the puppeteer to WASM too, so we won't even need the direct JS output anymore.
• amoitnga 8y ago
  1. It's like saying you don't need Rails, just use Sinatra and if your app really needs it then use Rails. I'll pick rails even for a super simple project because I'm very comfortable, quick with it. 2. "You don't need the complexity of SPA or javascript fatigue" and then you install webpacker gem that wraps around webpack and not only you have a headache of webpack but also of a gem that wraps around it. And then you need some front end libraries and you start including them in in the way that feels like a workaround. I mean no disrespect to these wonderful tools, I appreciate the hard work being put into these gems, and I will admit I didn't give it TOO MUCH effort to learn. I tried it. didn't feel right. moved on. I've just decided for myself that for now I'm gonna keep my backend ( ruby, db, server ) in one mental bucket, and all the fronted ( css, js, html ) in another. For me to go traditional Rails way it has to be a super simple app, at which point there will probably be other tools to solve the problem.
• oblib 8y ago
  This article feels to me like complaining about making the simple difficult. Since I work alone I suppose I'm not up to speed on what defines a single page app but the apps I've been building with PouchDB, jQuery, and Bootstrap run in a single page. "Stateless requests Traditional web servers are built to be stateless. " True, but "apps" should be designed to be self-contained (i.e. all the user navigation is done within the app UI, not the browser UI). "The browser knows how to deal with a traditional architecture If you go with the SPA route, you’ll always need extra code to emulate trivial browser features." That's a pretty trivial problem and browsers don't really solve that, nor should they. "Fewer, more mature tools Avoid the Javascript fatigue by not relying so much on Javascript!" The apps I'm building are almost entirely Javascript. I see that as a good thing. What little I do on the server side I do with Perl, which is something I've been doing since the `90s, so I can feel "traditional" doing that if it helps me sleep at night. "SEO for free Single-page apps have to add extra infrastructure and code to make sure they can be indexed by crawlers." This is not so difficult to address and in some cases it's not even a consideration. In the case of a "blog" app you can simply assign a url to a post and deliver a page built on the fly specifically for it. Google can parse that.
  • Arkanosis 8y ago
    > i.e. all the user navigation is done within the app UI, not the browser UI Not sure if that's what you mean here, but when this breaks the “back”, “next”, “refresh”, “bookmark” or “share URL” features of my web browser (among others), I hate whoever has been responsible of the design as much as I've hated Flash in the past.
    • oblib 8y ago
      I'll offer the distinction is rather you're using a "web site" or a "web app". A web site should never break your browser. A web app should be able to run in "Full Screen" mode without needing to use the web browser UI.
      • Arkanosis 8y ago
        I get it, and I think the distinction is relevant, indeed. Unfortunately, way too many developers think it's a good idea to build a web app instead of a web site, when it's not. Same issue as with Flash before, in fact.
• larrybeck 8y ago
  thanks
• clessg 8y ago
  Personally, I'm very interested in the possibility of Phoenix LiveView giving us the best of both worlds: https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
  • arbie 8y ago
    > As an application developer, you don’t need to write a single line of JavaScript to create these kinds of experiences. You can write and test all your code in a single language: Elixir. Now you have two problems.
• aviato 8y ago
  I’m surprised this article doesn’t touch on Next.js at all.
  • jamespollack 8y ago
    Author too busy hating to actually explore tools that would do exactly what they want.
• pier25 8y ago
  I've been making SPAs for a couple of years now and I totally agree. Not only the complexity of development is increased, but there is no real benefit for the vast majority of use cases. I think there is merit in using an API though and clearly separating data from presentation. What I've been doing lately is using Jekyll with Vue components for some in house projects. It works great. Another option I've been trying out is doing SSR in JavaScript on Zeit Now monorepos. Haven't used it in a real project, but so far it's awesome. You can keep using all your front end knowledge, but render each route on the server. No more managing state (Redux, Vuex, etc) or router.
• ilrwbwrkhv 8y ago
  and if u have to use a framework please use something like mithril
• deleted 8y ago
  [deleted]
• BlackFly 8y ago
  I used to feel that way, then I met a one javascript developer in particular who really made me see it differently. I won't get into those here, I just want to tone down the "probably don't need" into a "don't necessarily need". As a predominant back end developer, I do feel that the complaints from the article are due to inexperience or misunderstanding: 1. stateless requests: You don't have to cache any state by default, just like server side. You start caching to improve performance and caching is always one of the big 2 problems of computer science. Don't cache if you don't have to: stateless has benefits. 2. Reinvent browser features: use your framework! This is a solved problem. I am not sure what the Angular or React solutions are but with vue just use the vue router. 3. More mature tools: backend suffers from this as well, I know a lot of mid level software engineers that are always chasing the latest fads. Microservices, containers, serverless, etc. The biggest issue I had when I tried to do serious frontend development is just not being aware of the tooling and how it works. 4. SEO: Google can crawl your webapp: https://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 https://searchengineland.com/tested-googlebot-crawls-javascr..., I would prefer if the person making the claim (that an SPA does not get crawled) would be the one providing the evidence... Don't get me wrong though. Sometimes an SPA is the wrong choice but it would be hard for me to say if that is usually, rarely or a toss up. I think many places that go from server-side rendered to client-side rendered SPAs do not hire a bunch of front end experts when they do so. Then people experience a bunch of problems because of the fact I point out in 3: lack of awareness of the ecosystem. On the other hand, there sure are a lot of diva developers who don't like working with old technology (for example, PHP), and this probably causes a lot of the front end framework churn. Just like picking up a new language, it takes time to produce idiomatic code. Of course, for a new framework it takes time for the idioms to develop...
  • devmunchies 8y ago
    Google isn't the only search engine. But even if that is the only one you care about, Google said themselves in last years IO conference that it takes them several more days to index a client rendered interface, since they have to send it to a rendering queue, and the line is really long. Here is the talk: https://www.youtube.com/watch?v=PFwUbgvpdaQ https://www.youtube.com/watch?v=PFwUbgvpdaQ
• paultopia 8y ago
  Unpopular opinion: I love SPAs for simple stuff. Yes, they're a ton of work. But the feel of them is unparalleled. I have my personal home page written as a Vue SPA. It was a silly amount of work to get together, and not everything works perfectly. BUT: it moves like a rocket. I pre-render the simple front page, so initial load is nearly instantaneous (especially with cloudflare &c), and, by the time a visitor finishes absorbing the information on the front page (which is just a palmos style collection of icons to other content), everything else is loaded. Which means that the effective load time of the whole website is perceptually indistinguishable from zero on a moderate-speed connection (like my crappy home DSL). And that's... cool. It's legitimately cool. Let me have my fun!
  • tills13 8y ago
    The more you write SPAs, the easier it is to set up the next one... This whole "but SPAs are bad!" tirade a lot of people have been going on since a couple years ago stinks of people being nervous about their job security.
    • movedx 8y ago
      https://martinfowler.com/bliki/MonolithFirst.html https://martinfowler.com/bliki/MonolithFirst.html -- you're right, Martin Fowler, that guy no one has heard of, is just nervous his job is on the line. No. It's a perfectly valid point to make: splitting everything up into SPAs, micro services, etc, instead of solving the business problem with a monolith is indeed the wrong way to go, and Martin makes some sensible arguments around this topic. It's the same in video games: you create a prototype using cubes and texture-less blobs to test the "business logic" (mechanics) first before you produce a AAA model and 700 animations.
  • shhsshs 8y ago
    Well said. I think combining SSR and SPA by making intelligent tradeoffs is the way to go at this point. It's all about making the right choices to deliver the experience you're trying to offer.
  • Theodores 8y ago
• jtms 8y ago
  A well written rails app with good caching and some async stuff sprinkled in where necessary generally feels just as responsive as an SPA for a fraction of the dev cost.
• kadendogthing 8y ago
  Yes you actually do. At the very least you should build your web app with technology that makes it fairly trivial to move over to an SPA. MVC is a mistake. Read that again. MVC is a mistake. It's not a good paradigm to write web applications in. SPA's are not complicated. They do not take longer to build. They defacto are often way more responsive than any server side monolith that gets built. Because developers who buy into an archaic and broken "MVC" systems typically do so because its "easier" for them, but it's easier because they're not willing to think about whats being written in the first place, and that's a recipe for a bad app no matter how you write it. Inevitably you will end up hacking your "simple" MVC app to meet perfectly reasonable, ubiquitous client requirements regarding user experience. Because the paradigm isn't fit for base level requirements. A few years ago my entire job was completely based around consulting for these types web applications. Inevitably you get these developers that think they're wise by going "we're just going to do it with MVC" -- and after a few months of use it becomes completely obvious that the dev team can't meet any kind of modern requirements for the web application. The existing web app is slow (but it's "fast" to the developers), buggy, and the worst part for the business is it takes forever to write features for. Eventually these companies get so frustrated they look to the outside. To recap, when you build a "traditional" MVC app this typically means a few different things: 1) It's written in a toolchain that's fairly niche to "back end" developers; severely limiting the pool of talent that company can hire to maintain the web application moving forward. In a fair number of cases the company will have a front end team and a back end team. And sometimes all that back end team does is update views so the JS developer can do their thing. So expensive for something so small. 2) You will end up writing a mass of JS anyways, but the JS will mostly revolve around dealing with the fact that the server side templating language controls the original output of the web application. At worst, this means that a lot of devs like to sprinkle bits of HTML inside the JS. So now your templating is strewn across multiple languages and locations. The JS is typically bad because these are "real" developers who don't like JS. 3) Because of 2, there will also be a mess of server side code purely written to massage data into the server side templating language and an analogous set of code just for the JS side of things. 4) Because of 2 and 3, the app because buggy and oddly slow (though again, the devs that wrote it will only look at the original output timing and not the actual life time performance of the application). 5) Because of all of the above, the company has now spent an enormous amount of resources for a fairly shitty app that no one likes to use nor maintain. My primary focus for these companies was to build a baseline SPA. And then over the next couple of months guide them through creating new features. And this wasn't a one off thing. I had an entire job based around fixing the sins of the company's internal developers who are costing the company money while not delivering, costing the company money making the application way more complicated than it needed to be, and costing the company money by forcing the company to hire a specific subset of developers familiar with their MVC toolchain. Stop circle jerking about MVC apps. They were ugly in the first place and continuing to claim that's how we should build web apps is an erroneous position purely fueled by stubbornness on the part of developers. Here's my benchmark for an SPA: You can either build your entire site using static generation, or you need to structure your web app as an SPA (or prepare to do so in the original implementation). That is the threshold in the current landscape. If you can't get away with doing a statically generated site then you're not going to have fun writing your site with backend MVC framework. At the very least the company's finances definitely won't.
• trumped 8y ago
  You probably dont need a 40mb app either...
• deleted 8y ago
  [deleted]
• anonyfox 8y ago
  Having developed with nodejs since v0.4, went through jquery => backbone => angular (1) => ember => vue => react, written stuff in several incarnations of javascript (including coffee and typescript), used build tooling from grunt to webpack and customized browserify, even built stuff with meteor... i can‘t bear it any longer. Actually now we are full circle again. Files that mix css/template/logic with FOTM syntax, add some database calls during SSR and you have basically PHP. Just more complicated tooling. Deploy your frontend on S3 and its similar to FTP to Apache Servers, except you can‘t update just individual files. Run your backend on AWS lambda and you have stateless backends like ... PHP, but with cloud vendor lock-in. State Management like „Flux“ that poorly resembles state machines on top of JS shortcomings. I am personally switching completely to elixir/phoenix to do anything web-related and can solve things cleanly within minutes. Also when Phoenix LiveView finally arrives, it could be groundbreaking and replace many usecases of modern SPAs.
• dimgl 8y ago
  I can't agree with this article at all. Having an JSON API and a small web app bundle that you can deliver with a highly-available CDN removes a ton of scaling problems related to SSR and gives a clean separation of concerns both from a managerial and architectural standpoint. It also makes testing dead simple: you just make contracts on what the response bodies will look like and just feed mock data structures into your stateless web app. This allows the API team to make changes to the API layer with confidence that as long as they don't change the contracts with the web app, everything will still work.
• Trisell 8y ago
  It seems like a good 80-90% of the hate of SPAs doesn’t seem to be aimed at SPAs as much a poor programming and poor user experience because of that. In a lot of the cases that people here use. It’s not the SPAs fault as much as the programmers that messed it up. And honestly why do we think that putting it all back to SSR is magically going to fix poor programming?
  • detaro 8y ago
    You get quite a few of the things that SPAs often break for free with more traditional apps, because it's provided by the browser.
• draw_down 8y ago
  There are a lot of things you use or build that you probably didn't need. That is, there are plenty of programming languages you could have used, or shapes of solutions you could have built instead of what you did build, which probably would have satisfied the problem as well. So it's not worth getting hung up on specific things like SPA. What ends up getting built is in part due to the requirements the problem presents, and the rest is down to prejudices or inclinations of specific people in the organization. I'll never forget the time we had to build an Angular app because a bunch of people who were not frontend developers were convinced that Angular was the way web apps would be built in the future. Because it came from Google. Welp. (That was back in the Angular 1.x days, which even the people who make Angular couldn't drop quickly enough.)
• stevebmark 8y ago
  It's 2019 why doesn't anyone understand that all search engines can fully index SPAs?
• manigandham 8y ago
  Agree that SPAs are usually unnecessary. The big problems with JS SPA's is due to the limitations of javascript and the browser runtime. The one major innovation has been component-based view models while server-side frameworks have been stuck with older template-based approaches. Component-based views are starting to get to server-side frameworks so that should reach parity within 2 years and WebAssembly will change the rest. Now apps can be built using many different languages with OOP/functional styles, strong typing, dependency injection, etc, and run at native speeds in the browser. With the next gen of WASM running threads, GC, and DOM abilities, JS frameworks will likely start a slow death as the existing web frameworks start to have both server and client side delivery models. ASP.NET Core with Razor/Blazor is a great early example of this: https://www.youtube.com/watch?v=Qe8UW5543-s https://www.youtube.com/watch?v=Qe8UW5543-s
• wnevets 8y ago
  but how else would I get a job making SPAs if I don't make SPAs? /s
• sriram_iyengar 8y ago
  Valid points. - another aspect to consider seriously when designing SPAs is authentication. I have built ReactJs applications and everytime we need a different module that had only the login functionality. Somehow this always appeared disconnected whereas In traditional apps you have a middleware that watches before rendering, be it client side or server side rendered.
• rajangdavis 8y ago
  I used to love SPA's but, in my experience, the most poorly organized SPA code is severely more complex than poorly organized server side rendered app code. With SPA's, you're usually dealing with some build system, a variety of dependencies, and a swathe of design patterns. At worst, you have everything located in a single file which has all of the above across tens of thousands of lines. With server side rendered code, you are (at worst) following someone's code that didn't follow the correct separation of concerns. At worst, the spaghetti code will be within a couple thousands of lines of code. I had a project recently where I ran into both of the above scenarios and I would prefer to debug poorly written server-side code than poorly written SPA code. It's night and day in terms of complexity.
• codeisawesome 8y ago
  In “reasons for going SPA on a greenfield project” I would add: - Need for a mobile app is close on the roadma and there is an opportunity to build server code in an API first fashion.
• nojvek 8y ago
  I’m an advocate for SPA’s when they make sense. They have a clear niche. When you need to build an “application”. Like photoshop. Not a simple website that serves information. Most websites are best served by serverside rendering. Or some form of hybrid where you only send the templates as JS that will be in need. With SPA’s what usually ends up happening is that the whole app is sent in the first load. All the views, their css and shebang. <1% is actually used by the browser. This is where most hate comes from. Most people give a shit about “time to first meaningful paint”. It’s what makes up for that “wow that was fast experience” You can optimize both SPAs and server rendered pages for ttfcp. The former requires a lot more discipline. Browsers also do a lot to render as quickly as possible without the whole page being downloaded. With html it’s simple and they have a lot of streaming tricks. JavaScript is not that simple. It blocks the eventloop and the payload is downloaded in full, executed and then a paint can happen. There are trade offs. SPAs can offer high interactive experience when server side rendering cannot. SPAs are great. Just don’t throw everything away. We need the baby.
• Chloro 8y ago
  I don't get it. SPAs are easy to make and have way more pros than cons.
• littlecranky67 8y ago
  There are some features which will clearly call for a SPA over SSR, if you need * to continuously play media (video/audio) while the user interacts with the web app (think modern youtube, soundcloud, spotify web, video news sites) * provide offline usage/features * highly interactive app with extensive use of drag'n'drop, animations, touch events etc. * data sync between browsers/tabs (think moving a ticket in a trello board should update the stacks in other open trello tabs or even for other users that currently view the board)
• intrasight 8y ago
  Wait - what other type of application is there? I transitioned to SPAs 18 years ago and would never look back. That is for "applications". For web sites I would never use SPA. I stick with server-side rendered HTML.
• ercu 8y ago
  For me, the biggest problem with SPA is, needing node.js when you want SSR. There should be better ways than adding another backend layer if your stack is different and you don't want callback based multi-threading.
• vajrapani666 8y ago
  The OP glossed over managing styles and i18n between embedded JS apps and the host app. I'm not sure if there is a way to create strictly isolated CSS in pure server rendered applications without managing naming your own selectors manually. If you build tiny JS apps into your server rendered apps, you'll have to keep the styling for the JS app either in the main app, or bundle it into the embededded JS. If you bundle it into the embedded JS, you'll end up with two styling pipelines, which could make it more difficult to share variables and constants between the two, if you put the CSS rules for the embedded app in the host app, then you have to change the host app CSS for changes in the child app, which means the two might need to be in the same repo. This gets especially more difficult with advances in UI and interaction design which lean more heavily on state based animation. In those cases, we HAVE to have CSS related to animatable elements that are based on application state within the embedded JS application, then you'll really have an issue with having two pipelines. There are similar issues for i18n, asset bundling, accessibility auditing, and testing. Given all the complexity of managing multiple pipelines for simple and complex pages, it seems to make sense to avoid that complexity by adopting a single pipeline that ensures browser compatibility, testing, i18n, accessibility and performance optimizations are consistently applied and centrally maintained. Which might imply , if _any_ of your app requires complex presentation/interaction, it might be better to just build the entire app using the same framework. Unfortunately, even if your app doesn't currently have complex functionality or interactions, doesn't mean you can guarantee it won't ever. Investors are known for pushing products to innovate, pivot, and adapt. Which implies that avoiding SPAs is a privilege for app developers and teams who have absolute control over their product and won't ever be forced to build more complex products. The Op also doesn't address how having frontend dedicated ecosystems might affect hiring, or influence performance. I remember the days of having 20 instance variables set within a rails action and each of them being deeply coupled into the Erb template. Having a clear client server separation at least forces one to use an API, which can make caching easier by separating the caching of presentational and data elements. Also, the semantics of each server side templating language are quite different. E.g , slim vs liquid vs haml vs ejs. Using server side templates requires frontend developers to be much more versed in both templating languages and understanding the tiny bits of embedded server side code. I don't imagine too many front end folks jumping to learn scala, clojure or Haskell. However, if the client and server are separate than that means a scala shop can focus on the API and hire a frontend dev with no experience in the server side stack.
• oneshore 8y ago
  So much of this is because of the mobile "app" craze where -- due to the limitations of mobile app architecture, you had to build a stateful "app" instead of several independent screens with some limited shared state (usually just a token). Native mobile UIs are great, but something as simple as cookies / local storage could allow for stateless (or at least less stateful) mobile apps with native UIs. Now, the abomination of hybrid (cordova), or pre-processed (react native/xamarin) mobile apps is whole other thing, but often why web apps are translated to SPAs. If we need a mobile app as well, why not use a common code base for web and mobile...
• arendtio 8y ago
  I kinda dislike this article. Not because it isn't true, but because of the effect it might have on some readers. Yes, building a SPA is not always the best solution, but sometimes I get the feeling that a lot of developers hide behind 'I know how to build good SSR pages and all SPA I have used suck so I will not learn that sh*t'. If you know how to build a PWA with SEO support, offline+sync capabilities and push-notifications, you will know when to choose what (because of the pain you experienced learning it). If your boss chooses your tech (from the latest buzzwords) and he doesn't understand the implications, I am truly sorry for you, but don't blame the tech on it (ask your boss for a seminar on 'How to Communicate with Managers' maybe then he will understand that you are trying to tell him something...).
• fastbmk 8y ago
  TL;DR Stubborn Rails&DHH fanboys won't admit their 'knowledge' is obsolete.