3 ms·

There are lots of applications which don't really benefit from being an SPA (blogs, books, etc.). As soon as you start thinking about meaningful interactions y

by koblas 8y ago

There are lots of applications which don't really benefit from being an SPA (blogs, books, etc.). As soon as you start thinking about meaningful interactions you quickly start having to pile enough JavaScript into the HTML that you quickly run into a mess - defining ways to marshal data back and forth with an ad-hoc structure. While SPA tooling like React are incomplete since they don't provide all of the client/server data communications that comes for free with a server side application. That is starting to become more "standard" as GraphQL and Apollo start filling the gap of boilerplate. Though of course wrapping your head around GraphQL takes a bit of work for anybody who's spent their life with REST. Most applications should be SPAs to create the interactions that users expect.

taeric 8y ago
This builds an implication that spa tooling is the way to avoid a mess. Which is ironic to me. As soon as the teams I've seen start piling a ton of extra stuff into the UI, be it types to make things more safe or logic to make things feel faster, you get a mess. Note I'm not claiming either of those are the problem. More code is just almost always more mess. Keep it small. If possible, keep it separate.
- koblas 8y ago
  There are two forms of mess in my experience, none of them have to do with SPA. 1) You have the problems that different developers have different styles. So when you jump from one area to another in the code base you're hit with WFT this is functional/procedural/inheritiance/composition, etc. style and your first thought is "barf" they did it wrong... 2) People either have huge functions that are spaghetti or tiny little functions to avoid complexity that are one line if statements. Both of these are usually rooted in lack of a shared code culture, these are not SPA issues but team issues.
  - cle 8y ago
    These could also partially be language and tooling issues. There are some languages that are so “powerful”, “flexible”, and unopinionated that every developer has dramatically different coding styles (JavaScript, Scala, etc.). On the other end of the spectrum are tightly prescriptive, constrained languages where everyone’s code looks the same (Go comes to mind). No doubt team culture plays a part as well, but in team settings it is important to pick tools that are designed for team settings. These tend to prioritize regularity, lack of flexibility, syntactic simplicity, static analysis, etc.
  - taeric 8y ago
    Oddly, I would sum up both of those as bikeshedding problems. I agree it is a team issue. I know the world is sick of gardening metaphors, but I do feel like there are lessons from community gardens. (Really any community thing.) You will usually have an owner that will paint broad strokes of what the rules are. Then, a bunch of spots that contributors are touching regularly. In their contributions, the rules are much more free form. But, you don't typically have people moving rapidly between contribution zones. Which gets me to my favorite take on the answer. Solving the customer problem is not necessarily the same as solving any developer problem. If you are lucky, you can align them. However, as a developer brutal honest with self in "did this change actually provide any value to the customer" has to be constantly asked.

by koblas 8y ago

taeric 8y ago

This builds an implication that spa tooling is the way to avoid a mess. Which is ironic to me. As soon as the teams I've seen start piling a ton of extra stuff into the UI, be it types to make things more safe or logic to make things feel faster, you get a mess. Note I'm not claiming either of those are the problem. More code is just almost always more mess. Keep it small. If possible, keep it separate.

koblas 8y ago
There are two forms of mess in my experience, none of them have to do with SPA. 1) You have the problems that different developers have different styles. So when you jump from one area to another in the code base you're hit with WFT this is functional/procedural/inheritiance/composition, etc. style and your first thought is "barf" they did it wrong... 2) People either have huge functions that are spaghetti or tiny little functions to avoid complexity that are one line if statements. Both of these are usually rooted in lack of a shared code culture, these are not SPA issues but team issues.
- cle 8y ago
  These could also partially be language and tooling issues. There are some languages that are so “powerful”, “flexible”, and unopinionated that every developer has dramatically different coding styles (JavaScript, Scala, etc.). On the other end of the spectrum are tightly prescriptive, constrained languages where everyone’s code looks the same (Go comes to mind). No doubt team culture plays a part as well, but in team settings it is important to pick tools that are designed for team settings. These tend to prioritize regularity, lack of flexibility, syntactic simplicity, static analysis, etc.
- taeric 8y ago
  Oddly, I would sum up both of those as bikeshedding problems. I agree it is a team issue. I know the world is sick of gardening metaphors, but I do feel like there are lessons from community gardens. (Really any community thing.) You will usually have an owner that will paint broad strokes of what the rules are. Then, a bunch of spots that contributors are touching regularly. In their contributions, the rules are much more free form. But, you don't typically have people moving rapidly between contribution zones. Which gets me to my favorite take on the answer. Solving the customer problem is not necessarily the same as solving any developer problem. If you are lucky, you can align them. However, as a developer brutal honest with self in "did this change actually provide any value to the customer" has to be constantly asked.