10 ms·

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

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.

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.