10 ms·

> 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

> 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. This doesn't seem like a problem of "MVC vs SPA". The same problem would occur if you were ordered to rebuild 12 apps written in Rails ( or whatever full-stack MVC framework) in a different one, like Django, for example. You'd experience the same pain. The story of rewriting Netscape comes to mind and a few others. Point being, not much value in rewriting something that works in different language.

brazzy 8y ago
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 front end frameworks
- 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]
deleted 8y ago
[deleted]

brazzy 8y ago

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 front end frameworks

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]

deleted 8y ago

[deleted]