Why Is Front-End Development So Unstable?

Well, I can say that I am just coming out of few years long miserable period of my life that came after I was kicked out of Canada thanks to "LMIA disaster" after spending 6 years of my life securing my future in the country. Right now, I am easily passing under the points system, but nah, after such shameless bait and switch with immigration policy, there is no way I am going back.

Good things, I am out of webdev as an industry, and finally working in a more serious function in an engineering consulting now - something I was aiming at from my teen years, when I was still not in "money over job satisfaction" mode of thinking.

>I picked up Python at 14 and that had absolutely no barriers for entry other than installing IDLE on a laptop.

Will you ever be employed by a "serious company" to make commercial desktop software just for few demos you show from your laptop?

I think the instability is a byproduct of what it is.

Today we have https://caniuse.com but this sort of tool in one form or another has existed for a long time - I think that mobile, and native mobile have only compounded the problem.

Frameworks, and ecosystems (Node, and what it spawned) are practically a requirement to get things done. But abstracting issues away from front end developers, hiding them behind hacks and fixes only serves to make things worse, and harder.

The foundation of the front end isn't just broken, it is a fuckstorm... and we keep piling more stuff on top of that foundation trying to make it make sense, make it rational. With each layer we add creating new sets of issues that only get worse over time. Then someone "smart" enough to build something a bit better does just that, and we get this: https://xkcd.com/927/

The reality is that the fish stinks from the head and in this case, blame google, apple, MS, and Firefox - https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-die-but-...

Javascript isn't much better https://ariya.io/2014/05/the-curious-case-of-javascript-nan ---

(Note the above links are just my favorite "examples" of these issues not even a good indicator of the real problems therein, everyone has their own grievances)

And this IS the heart of the issue. Any one sane, any one with a high level of skill isn't going to want to work in an environment where they aren't in control where someone can yank the carpet out from under them at any given moment. No one is going to stay long when new browsers and missing packages create more work, or work that has to be re-done to deal with some edge case or issue that literally came out of nowhere. Front end people see those of us working on server side code where we have a HIGH degree of control (orders of magnitude) and realize how bad it is for themselves. Simply put any one who is good invests the time and energy to get OUT of that line of work. Tallent will quickly migrate away from the broken foundation of the front end. This only serves to exacerbate the situation, as a new "smart" person onboards thinking "I can do this better" and being right to some degree.

I think I'd add to this comment that you can't solve a lot of these problems with more code because in the browser code size is a very significant factor. On the desktop, or even on mobile, code size isn't very important. So we can have big libraries that do a lot of work.

I think this is a piece by someone who has not really been in front end web development as a career (or does not specialize in it) for very many years. The author's thesis is that 'poor choice architecture' is what drives churn in front end. I disagree. The churn in JS tech has reduced over the past few years.

Some of the churn was in part due to limitations of the web platform. ES5 was limited in features. The web has evolved a lot, and now we don't need to depend on every framework re-inventing things like modules.

React has been around for 5 years now, and it's still the dominant choice for front end architecture. This is not by accident. React solves some of the biggest challenges in front end development with a clean, minimalistic component API, a virtual DOM abstraction to minimize re-renders, JSX (still superior to underpowered template languages), and one-way data flow (which makes refactoring and state management easier). Also functional component model has implications that it can render to any target.

React is not just a web development innovation, it's a UI innovation. There has never been a desktop UI framework with this much flexibility and power. You can target web, native mobile, native desktop, create custom canvas-rendering if you like, render to touch bar, VR, etc...no limits.

The author sort of implies that a one-size-fits-all framework or some standard way of doing things across all projects would lead to less frustration and less churn in the JS community.

We've seen many attempts at this (Ember, Angular, etc). The thing is, not all projects have the same needs. The web is a big place. There are simple web pages with mostly text content (and little need for JS) all the way to rich apps with interactive video, real time chat, dynamic graphs and complex customized data feeds for each user. There is no one-size-fits-all comprehensive framework that will ever meet those demands. For the easy projects, they're overkill and for the complex, long-lived projects, you're likely to beat your head against the limitations of the framework.

The innovation that has come in state management, style management, and component-based design in the past few years is unrivaled by any other UI community. I think the article is a surface level grasp at the situation. It implies that the JS community is spinning its wheels instead of producing solid long-lasting paradigms for application development. I disagree.