8 ms·

Serious question : Why are SPA frameworks so popular these days? When someone asks "What should I use for web development?", It's now all about React/Angular/Em

• overcast 10y ago
  Prevalence of API's. One common interface to query/update from. You don't have to do both server side, and client side requests. Rather do it all client side. I've done of a few of these types, and now have moved onto mixed environments. Where most is rendered server sided, then only updates requested client side. Of course you're doing things twice for same queries.
• scottmmjackson 10y ago
  SPA frameworks are not all-encompassing tools for buildong all web pages. Notably, trying to SEO a SPA is frustrating at best and impossible at worst. However, in b2b use cases where SEO isn't an issue, SPA frameworks are ideal for coordinating a static-site<->dynamic-api system.
  • pault 10y ago
    Server-side rendering is supported in several SPA frameworks now, and SEO is not an issue if you use it.
  • quaunaut 10y ago
    Google's been indexing SPAs fine for quite awhile.
  • charrondev 10y ago
    React, Angular 2, Vue 2 and some other SPA frameworks or view systems all support server-side rendering with very little coercion nowadays. That combined with google executing javascript during indexing means that SEO isn't nearly the issue it used to be.
• TelmoMenezes 10y ago
  What's with the "serious question", "genuine question", etc? Mostly I see this mannerism prefacing questions that could not reasonably be taken as a joke or provocation. Serious question: are people so touchy these days that you have to assure them that you are not being hostile before even saying something?
  • praptak 10y ago
    I think it means "don't interpret curiosity as middlebrow dismissal".
  • deleted 10y ago
    [deleted]
  • electrotype 10y ago
    This is a huge release for the Angular team, I'm happy for them and I don't want to sound like I'm "attacking" them with such question. Also, english is not my main language so maybe I don't understand perfectly when to use this expression or not. I see I should use it more carefully! ;-)
  • aiokos 10y ago
    If you look at some of the comments condemning him for not backing up his preferences with statistics it makes sense that he should preface his questions with something to provide levity. I don't know why programming communities are so touchy about their tools, particularly JavaScript frameworks. It must be a sort of buyer's satisfaction to convince themselves that they made the correct time investment.
  • akst 10y ago
    Someone having a different point of view online isn't that radical of a concept. Especially considering how easy it is to misinterpret the tone of someone's remark online. It just shows you're going out of your way to clarify your interested in a genuine discussion.
    • TelmoMenezes 10y ago
• EugeneOZ 10y ago
  > I think I still prefere the "feel" of classic Very detailed, proved by numbers, objective and professional argument. That's how things should work.
• emodendroket 10y ago
  It loads faster, you can have a richer experience, you can use less compute resources and less bandwidth. And I'd say that HN users are not typical users. In any event, if you're making a real Web application (as opposed to just a Web site that's primarily static content) the experience is much better.
• zodiac 10y ago
  Server-side rendering blurs the line here, eg you can write your page completely in react and still have the "server generate each page"
• morgante 10y ago
  > I think I still prefere the "feel" of classic websites. Your hacker biases are showing. The sites where 95% of people spend most of their time (Twitter, Facebook, Instagram, etc.) are all built as single page "applications." Users expect rich interactivity from websites these days and are usually not tolerant of UI refreshes. The comparison is not to "desktop" applications but to mobile apps. Users expect a mobile app level of interaction. Plus, if you're building mobile apps then it's a lot easier to just reuse those same APIs for a web app. That being said, if your site doesn't have any interactivity then it does make sense to just render it statically.
  • andrewstuart2 10y ago
    One of the key advantages of a single-page application from the User Experience perspective is perceived response time. It takes well under a single frame refresh period (~16ms) to react to some event and either change the page using data you already have, or throw a loading indicator on the screen. The app may have been slower to load the first time (hopefully not by much) but from then on, they get the perception of instant feedback even if they have to wait a round trip for the backing data sometimes. SPA frameworks make this sort of interaction very easy to design and reason about as a developer.
  • omouse 10y ago
    And the performance of all those is just garbage in Firefox on a 3 yr old laptop and isn't that much better on mobile. They're fantastic for forcing people to buy new hardware just to look at information :|
    • charrondev 10y ago
      Well it must not be a very good 3 yr old laptop then? And firefox isn't exactly the slimmest or lightest web browser. Sucks ram just as bad as chrome used to. My 3 year old laptop can handle all of the google services just fine.
      • omouse 10y ago
        8gb RAM, great CPU. I'm playing counterstrike global offensive and civ 5 with very few problems. Lower FPS sure because the video card isn't great but it shouldn't be this bad. It was fairly decent in Win7.
• neverminder 10y ago
  Because today there are websites and there are are web apps. Sometimes there's a combination of both - for example a blog - it's front end (user facing) part could be rendered by the server page by page and it's backend (admin access) is a single page web app. Each is used where appropriate - website - mostly static content, SEO and web app - a lot of user interaction.
  • prodigal_erik 10y ago
    There's no such thing as a web app, just javascript apps, and every time someone ships one the world-wide web of linked hypertext becomes smaller and less useful than it might have been.
• akamaka 10y ago
  They're easier to develop. Most websites and web apps have use AJAX to dynamically update certain parts of the site. Even though few sites would need to use it for everything, once you introduce good tools for dynamically updating the DOM and hire some Javascript developers, it's easy to say "Let's just use this approach to everything". It's fair to say it's a lazy approach. I've built many SPAs that probably would have been better as static sites, and would have benefited from better SEO. But hey, we got then shipped fast.
  • nkassis 10y ago
    "They're easier to develop." I don't think that's entirely true, they allow for building experiences that weren't really possible with the previous model of rendering entire pages server side on every action but they aren't easier in all respect to that. If you site is mostly static data, it's probably still easier to use the older model. SPA frameworks start to make more sense when you want to build interactive pages with components that you want to individually update etc... But they do add complexity that can't be ignored. that's why tooling and frameworks are hugely important as they smooth out that complexity.
    • hatsix 10y ago
      The biggest "easier to develop" thing for me is the ability to have the SPA separate from the server. Being able to deploy beta builds, one-off builds, etc makes it MUCH easier to diagnose production problems. So, I guess I'm saying that it allows for much shorter iteration times, ability to experiment with solutions in the production environment without requiring complicated server solutions. Granted, that also lets me build experiences that weren't possible, because I can experiment more and have a faster feedback loop, but for me, it's because I can DEV better.
• daxfohl 10y ago
  Also I think it's more intuitive to develop. You do all your logic in the "app", and the REST layer is just a glorified DB wrapper. It matches the project's inevitable phone app more closely too so you don't have two entirely different paradigms. Of course all that goes away when your boss says you need to support JS-disabled browsers.
  • akst 10y ago
    > Of course all that goes away when your boss says you need to support JS-disabled browsers Well seeing as this release of angular offers some form of server side rendering, as well as Ember with fastboot, & being implementable in React or something like that. It's more approachable these days, there's some tweaking that's required, but very much doable. Unless of course you're dealing with an interaction heavy UI.
• dcwca 10y ago
  Websites vs. Web Apps. Websites are static documents. Web Apps use the browser as a runtime for a UI application.
  • electrotype 10y ago
    You can have a lot of interactivity with plain Javascript + some Ajax requests, without the need for the application to be a single page developed using an almighty framework. Classic websites are not synonym of "static documents" in my opinion.
• bluetwo 10y ago
  I have to agree with you. HTML5, CSS3, and Javascript have matured to the point where they are very powerful and flexible. I don't always see the point of over-complicating things with frameworks.
  • skhavari 10y ago
    Yes, they are very powerful and flexible. These frameworks actually payoff and simplify once your project grows beyond a particular size.
    • officialchicken 10y ago
      > once your project grows beyond "Premature optimization is the root of all evil." - Donald Knuth
  • hatsix 10y ago
    I recently built a small three 'page' game for a trade-show booth. By using Ember, I was able to: try out a new CSS framework based on flexbox, save data to localstorage, capture images from the webcam, have 'data binding' of variables so that they updated on the page when I changed them, and deploy to surge.sh in the first hour. All-told, it took 20 hours, 7 of which was me getting used to the intricacies of developing a full-screen "App" (no scrolling) with flexbox and implementing the designs. I'm good with vanilla JS, but there's no way I could have done all of the coding (three 'game' pages, three 'admin' pages) in less than two days. I guess the point is, a framework that you know and are familiar with can halve the time you spend on a project. I find that to be especially true with Ember because of the CLI tools and all of the various addons.
• jwarren 10y ago
  There's honestly no need for React/Angular/etc to necessarily power a SPA, you can just use it to build smaller components. I initially got started with Angular to power a reusable video "widget" component on a WordPress site - a far cry from an SPA! It's also a great route to getting your feet wet without committing wholesale to a technology.
  • oelmekki 10y ago
    +1. I've made nine react apps since last year, only the two last are SPA (because I wanted to try the golang/react combo). React is super good to take control of a small piece of the page and build a complexe widget on it (can't speak about angular, I only used it twice without getting very far).
• Roboprog 10y ago
  See my response to "alzoid" about separation of concerns and bandwidth/processing benefits. Simplify server logic Use less bandwidth
• shados 10y ago
  IMO building classic websites is a solved problem, while building web apps isn't. Classic websites have CMS, things like Wordpress, and a ton of MVC frameworks that have been tweaked over the last decade, like Rails, Django, ASP.NET MVC, etc. When it wasn't a solved problem, a new one like this was popping up in the news every other week. Now, that that's done, people are trying to do other things, like complex web apps...and so that's where the brain time is being spent.