14 ms·

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

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.
    - dangoor 8y ago
      Indeed, that's true. While I'm not saying they're good for everything, one thing I like about SPAs is that the server can just serve up an API that is usable by both web and mobile clients. No duplication of templating/view logic between server and client as often happens when the server is serving up HTML.
      - deleted 8y ago
        [deleted]
- dscpls 8y ago
  I could make the reverse argument: bad frontend programmers who dont use the facilities available to separate concerns create unmaintainable spaghetti when good backend programmers who separate concerns properly produce beautiful maintainable code. The key being bad programmers dont isolate concerns and good ones do.
- abraae 8y ago
  It doesn't often happen because of Conway's law - that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them. But in many organizations the same people that own the APIs also own the back end. That means it takes discipline and an acceptance of extra costs to keep this separation. Its easiest and cheapest to just slop all the back end together. With an SPA, a different team builds the front end from the back end, and APIs are the only way for them to talk. That acts as a force for good APIs.
  - rhapsodic 8y ago
    >Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them. YAGNI
  - pjc50 8y ago
    IMO it's one of the long-term failures of web architecture for CRUD that there isn't a unified solution for this; not only should they be the same team but they should be in the same repo, quite possibly in the same language, and the number of places a field has to be defined should be as small as possible. Let the machine sort out separation of concerns and what code goes where. Learn something from dBase and FoxPro.
    - a_wild_dandan 8y ago
      Apologies if I misunderstood you, but isn't all of that criteria met by a Node/GraphQL/React app? 1. One language - JavaScript 2. One repo - containing a Node backend, also builds/serves a front end bundle (alternatively use Next.js/etc if SSR is your thing) 3. Use GraphQL schemas to handle your API(s) and consume the minimum necessary data on the client, reduce redundant field declarations One language, one repo, easy & consistent API production/consumption, no?
- donatj 8y ago
  SPA doesn’t guarantee good separation of concerns though. I have seen many a horrible SPA in my day that had all the business logic in the client side JS and zero validation server side. Server basically a very thin wrapper around the database. I’ve been doing this for 15 years, and if I’ve learned anything it’s that developers can figure out ways to abuse anything.
  - insulanian 8y ago
    Separate frontend from backend development and make it even two teams. This makes it much more robust and loosely coupled because both sides protect the interface from each other.
    - mnm1 8y ago
      This works. Now you only need double the engineers to create the same app as you would using a server side framework. Hardly a more powerful argument against SPAs than this.
      - pault 8y ago
        I'm not sure I buy this. I recently worked on a project where we had one .net core developer, a dev ops guy, and me doing the client SPA. We were all able to focus on our core competencies and turn around the project incredibly quickly. I would argue that you can get away with the same team size split between front and back end and possibly end up with a more efficient allocation of resources.
      - donatj 8y ago
        I'd argue more than double considering all the things a good SSR gives you reliably for free.
      - wokwokwok 8y ago
        Perhaps, but if both teams are half the size, specialised and deliver faster, it’s a win. That may not always be the case, but if your SSR team and API team are the same size, your devs suck, bluntly. API based backends are much easier to build, test, manage and look after.
- dvogel 8y ago
  One reason the SSR mess is so easy to walk into is that everyone knows it's a reasonable amount of refactoring to get out of later. The cleanup of an SSR app lacks the deployment headaches of SPAs (doubly so with the service worker layer).
- kissgyorgy 8y ago
  > I would note that generally server side templating is often a mish mash of business logic If you don't have good, experienced senior developers or they don't have discipline, yes. But that's true for any technology. Good developers have the knowledge for simple things like how to separate business logic from templates...
  - Novashi 8y ago
    TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less. It would be nice if, given a task, we could teach people to choose the right approach in code the first time, but given we still have trouble recognizing good developers, the fast-paced churn of rewriting apps is a decent hedge until we figure out how to train the people we want. We seem to only want developers with this skill, but then force them to rewrite stuff often enough so that no actual long-term gains can be realized from their expertise.
    - save_ferris 8y ago
      > TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less. I disagree with this. De-prioritizing code quality because a rewrite is on the horizon is a great way to paint yourself into a very bad corner. Imagine letting your codebase rot with the assumption you're going to rewrite it only to have your CEO walk in one day and completely shift priorities to build some new feature to land a new customer or appease a current one (a not-too-different scenario happened to me once.) Priorities change all the time, and quality code grants the flexibility to adapt to changing priorities.
      - Novashi 8y ago
        Unknown: when random CEO idea occurs Known: we’re definitely rewriting it in two years regardless of this CEO feature The feature probably isn’t that complicated anyway Maybe if you want code quality, stop rewriting so much shit because there’s some new hotness. Probably helps to not have so much new hotness too.
- mattmanser 8y ago
  This is a load of nonsense. If you can't separate concerns in a hybrid MVC pattern, you'll be screwing it up just as much in an SPA. Plus you've got the extra layer of an API to maintain too making it even more complicated, and more likely to spaghettifi, not less.
  - ryukafalz 8y ago
    >Plus you've got the extra layer of an API to maintain too On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.
    - IanCal 8y ago
      Possibly, though your perfect API design may differ significantly from your perfect site structure. It feels reasonable to consider both and see it as a positive if the use cases work.
    - Scarblac 8y ago
      This is also the main argument that keeps me on the side of SPA for our own project, at the moment. Our product is a specialized database with a fancy GUI on top, but we have customers that only use the database through its API; by using it ourselves for our frontends we make sure everything is doable that way. The other argument is that frontend developers are looking for SPA work because they see SPA work everywhere. There's an element of everybody having to go with the flow...
    - eeZah7Ux 8y ago
      Nonsense. People have been doing that for years before the single-page hype. The servers generating HTML contents use the API as their own backend and you have better layering.
      - pvorb 8y ago
- save_ferris 8y ago
  I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose. Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions). The single biggest disadvantage I see with front end apps is that comprehending state management via redux and co. is so complicated, and so, so easy to get wrong. I can tell a coworker to refactor a smelly ERB view and extract out a new template, presenter, whatever. But redux still causes us problems that require refactors months later. It still feels way more cumbersome than being diligent about keeping controller/presenter/template logic clean. We're also far more competent rails developers than we are modern UI developers, and that definitely factors into our productivity.
  - woah 8y ago
    The real issue here was that someone forced a bunch of developers to rewrite their entire product in a stack they don’t know, against their will.
  - acemarke 8y ago
    Hi, I'm a Redux maintainer. Any specific concerns that I can help with? You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-starter-kit.js.org https://redux-starter-kit.js.org
    - jamespollack 8y ago
      i love redux - surface area for bugs is reduced so much compared to the past. thanks!
    - pault 8y ago
      After having some pretty extensive (heated) debates about the merits of redux here on HN, I've come to the opinion that the love/hate for redux is a consequence of the departure from MVC architectures that more experienced developers are accustomed to. There are decades of best practices built up around scaling object oriented MVC architectures, but react and redux come from a completely different school of programming where trying to apply traditional inheritance patterns is impossible and can mortally wound a project. There was an article about entity component systems recently posted here, which are typically used in game programming, and I was shocked at how similar it is to the architectures I use in my react apps. This entry [0] from the ECS wiki is a good summary: > Whereas in an inheritance-based design, an enemy may have a complex inheritance chain such as Damageable <- Actor <- GroundBasedActor <- Enemy <- ZombieEnemy, in a C/ES-based design you might have a Health component, a GroundBasedMovement component and a ZombieAi component added to an entity named ZombieEnemy. This eliminates ambiguity issues encountered in an inheritance-based design (should the root be Actor <- DamageableActor or Damageable <- Actor? Should items be implemented twice as PickupActors or DamageablePickupActors?). At the same time, components can be freely combined: a damageable inventory item? add the Collectable and Health components to an entity. It occurred to me that in a lot of ways, games are just extremely complex user interfaces. So it makes sense that patterns that work well in game architectures should map rather cleanly to application UIs. I'd be interested in hearing if anyone else sees the correlation here, or if I'm just confused and misunderstanding ECS architectures. My email is in my user profile. [0]: http://entity-systems.wikidot.com/ http://entity-systems.wikidot.com/
- JamesBarney 8y ago
  So I could see an issue with someone writing business logic in a view and then someone else rewriting that business logic somewhere else slightly differently. But I've seen the same thing happen in the SPA. Where one person calculates some value in an API method, another doesn't know about it and calculates it again slightly differently in a different method leading to app inconsistencies. And SPA's make it worse not better because it sometimes forces you to write a piece of domain logic twice, once for the browser and once serverside. I honestly don't know what's wrong with accessing query strings or session information. But I think maybe the reason you've seen template code using global state is because the template code was just written earlier back before that information had really soaked into the entire development community.
- rhizome 8y ago
  These problems appear largely academic to me.
Scarbutt 8y ago
Not contradicting you, but how did you evaluated that the SPA is not bringing any value to the customers? It may make work harder for you, it may cost more, but maybe that cost is rightfully justified from a business perspective.
- whitepoplar 8y ago
  As a consumer of SPAs all across the internet, all I seem to get is a bunch of janky, slow, bloated, buggy experiences. Server-rendered views just seem more performant and reliable when done well.
  - deleted 8y ago
    [deleted]
varlogix 8y ago
Same issue at the previous company. Engineering team decided to turn the web app into SPA, and spent months doing this. All that time which could have been spent on building customer value were wasted.
- qudat 8y ago
  It kept the engineers busy and for some even happy.
barbecue_sauce 8y ago
Would it be accurate to characterize your opinion as "SKA not SPA?"
mandeepj 8y ago
Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd like to share thoughts from my current situation. We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it. While I'm not proposing a complete rewrite into SPA, due to - migration requires a lot of effort, huge risk for missing functionality, errors etc. The biggest problem with the product is - app posts back the entire page, which most of the times is huge, even if we changed just one field. The viewstate is enormous. My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it. This approach is also described in MS's silk project - https://www.microsoft.com/en-us/download/details.aspx?id=27290 https://www.microsoft.com/en-us/download/details.aspx?id=272...
- GordonS 8y ago
  > My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then process the result and do something (update a table, display a message, redirect, whatever). I feel like this gives me the best of both worlds - the backend is very testable, and really straightforward for new developers to come up to speed on, while at the same time we remove a lot of full-page renders. You can find an example of this technique here[0] [0] https://github.com/jbogard/ContosoUniversityDotNetCore https://github.com/jbogard/ContosoUniversityDotNetCore
  - hakfoo 8y ago
    I recall one of the more frustrating clients at my old firm. The client was hoping to build a competitor to a fancy all-AJAX industry-specific backoffice application (written by a team of dozens and with a coffee budget alone three times our dev budget) Since they were domain experts, but sort of scatterbrained (oh, we need undisclosed requirement xyz" 3 months into development), we were building it in phases to make sure we could cover their functional needs. It was a rule-based system for validating and analyzing user-provided data, where they'd be responsible for maintaining the rules via an admin backend. It was your typical PHP based request/response lifecycle. They. Could. Not. Get. Over. The. Fact. The. Pages. Reloaded. After. Each. Request. No matter how many times we said "can we focus on making sure the underlying math is right and then polish the UI?" So I finally snapped and implemented that exact same thing. That shut them up enough that they just started disappearing when they were asked for info. I suspect the project had enterred the phase where they were out of money and/or realized they were trying to swallow a bigger task than they could handle themselves. Recently, I saw Turbolinks [0] which looks like the same concept with way more panache. [0] https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
amoitnga 8y ago
> 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).
      - 8y ago
oblib 8y ago
Wow... that is just insane. I've been working alone for so long I've not had to deal with anything like that for years, but I'll offer this... Doesn't matter, so don't let it matter to you. When I worked for others I'd offer my opinion and advice and when it was ignored I'd do it their way every step of the way because it really does not matter. You get paid the same either way. I'll add that because it didn't matter to me I ended up getting to work on some pretty cool stuff. Everyone knew I wouldn't whine about changing directions or being taken off a project and jumping on whatever they wanted so I was almost always the 1st choice to work on something new. When that happened I was often able to influence the direction of the work.
- movedx 8y ago
  Yes. This... yes. All you can do as a professional, with experience, is offer up an argument and attempt to make it convincing enough to compel people to do things your way. If they reject your option, defend only once, and no more. After that, simply step back and work with whatever technologies are decided upon. You can also attempt to work the social networking game and play (internal) politics. If you do these successfully you're more likely to get your ideas heard and implemented. I find this tiresome. Ultimately if I'm being polite, professional and basing my arguments on facts and evidence, and they're being rejected, I'm not expelling any more energy on this front. Move on. Work on and with what's decided and have fun doing it.
  - pojzon 8y ago
    > work with whatever technologies are decided upon. It may sound great when you learn something new, but when you worked with a technology and you know its deprecated crap - as a professional - you should also consider your own career.. Work on crap nobody uses for 5 years and you are so handicapped by that you "will" find a new job, but rather not a good one. Not everyone can spend hours at home to keep up with the industry.
    - oblib 8y ago
      That's true, but not really the same thing. I was looking for work once and went to place that made wheelchair lifts for vans and buses. There was a miscommunication about what they were hiring for and when I got there they took me out to a drill press with a stack of thousands of parts on carts that needed a hole drilled in them. I politely declined the position.
quickthrower2 8y ago
The bank I used has gone from traditional to SPA style, and I wish they hadn't. There is a massive load time before I can even log in with some stupid animation, and they've reduced the exporting features. As a customer I have gained nothing. But I guess it keeps food on the table for some devs.
taude 8y ago
Our team has found the balance by making a bunch of smaller, individual SPAs that make up our whole application. We follow some SPA designs, but have them more modular, and glued together by a bunch of delivery pages. We kind of get the best of both worlds, plus there's some pages and content that just render better on the server, and delivered faster through caching...
ericmcer 8y ago
Anytime you rewrite 12 existing, working web apps in something new it is going to be a huge pain. The only sane way to approach this is the strangler pattern, picking one page/view in one app to rewrite, then another, hooking them up with some kind of client-side router, and slowly letting the SPA consume the old SSR pages. That way you can measure the cost/benefit of each page before deciding it should be added into the SPA.
- jtms 8y ago
  I have had to do this approach before - I hate it so much.
foobaw 8y ago
Sounds like something Stubhub did recently.
rhizome 8y ago
I'd love to hear some trench stories where these kinds of initiatives to increase the complexity of (what appear to be core) business tools were met with what I'll call a "simplicity advocate," who carried the day and the complexity was tempered, if not rejected.
insulanian 8y ago
Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic. Clean separation of frontend SPA and backend API made both sides simpler and more robust. I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.
- kortilla 8y ago
  You can do that separation either way. People working on state sync and actual apis should be different anyway (unless your team is small).
  - insulanian 8y ago
    I'm not convinced. We were using MVC for years and tried different approaches, but the API code is incomparably cleaner when it doesn't deal with client concerns.
- hello_moto 8y ago
  > I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better. In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience. One example would be the disagreement over "Data Model" of front-end vs back-end.
  - jrowley 8y ago
    This where technology like graphql can really shine.
  - pault 8y ago
jordache 8y ago
your anecdotal story doesn't highlight deficiencies with SPA. You only talked about the pains associated with rebuilding apps with different technology to achieve feature parity.
tpkj 8y ago
> "It drives me crazy to think that some exec came up with SPA-ing everything as a sales pitch to clients" In other companies, I wonder if this is just as often due to: (a) developers getting tired of what works reasonably well and wanting to move to a different technology and/or (b) the voices in the tech evangelist community whose own jobs seems to hinge on pitching new and shiny, latest and greatest library/framework/whatever, instilling FOMO and insecurity in the developers who listen to them about not getting on board with the latest and greatest?
anonytrary 8y ago
Eh. The problems you talk about have little to do with SPAs in general, and have more to do with "rewriting things from A to B". If you had started out with SPAs first and wanted to un-SPA everything, you'd be making the same comments. The issues you mentioned aren't intrinsic to SPAs, they're intrinsic in redoing things.
- rainonmoon 8y ago
  You're right, but it's also intrinsic to the senselessly shifting paradigm/bandwagon-jumping around SPAs. It's not just that redoing things is a problem, but that the motivation behind the rehaul is poorly conceived.
  - anonytrary 8y ago
    I think that's how the cookie crumbles, unfortunately. Most companies want to be on the biggest bandwagon to ensure they have a steady supply of fresh, young employees. Few companies want to rely on niche software that only a few people know how to work with. As long as younger people keep jumping onto new trends, companies will continue to follow.
unclebucknasty 8y ago
The hybrid approach sounds good, but I've found it frequently non-trivial to pull off in practice. In my experience, you have to be really thoughtful about what and how much you make dynamic. For instance, if you start to rely heavily on dynamic capabilities to render key components, such as detail views/overlays, then you have to start reasoning about making them accessible via their own URL to enable direct access, browser reloads, sharing, etc. By the time you've done that, you've started duplicating browser functionality via routing, history, etc, and generally working to create an app that coexists peacefully within an app. In other words, you quickly move into SPA territory and all that that entails. But, if that causes you to be more conservative about sprinkling in dynamic capabilities, then you're really much closer to an old school SSR app and not realizing a lot of the purorted benefits of a SPA, or much else beyond the old school AJAX approaches. Not to say that's useless, but we've long since been down that road, and it doesn't represent any new thinking. So, it's just hard to find balance there. In most cases, you're really either a SPA or you're not.
qudat 8y ago
On the flip side, I recently worked on a "hybrid" project that has been around for a couple years. It was a nightmare knowing when SSR stopped and SPA began. There was no consistency, multiple ways to do the same thing, and poorly maintained. It was schizophrenic. I think the real issue you are dealing with is what others mentioned: rebuilding something from scratch burns a ton of people-hours and money. Asking a bunch of rails developers to lean into FE development is a recipe for animosity and to me it shows in this post.
Existenceblinks 8y ago
Yeah we have read experiences like yours again and again on every HN thread about SPA, but why we never learn? We developers kind of helping this fashion to happen.
- krapp 8y ago
  Nine times out of ten, we developers aren't in a position to make or change business decisions of that magnitude. Remember, every time you tell your boss to do something they don't want to do, you're telling them to spend money they don't want to spend, and if it's something you were hired to do, you're also placing your own value as an employee in question.
  - Existenceblinks 8y ago
    True but I was talking about the producer side, those cool kids in big corps. They have money backed and drive small companies to adopt the next cool things.
skydv 8y ago
That's not SPAs problem, that's your company specific problem. It is always painful to migrate. You need to re-wire the logic, change the shoes in the air. Your comment being on top is ridiculous

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.
  - dangoor 8y ago
    Indeed, that's true. While I'm not saying they're good for everything, one thing I like about SPAs is that the server can just serve up an API that is usable by both web and mobile clients. No duplication of templating/view logic between server and client as often happens when the server is serving up HTML.
    - deleted 8y ago
      [deleted]
dscpls 8y ago
I could make the reverse argument: bad frontend programmers who dont use the facilities available to separate concerns create unmaintainable spaghetti when good backend programmers who separate concerns properly produce beautiful maintainable code. The key being bad programmers dont isolate concerns and good ones do.
abraae 8y ago
It doesn't often happen because of Conway's law - that "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations." Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them. But in many organizations the same people that own the APIs also own the back end. That means it takes discipline and an acceptance of extra costs to keep this separation. Its easiest and cheapest to just slop all the back end together. With an SPA, a different team builds the front end from the back end, and APIs are the only way for them to talk. That acts as a force for good APIs.
- rhapsodic 8y ago
  >Its always possible to architect the web/app back end to do everything through APIs, keeping the APIs pure, and ensuring that others will be able to build UIs on top of them. YAGNI
- pjc50 8y ago
  IMO it's one of the long-term failures of web architecture for CRUD that there isn't a unified solution for this; not only should they be the same team but they should be in the same repo, quite possibly in the same language, and the number of places a field has to be defined should be as small as possible. Let the machine sort out separation of concerns and what code goes where. Learn something from dBase and FoxPro.
  - a_wild_dandan 8y ago
    Apologies if I misunderstood you, but isn't all of that criteria met by a Node/GraphQL/React app? 1. One language - JavaScript 2. One repo - containing a Node backend, also builds/serves a front end bundle (alternatively use Next.js/etc if SSR is your thing) 3. Use GraphQL schemas to handle your API(s) and consume the minimum necessary data on the client, reduce redundant field declarations One language, one repo, easy & consistent API production/consumption, no?
donatj 8y ago
SPA doesn’t guarantee good separation of concerns though. I have seen many a horrible SPA in my day that had all the business logic in the client side JS and zero validation server side. Server basically a very thin wrapper around the database. I’ve been doing this for 15 years, and if I’ve learned anything it’s that developers can figure out ways to abuse anything.
- insulanian 8y ago
  Separate frontend from backend development and make it even two teams. This makes it much more robust and loosely coupled because both sides protect the interface from each other.
  - mnm1 8y ago
    This works. Now you only need double the engineers to create the same app as you would using a server side framework. Hardly a more powerful argument against SPAs than this.
    - pault 8y ago
      I'm not sure I buy this. I recently worked on a project where we had one .net core developer, a dev ops guy, and me doing the client SPA. We were all able to focus on our core competencies and turn around the project incredibly quickly. I would argue that you can get away with the same team size split between front and back end and possibly end up with a more efficient allocation of resources.
    - donatj 8y ago
      I'd argue more than double considering all the things a good SSR gives you reliably for free.
    - wokwokwok 8y ago
      Perhaps, but if both teams are half the size, specialised and deliver faster, it’s a win. That may not always be the case, but if your SSR team and API team are the same size, your devs suck, bluntly. API based backends are much easier to build, test, manage and look after.
dvogel 8y ago
One reason the SSR mess is so easy to walk into is that everyone knows it's a reasonable amount of refactoring to get out of later. The cleanup of an SSR app lacks the deployment headaches of SPAs (doubly so with the service worker layer).
kissgyorgy 8y ago
> I would note that generally server side templating is often a mish mash of business logic If you don't have good, experienced senior developers or they don't have discipline, yes. But that's true for any technology. Good developers have the knowledge for simple things like how to separate business logic from templates...
- Novashi 8y ago
  TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less. It would be nice if, given a task, we could teach people to choose the right approach in code the first time, but given we still have trouble recognizing good developers, the fast-paced churn of rewriting apps is a decent hedge until we figure out how to train the people we want. We seem to only want developers with this skill, but then force them to rewrite stuff often enough so that no actual long-term gains can be realized from their expertise.
  - save_ferris 8y ago
    > TBH if the thing is getting rewritten every two years because of $new_paradigm, code quality matters less. I disagree with this. De-prioritizing code quality because a rewrite is on the horizon is a great way to paint yourself into a very bad corner. Imagine letting your codebase rot with the assumption you're going to rewrite it only to have your CEO walk in one day and completely shift priorities to build some new feature to land a new customer or appease a current one (a not-too-different scenario happened to me once.) Priorities change all the time, and quality code grants the flexibility to adapt to changing priorities.
    - Novashi 8y ago
      Unknown: when random CEO idea occurs Known: we’re definitely rewriting it in two years regardless of this CEO feature The feature probably isn’t that complicated anyway Maybe if you want code quality, stop rewriting so much shit because there’s some new hotness. Probably helps to not have so much new hotness too.
mattmanser 8y ago
This is a load of nonsense. If you can't separate concerns in a hybrid MVC pattern, you'll be screwing it up just as much in an SPA. Plus you've got the extra layer of an API to maintain too making it even more complicated, and more likely to spaghettifi, not less.
- ryukafalz 8y ago
  >Plus you've got the extra layer of an API to maintain too On the other hand, if you're providing a service that will always have an API, and you want to make sure that all the functionality you provide is nicely accessible through the API, building the frontend on top of it can be a good approach. The developers at the company I work for have done this, and IMO it's worked out pretty well.
  - IanCal 8y ago
    Possibly, though your perfect API design may differ significantly from your perfect site structure. It feels reasonable to consider both and see it as a positive if the use cases work.
  - Scarblac 8y ago
    This is also the main argument that keeps me on the side of SPA for our own project, at the moment. Our product is a specialized database with a fancy GUI on top, but we have customers that only use the database through its API; by using it ourselves for our frontends we make sure everything is doable that way. The other argument is that frontend developers are looking for SPA work because they see SPA work everywhere. There's an element of everybody having to go with the flow...
  - eeZah7Ux 8y ago
    Nonsense. People have been doing that for years before the single-page hype. The servers generating HTML contents use the API as their own backend and you have better layering.
    - pvorb 8y ago
save_ferris 8y ago
I completely agree that a big part of this conversation falls on ensuring code quality is maintained over time, regardless of the architecture you choose. Fortunately, I inherited a set of pretty well-maintained SSR rails apps, and they've been pretty straightforward to continue working on (with a couple of exceptions). The single biggest disadvantage I see with front end apps is that comprehending state management via redux and co. is so complicated, and so, so easy to get wrong. I can tell a coworker to refactor a smelly ERB view and extract out a new template, presenter, whatever. But redux still causes us problems that require refactors months later. It still feels way more cumbersome than being diligent about keeping controller/presenter/template logic clean. We're also far more competent rails developers than we are modern UI developers, and that definitely factors into our productivity.
- woah 8y ago
  The real issue here was that someone forced a bunch of developers to rewrite their entire product in a stack they don’t know, against their will.
- acemarke 8y ago
  Hi, I'm a Redux maintainer. Any specific concerns that I can help with? You might want to check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-starter-kit.js.org https://redux-starter-kit.js.org
  - jamespollack 8y ago
    i love redux - surface area for bugs is reduced so much compared to the past. thanks!
  - pault 8y ago
    After having some pretty extensive (heated) debates about the merits of redux here on HN, I've come to the opinion that the love/hate for redux is a consequence of the departure from MVC architectures that more experienced developers are accustomed to. There are decades of best practices built up around scaling object oriented MVC architectures, but react and redux come from a completely different school of programming where trying to apply traditional inheritance patterns is impossible and can mortally wound a project. There was an article about entity component systems recently posted here, which are typically used in game programming, and I was shocked at how similar it is to the architectures I use in my react apps. This entry [0] from the ECS wiki is a good summary: > Whereas in an inheritance-based design, an enemy may have a complex inheritance chain such as Damageable <- Actor <- GroundBasedActor <- Enemy <- ZombieEnemy, in a C/ES-based design you might have a Health component, a GroundBasedMovement component and a ZombieAi component added to an entity named ZombieEnemy. This eliminates ambiguity issues encountered in an inheritance-based design (should the root be Actor <- DamageableActor or Damageable <- Actor? Should items be implemented twice as PickupActors or DamageablePickupActors?). At the same time, components can be freely combined: a damageable inventory item? add the Collectable and Health components to an entity. It occurred to me that in a lot of ways, games are just extremely complex user interfaces. So it makes sense that patterns that work well in game architectures should map rather cleanly to application UIs. I'd be interested in hearing if anyone else sees the correlation here, or if I'm just confused and misunderstanding ECS architectures. My email is in my user profile. [0]: http://entity-systems.wikidot.com/ http://entity-systems.wikidot.com/
JamesBarney 8y ago
So I could see an issue with someone writing business logic in a view and then someone else rewriting that business logic somewhere else slightly differently. But I've seen the same thing happen in the SPA. Where one person calculates some value in an API method, another doesn't know about it and calculates it again slightly differently in a different method leading to app inconsistencies. And SPA's make it worse not better because it sometimes forces you to write a piece of domain logic twice, once for the browser and once serverside. I honestly don't know what's wrong with accessing query strings or session information. But I think maybe the reason you've seen template code using global state is because the template code was just written earlier back before that information had really soaked into the entire development community.
rhizome 8y ago
These problems appear largely academic to me.

Scarbutt 8y ago

Not contradicting you, but how did you evaluated that the SPA is not bringing any value to the customers? It may make work harder for you, it may cost more, but maybe that cost is rightfully justified from a business perspective.

whitepoplar 8y ago
As a consumer of SPAs all across the internet, all I seem to get is a bunch of janky, slow, bloated, buggy experiences. Server-rendered views just seem more performant and reliable when done well.
- deleted 8y ago
  [deleted]

varlogix 8y ago

Same issue at the previous company. Engineering team decided to turn the web app into SPA, and spent months doing this. All that time which could have been spent on building customer value were wasted.

qudat 8y ago
It kept the engineers busy and for some even happy.

barbecue_sauce 8y ago

Would it be accurate to characterize your opinion as "SKA not SPA?"

mandeepj 8y ago

Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd like to share thoughts from my current situation. We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it. While I'm not proposing a complete rewrite into SPA, due to - migration requires a lot of effort, huge risk for missing functionality, errors etc. The biggest problem with the product is - app posts back the entire page, which most of the times is huge, even if we changed just one field. The viewstate is enormous. My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it. This approach is also described in MS's silk project - https://www.microsoft.com/en-us/download/details.aspx?id=27290 https://www.microsoft.com/en-us/download/details.aspx?id=272...

GordonS 8y ago
> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then process the result and do something (update a table, display a message, redirect, whatever). I feel like this gives me the best of both worlds - the backend is very testable, and really straightforward for new developers to come up to speed on, while at the same time we remove a lot of full-page renders. You can find an example of this technique here[0] [0] https://github.com/jbogard/ContosoUniversityDotNetCore https://github.com/jbogard/ContosoUniversityDotNetCore
- hakfoo 8y ago
  I recall one of the more frustrating clients at my old firm. The client was hoping to build a competitor to a fancy all-AJAX industry-specific backoffice application (written by a team of dozens and with a coffee budget alone three times our dev budget) Since they were domain experts, but sort of scatterbrained (oh, we need undisclosed requirement xyz" 3 months into development), we were building it in phases to make sure we could cover their functional needs. It was a rule-based system for validating and analyzing user-provided data, where they'd be responsible for maintaining the rules via an admin backend. It was your typical PHP based request/response lifecycle. They. Could. Not. Get. Over. The. Fact. The. Pages. Reloaded. After. Each. Request. No matter how many times we said "can we focus on making sure the underlying math is right and then polish the UI?" So I finally snapped and implemented that exact same thing. That shut them up enough that they just started disappearing when they were asked for info. I suspect the project had enterred the phase where they were out of money and/or realized they were trying to swallow a bigger task than they could handle themselves. Recently, I saw Turbolinks [0] which looks like the same concept with way more panache. [0] https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks

amoitnga 8y ago

> 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).
    - 8y ago

oblib 8y ago

Wow... that is just insane. I've been working alone for so long I've not had to deal with anything like that for years, but I'll offer this... Doesn't matter, so don't let it matter to you. When I worked for others I'd offer my opinion and advice and when it was ignored I'd do it their way every step of the way because it really does not matter. You get paid the same either way. I'll add that because it didn't matter to me I ended up getting to work on some pretty cool stuff. Everyone knew I wouldn't whine about changing directions or being taken off a project and jumping on whatever they wanted so I was almost always the 1st choice to work on something new. When that happened I was often able to influence the direction of the work.

movedx 8y ago
Yes. This... yes. All you can do as a professional, with experience, is offer up an argument and attempt to make it convincing enough to compel people to do things your way. If they reject your option, defend only once, and no more. After that, simply step back and work with whatever technologies are decided upon. You can also attempt to work the social networking game and play (internal) politics. If you do these successfully you're more likely to get your ideas heard and implemented. I find this tiresome. Ultimately if I'm being polite, professional and basing my arguments on facts and evidence, and they're being rejected, I'm not expelling any more energy on this front. Move on. Work on and with what's decided and have fun doing it.
- pojzon 8y ago
  > work with whatever technologies are decided upon. It may sound great when you learn something new, but when you worked with a technology and you know its deprecated crap - as a professional - you should also consider your own career.. Work on crap nobody uses for 5 years and you are so handicapped by that you "will" find a new job, but rather not a good one. Not everyone can spend hours at home to keep up with the industry.
  - oblib 8y ago
    That's true, but not really the same thing. I was looking for work once and went to place that made wheelchair lifts for vans and buses. There was a miscommunication about what they were hiring for and when I got there they took me out to a drill press with a stack of thousands of parts on carts that needed a hole drilled in them. I politely declined the position.

quickthrower2 8y ago

The bank I used has gone from traditional to SPA style, and I wish they hadn't. There is a massive load time before I can even log in with some stupid animation, and they've reduced the exporting features. As a customer I have gained nothing. But I guess it keeps food on the table for some devs.

taude 8y ago

Our team has found the balance by making a bunch of smaller, individual SPAs that make up our whole application. We follow some SPA designs, but have them more modular, and glued together by a bunch of delivery pages. We kind of get the best of both worlds, plus there's some pages and content that just render better on the server, and delivered faster through caching...

ericmcer 8y ago

Anytime you rewrite 12 existing, working web apps in something new it is going to be a huge pain. The only sane way to approach this is the strangler pattern, picking one page/view in one app to rewrite, then another, hooking them up with some kind of client-side router, and slowly letting the SPA consume the old SSR pages. That way you can measure the cost/benefit of each page before deciding it should be added into the SPA.

jtms 8y ago
I have had to do this approach before - I hate it so much.

foobaw 8y ago

Sounds like something Stubhub did recently.

rhizome 8y ago

I'd love to hear some trench stories where these kinds of initiatives to increase the complexity of (what appear to be core) business tools were met with what I'll call a "simplicity advocate," who carried the day and the complexity was tempered, if not rejected.

insulanian 8y ago

Well, in our case moving from server side MVC to SPA approach has drastically increased productivity and stability of our applications. MVC approach was a hairball of code where 2/3 was dealing with synchronization of state between client and server, and only 1/3 being related to actual application logic. Clean separation of frontend SPA and backend API made both sides simpler and more robust. I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better.

kortilla 8y ago
You can do that separation either way. People working on state sync and actual apis should be different anyway (unless your team is small).
- insulanian 8y ago
  I'm not convinced. We were using MVC for years and tried different approaches, but the API code is incomparably cleaner when it doesn't deal with client concerns.
hello_moto 8y ago
> I would also wholeheartedly recommend separating the development into two teams (frontend / backend) . It makes both pieces of the application even more robust due to both teams guarding the interface with the other part even better. In theory, we should strive for that. In practice, back-end team tend to strive on "technical purity" and would ask the front-end team to take any hacks/workarounds necessary to deliver "compelling" user-experience. One example would be the disagreement over "Data Model" of front-end vs back-end.
- jrowley 8y ago
  This where technology like graphql can really shine.
- pault 8y ago

jordache 8y ago

your anecdotal story doesn't highlight deficiencies with SPA. You only talked about the pains associated with rebuilding apps with different technology to achieve feature parity.

tpkj 8y ago

> "It drives me crazy to think that some exec came up with SPA-ing everything as a sales pitch to clients" In other companies, I wonder if this is just as often due to: (a) developers getting tired of what works reasonably well and wanting to move to a different technology and/or (b) the voices in the tech evangelist community whose own jobs seems to hinge on pitching new and shiny, latest and greatest library/framework/whatever, instilling FOMO and insecurity in the developers who listen to them about not getting on board with the latest and greatest?

anonytrary 8y ago

Eh. The problems you talk about have little to do with SPAs in general, and have more to do with "rewriting things from A to B". If you had started out with SPAs first and wanted to un-SPA everything, you'd be making the same comments. The issues you mentioned aren't intrinsic to SPAs, they're intrinsic in redoing things.

rainonmoon 8y ago
You're right, but it's also intrinsic to the senselessly shifting paradigm/bandwagon-jumping around SPAs. It's not just that redoing things is a problem, but that the motivation behind the rehaul is poorly conceived.
- anonytrary 8y ago
  I think that's how the cookie crumbles, unfortunately. Most companies want to be on the biggest bandwagon to ensure they have a steady supply of fresh, young employees. Few companies want to rely on niche software that only a few people know how to work with. As long as younger people keep jumping onto new trends, companies will continue to follow.

unclebucknasty 8y ago

The hybrid approach sounds good, but I've found it frequently non-trivial to pull off in practice. In my experience, you have to be really thoughtful about what and how much you make dynamic. For instance, if you start to rely heavily on dynamic capabilities to render key components, such as detail views/overlays, then you have to start reasoning about making them accessible via their own URL to enable direct access, browser reloads, sharing, etc. By the time you've done that, you've started duplicating browser functionality via routing, history, etc, and generally working to create an app that coexists peacefully within an app. In other words, you quickly move into SPA territory and all that that entails. But, if that causes you to be more conservative about sprinkling in dynamic capabilities, then you're really much closer to an old school SSR app and not realizing a lot of the purorted benefits of a SPA, or much else beyond the old school AJAX approaches. Not to say that's useless, but we've long since been down that road, and it doesn't represent any new thinking. So, it's just hard to find balance there. In most cases, you're really either a SPA or you're not.

qudat 8y ago

On the flip side, I recently worked on a "hybrid" project that has been around for a couple years. It was a nightmare knowing when SSR stopped and SPA began. There was no consistency, multiple ways to do the same thing, and poorly maintained. It was schizophrenic. I think the real issue you are dealing with is what others mentioned: rebuilding something from scratch burns a ton of people-hours and money. Asking a bunch of rails developers to lean into FE development is a recipe for animosity and to me it shows in this post.

Existenceblinks 8y ago

Yeah we have read experiences like yours again and again on every HN thread about SPA, but why we never learn? We developers kind of helping this fashion to happen.

krapp 8y ago
Nine times out of ten, we developers aren't in a position to make or change business decisions of that magnitude. Remember, every time you tell your boss to do something they don't want to do, you're telling them to spend money they don't want to spend, and if it's something you were hired to do, you're also placing your own value as an employee in question.
- Existenceblinks 8y ago
  True but I was talking about the producer side, those cool kids in big corps. They have money backed and drive small companies to adopt the next cool things.

skydv 8y ago

That's not SPAs problem, that's your company specific problem. It is always painful to migrate. You need to re-wire the logic, change the shoes in the air. Your comment being on top is ridiculous