7 ms·

You overlooked this part: > 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

• chrisco255 8y ago
  That's pretty debatable. I've worked on some gnarly SSR architectures and making changes to the front end almost always involves refactoring some of the backend as well.
• ivanhoe 8y ago
  You simply trade back-end frameworks complexities for the front-end framework complexities. With the right architecture there is no huge difference IMO, just of course you also need to upgrade your teams so that they can handle a lot more tasks on the front-end than with SSRs (and you'll probably need less back-end devs)
  • armandososa 8y ago
    Also, on the majority of SPA frameworks you have the notion of components which makes making the UI a lot simpler than with traditional SSR abstractions (templating and partials are not sufficient).
    • Existenceblinks 8y ago
      Or your backend template engine is weak. In Elixir, EEx used in Phoenix, every template is a function. It's not supper good, but it's component (I hate term "component" and prefer "function")
      • pennaMan 8y ago
        But a component is a function that satisfies certain properties, why would you prefer to not to be precise in your communication? Do you call squares rectangles because you hate the term "squares"?
        • Existenceblinks 8y ago
          In my example, it's very precise that a template _is_ definitely a function. And conceptually I still think of it as function. For your example I'd call it "squares" not because I don't hate it, but I don't think squares has something to do with "component"
  • tspike 8y ago
    Front-end frameworks have a way of going in and out of fashion / support much faster than backend ones.
    • kangoo1707 8y ago
      Not at all, people moves between libraries of the same framework, they will likely refactor jQuery mess into a framework, but it's unlikely for a team to move from React to Vue or Angular (and vice versa).
    • ivanhoe 8y ago
      There was indeed a moment few years ago when front-end frameworks/libs were changing at warp speed, but last year or so I think the situation crystalized a lot. You now have React and Vue as major players and Angular competing for the 3rd place against some fresh libs... and I don't see that changing anytime soon.
      • wolco 8y ago
        Every year this is said like burning man is dead. I predict a bigger react ecosystem. The slide of vue but the raise of the Quasar framework for apps. The rise of Angular once again.
      • jes5199 8y ago
        yeah, you have React, but which of the 30 fashionable state-management libraries are you using? Typescript or Flow? What version of JS syntax? What compiler what minifier? oh hey, half of these just stopped being maintained without warning
      • rat9988 8y ago
        I have always felt as angular was the second major player and vue the one in the 3rd place.
        • ivanhoe 8y ago
          It's possible, especially if you look primarily at the enterprise market. From where I stand (startups, SMEs) it seems like a lot of people moved from Angular 1.x directly to Vue, skipping Angular 2+ versions. I haven't been offered any Angular projects in about 2 years, while React and Vue are really popular. But it's just my perspective, global situation might be different.
  • krferriter 8y ago
    "You simply trade back-end frameworks complexities for the front-end framework complexities" Not necessarily, you can have simple and modular front-ends while also having less complex back-end frameworks. The question is between SPA and non-SPA web applications, not between SPA and JSP/PHP.
  • yellowapple 8y ago
    The complexities of back-end frameworks are far less than the complexities of front-end frameworks in my experience and observation (in particular because the latter tend to needlessly reinvent half of a web browser). Additionally, the back-end complexities still exist when using front-end frameworks (unless you don't actually have a back-end, of course).
• sirsuki 8y ago
  Is there any possibility that the added complexity is a symptom of the framework in use and not a general problem with ALL frameworks? I know I've experienced many projects and found server side rendering more complex then client side when using frameworks like Ember.js.
  • Touche 8y ago
    It's a symptom of the SPA architecture. Since you give up a lot of basic functionality by not using multiple pages, that same functionality has to be reinvented.
  • andrewfong 8y ago
    I'm a front-end engineer, but I'd agree that SPAs are always more complicated than a pure SSR solution: You're inherently doing more. You're probably already tracking state somewhere on the backend (e.g. in a database). An SPA means you now have to track state on the front-end too. There are benefits and things you can do with an SPA that you can't do with pure SSR, but they _do_ come at a cost. TANSTAAFL.
    • collinmanderson 8y ago
      TANSTAAFL stands for: There ain't no such thing as a free lunch But I agree, that seems to be my impression. Single Page Apps allow higher quality User Interfaces (if done right), though they do require more work.
• dimgl 8y ago
  Yeah, I don't buy that. React and Vue are dead simple.
  • Silhouette 8y ago
    React and Vue are dead simple. But if the comparison is with more traditional SSR sites, React and Vue are also not doing everything the back-end was doing before.
  • Existenceblinks 8y ago
    When you talk about React and Vue it should mean React ecosystem or Vue ecosystem, not view layer. Then noting is simple.
• guscost 8y ago
  But this claim is simply wrong in a large percentage of cases (at least among the “web application” projects I have seen firsthand).
• deleted 8y ago
  [deleted]