3 ms·

While I think it's important to fight against the "FE is easy; BE is real programming" stigma, I think you're going bit too much in the other direction. You're

While I think it's important to fight against the "FE is easy; BE is real programming" stigma, I think you're going bit too much in the other direction. You're painting FE almost as the most difficult thing that exists. However, it's not like GUI applications is a new thing. GUI applications which talks to the Internet is not exactly groundbreaking either. > Updating a user’s role on the BE is a single SQL operation Exactly! Updating a user's role on the BE is actually a really difficult task: You need to persist the data in a safe way and ensure that it's consistent with other concurrent actions that happens. These hard problems have been worked on for 50 years and what we've ended up with is a set of solid tools (SQL databases that provides transactions). It's thanks to these tools that BE becomes easy. These tools have also been built on top of each other. A new tool often "extends" an older tool instead of "replacing" it. It comparison, look at some of the "progress" in the tooling in the front-end world: One of the biggest recent change in state management is React Hooks. This is a concept which has zero precedence in any language or literature. It's something they invented out of thin air and behaves like nothing else out there. The documentation has a big list of gotchas you need to watch out for. Does it has its advantages? Sure, it's nice for many things. But of course there's going to be rough edges when introducing such novel concepts. Cocoa has been successfully using view controllers for state management for 20 years (or more?). They've made some tweaks over the years (e.g. segues), but it's mainly stayed the same. Is state management perfect in Cocoa? No. Do you hear Cocoa developers complain about state management? Yes. Do they spend every year talking about the "new best way to handle state"? Nope. I understand that it's not completely comparable (different platforms etc), but of course state management becomes a recurring problem when you end up switching out the state management library every second year (Redux anyone?).

nojvek 6y ago
You are right about JS fragmentation. After doing 10+ years of frontend, my theory is that frontend welcomes a lot of new self learnt programmers mostly because the browser is the runtime and almost every device has it. This means it’s pretty easy to stitch a few things and get something useful in the hands of customers. Npm makes it very easy to create new packages and libraries. All though not a significant % of community has computer science background and deeply understand what goes under the hood. StateOfJS contains stats of new programmers : old ones. Things that stay the same after a long period of time and stay successful have been reasoned from first principles to satisfy its constraints in the most efficient way possible. E.g svelte was built up this way, to track changes and propagate dom mutations in a very efficient way while still keeping the invariant of view= state of function. My point is that many things in JS are made without such fundamental analysis, so you see churn. I’m a fan of esbuild since it’s built from fundamentals (parse the AST from source only once and utilize all cores while doing it, it saturates available disk bandwidth since go is amazingly efficient at it) Those ideas are here to stay for a long time.
wildermuthn 6y ago
You’re right, I did go overboard. The hardest thing I did last year was battling race-conditions for concurrent BE operations. By far. But your point about some BE problems being solved and Cocoa state management still receiving complaints, suggests that browser state management still remains an unsolved problem. Having said that, Apollo Client’s local field type definitions (akin to GraphQL resolvers for FE state) are as close as a solution as I’ve ever seen. To add to your point, I do think that most complexity should be delegated to the BE, because the BE is almost always better equipped to handle it.

nojvek 6y ago

You are right about JS fragmentation. After doing 10+ years of frontend, my theory is that frontend welcomes a lot of new self learnt programmers mostly because the browser is the runtime and almost every device has it. This means it’s pretty easy to stitch a few things and get something useful in the hands of customers. Npm makes it very easy to create new packages and libraries. All though not a significant % of community has computer science background and deeply understand what goes under the hood. StateOfJS contains stats of new programmers : old ones. Things that stay the same after a long period of time and stay successful have been reasoned from first principles to satisfy its constraints in the most efficient way possible. E.g svelte was built up this way, to track changes and propagate dom mutations in a very efficient way while still keeping the invariant of view= state of function. My point is that many things in JS are made without such fundamental analysis, so you see churn. I’m a fan of esbuild since it’s built from fundamentals (parse the AST from source only once and utilize all cores while doing it, it saturates available disk bandwidth since go is amazingly efficient at it) Those ideas are here to stay for a long time.

wildermuthn 6y ago

You’re right, I did go overboard. The hardest thing I did last year was battling race-conditions for concurrent BE operations. By far. But your point about some BE problems being solved and Cocoa state management still receiving complaints, suggests that browser state management still remains an unsolved problem. Having said that, Apollo Client’s local field type definitions (akin to GraphQL resolvers for FE state) are as close as a solution as I’ve ever seen. To add to your point, I do think that most complexity should be delegated to the BE, because the BE is almost always better equipped to handle it.