Why is front-end development so unstable? (2018)
breck-mckye.com
breck-mckye.com
I think there are a lot of _vendors_ trying to usher in a revolution around their particular products - there's a lot of VC funding in JavaScript tooling nowadays - but that's a different problem.
- grunt / broccoli / gulp / browserify / webpack / metro / esbuild / parcel / swc / turborepo / bun
- flummox / redux / unstated / mobx / mobx-state-tree / xstate / apollo / apollo-link-state / swr / react-query / zustand / recoil / jotai
And this is just within React, and off the top of my head. Then you add all the ECMAScript versions, browser feature churn, node.js, npm/yarn, immutability, classes, functional components, hooks, fiber, the list goes on and on.
Anyone who feels compelled to jump from one unproven state management library or bundler to another, in serious projects, is just not doing their due diligence.
Have you worked at different companies or contributed to different OSS projects in those 6 years? If you have, and they've all been set up exactly the same as what you mentioned, that's rare, but great. I think most people's qualms on the amount of different frontend tooling is based on the fact that almost every company or OSS maintainer takes different approaches to accomplish essentially the same thing.
Not OP. At a big tech company. As far as I can tell neither myself nor anyone I work with has touched a system developed in the past 6 years that didn't use React with with Webpack and/or Esbuild for the build system. Of those, 90% + used Redux for state management or switched to Redux after starting with a different state management system like mobx or xstate. The only exception to this the only exceptions are apps that needed something Recoil-like (e.g. Redux caused too much computational overhead). Some of them also used Nextjs for static pages.
I work full time as a software developer doing react. I have got literally no idea what almost everything you listed is.
"Broccoli"?
I have heard: grunt, gulp, webpack, metro, redux, and recoil. The rest of those could be sarcasm for all I know.
React should be considered a framework.
React absolutely imposes a data model (unidirectional workflow) to the developer thus a certain code structure. The fact that it is light weight compared to Angular doesn't change the fact that React is a front end framework. React usage completely replaces the traditional way to interact with the DOM and manage DOM events, thus abstracting it.
> React doesn’t have opinions,
React becomes very hard to use if your data model isn't organized to suit React architecture.
It doesn't have opinions about everything (like AJAX or SPA routing) but it absolutely has an opinion about how you data objects should be structured.
Literally on the start page
It's probably cause I switched 4 years ago from the typical perma-migration grind to rarely using any framework and coding JS like I code the backend. Simple service classes in pure JS, rare dependencies, simple build. I once ditched years of work by a team of 40 to rewrite "everything" in low level javascript and showed the guys that what we spent all this years writing, really, was useless: did we need that enormous angular runtime config resolver that would draw generic components reading from crafted json configuration ? Or could we just write the damn things as we mean it in... javascript directly ?
Don't use a JS framework as long as you can help it, just the simple fact you can trace the whole function chain in a few seconds, vs reverse engineering the damn VueJS, or React, or Angular (does that monster even exist anymore, we hear about it a lot less than when it was all-encompassing, 8 years ago) plumbing, is worth it.
And son, if you want some war stories from your granddad, have you heard of jQuery ? :D
> if you want some war stories from your granddad, have you heard of jQuery ? :D
Bah, whippernsapper! I cut my baby web teeth on CGI and spent the bulk of it in Struts and JSF. Remember THOSE?
However, employers dont need to be involved in choosing a framework or not. You ll notice that usually its the little bees building their resumes that bemoan non stop about migrating from react to vue or vue to react :D
I never heard a sales guy tell me: WHAT, it works fine, is cheap to maintain and has no stupid 10k levels dependency graph in npm ? I ll stop making money on this until you completely "standardize" it into a moving sand on npm. And dont forget a pipeline of 3 transpilers, you wouldnt want to write in a browser-native language, caveman.
I do use requireJS to split in nice files and import easily though I admit.
Build tools are a bigger issue, but fortunately most front end devs don’t actually need to deal with them all that often.
There are also codemods to say move from underscore to lodash and vice versa (been a while and can't find them at the moment).
ASTs [2] are pretty cool in this regard. Especially if you write your code in a manner that easier to automate against.
[1] https://github.com/mui/material-ui/blob/master/packages/mui-... [2] https://en.wikipedia.org/wiki/Abstract_syntax_tree
Multiple things exist. That’s fine and healthy? You don’t need to know absolutely everything.
Competing state libraries is to be expected but picking redux or mobx has let you use the same ones since 2017
JS itself has improved but hasn’t really ever deprecated anything, it just grows and adds terse methods to the language
Npm and yarn are among the best package managers
React hooks were the only major change you’ve touched on but even they didn’t deprecate class based react or change library semantics very significantly
Webpack 2 was in CRA in 2017
Redux and MobX have been the #1 and #2 state managements for that whole span, and clearly all the observable libs are successors of MobX after Proxy came out
Every language changes, many with breaking version changed that JS avoids
I don’t know how you’d point at package management as an issue in JS land
It’s just that every single popular community has massive amounts of clones or similar libraries, I don’t know how that qualifies as “churn” though. I maintain my 2017 apps including major version bumps with no issues today, using the same libraries and tools. The argument you’re making was fine in 2016 but is half a decade out of date.
Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps”. Webpack alone has gone through five major revisions in this time, with large breaking changes meaning all of your plugins and babel extensions needed upgrading (sometimes not readily available), rewriting the entire config, even before you get to upgrade React and dependencies. React Native has changed massively in this timeframe, I’m talking complete API refactoring and packages moving around, not simple function signature changes.
This is simply not reality for people working tech jobs.
For a glaring example, you say it’s #1, but Redux is dead in the water. I haven’t interviewed a single person in the past two years that wants to use it. The creators have been recommending “just using react.Context” for years and that has clearly had an effect.
> Sorry but I have to call bullshit on that, unless you’re taking about tiny one page “apps”
What a strange stance. It's a React/MobX collaborative model editing internal tool deployed in production to users who generate and analyze models with it. It started on Webpack 2 and React 15 and MobX 4, now it's on Webpack 5 and React 17 and MobX 6. I of course had to update some babel configurations but it was much more version bumping than configuration rebuilding. It still uses decorators and looks like complete dog-shit, and that's my point: the same tricks and patterns available then are not only there, but working identically now.
Re: native, I don't believe in React Native or any webview-based "native" replacement anyways, but it's easy to do this as my user-base is interacting with this app from their company-provided laptops anyways. I would willingly concede React Native is an environment with churn, I don't really recall RN every reaching meaningful stability
> Redux is dead in the water
https://www.npmjs.com/package/redux shows 7M downloads weekly
https://www.npmjs.com/package/react-redux shows 5M
https://www.npmjs.com/package/@reduxjs/toolkit shows 1.5M
MobX / MobX React are around 1M/700k
Your list of "flummox / redux / unstated / mobx / mobx-state-tree / xstate / apollo / apollo-link-state / swr / react-query / zustand / recoil / jotai" seems to peak at 500k with the exception of "react-query", which I don't really see as applicable to a conversation about state management. Overall, this list perfectly illustrates my point that there's new stuff but you don't need to know it, and the value props aren't convincing alive-and-well shops to drop everything and rebuild
> you say it’s #1, but Redux is dead in the water
I never personally believed in Redux, it struck me as a terrible pattern from the start, thus why I selected MobX; but I find it difficult to believe that you really think React Context scales the same way building an external state management tree does. I like React Context, but it doesn't do a very good job of hiding away complexity from the developer as the application grows. Not to mention it does no render-optimization for you.
Again, I'm not saying things don't change or that there's not alternatives, but I am saying that someone who learned fundamentals in 2017 is still able to get up-to-speed in the updated versions of the library kings of 2017 in virtually no time, and deliver standard-fare webapps. I say this because I've worked at the same place for over 5 years, I use the same tools, and my users regularly are telling me the tools my team puts in front of them are the gold standard. The churn is long gone, everything you describe would have perfect analogues in any other popular modern language / library ecosystem.
I don't, and I find the advice on this subject found around the web pretty terrible. But it's the position you'll most often see from React core team and people selling online lessons.
jQuery is still used in > 50% of websites. Popularity in numbers lags way behind developer adoption.
I've been involved in multiple new product development efforts in the last decade, and can tell you it looks a lot different from maintaining one stable product. And it's sped up by 10x if work at an agency putting out a different project every 2-3 weeks. This is where the fatigue comes from.
The kind of development you do (product / projects / marketing) makes a huge difference in your experience, how often you get to start from scratch (= latest versions of everything) vs maintaining existing codebases. I don't think that's controversial. You could use the same stack for every project, but people and teams change and want to catch onto the latest "advancements" in the field.
Yet, here I am, new apps in hooks based react, old ones not, and the same stack delivering great performance in either case - DX is only suitable in some tho
I’ve used Context only, SolidJS, Angular, whatever you like these days, I still would only build real apps with MobX. Typescript is the only real change since 2017 you need, otherwise what’s newer is not what’s better since then. That’s the point. Take care and try to not get lost in the noise, it’s very different than what came before it
lol and that's why we saw the emergence of rollup and parcel and snowpack and whatever the hell else came along since then?
But CRA is still on webpack, and CRA is still the de facto default way to make a new react app. I don’t really see the fact that alternatives exist as implying churn when the same option has been the longest living and most popular.
> I no longer think front-end suffers the instability people accuse it of.
Do you mind elaborating why you believe this is the case?
now that it is 2022, what's the new flavor that would be prescient? I don't ask to actually know, but to reiterate the problem of nothing being solid in this world.
(Now what you couple with NextJS for data access is an interesting question - this is where there's a lot of innovation. Personally, I'm going with tRPC. I would look at Edge DB, but in this application I'll need a recursive CTE and Edge can't do it.)
Edit: I do think Astro might replace NextJS for purely-static sites, or ones where the "islands of interactivity" pattern is compelling.
My guess is that since frontend web development is at the top of the stack it has an incredible amount of freedom so everything changes every minute. You don't see too many people wanting to subvert HTTP making a billion homemade alternatives
No? I constantly come across new protocols, promising improvements compared to it. Some even become relatively popular and are included in browsers by default. Just some examples are WebSockets, WebRTC and QUIC. I expect we'll see more of them in the future as specific use cases requires more specific protocols.
You could right click "inspect element" in any browser and mess around in the html or the JS console and see things happening live. This is an extremely low barrier to entry.
Low barriers to entry are good, our profession is very well compensated and developed economies could certainly use low effort ways to get people from lower compensated jobs into higher compensated jobs* but that also means that there are a lot of cooks in the kitchen.
---
* yes, tech isn't for everyone (what job is?), and when I say low barrier to entry I mean you don't really need to subject yourself to what could easily be 5-10 years of schooling in medicine or law or engineering.
"We all know the meme: by the time you’ve learned one front-end technology, another three have just been released. Also, that one you just learned? It’s deprecated."
Maybe it's because the article is 4 years old. I just don't think it's true anymore. Ok there's React and Vue and others, but that's fine. It's basically the same tech, but they have DX/cosmetic differences. It's not like we're still arguing whether or not VDOM is a good thing.
That said, the "Imagine being a junior developer" section sounds spot on still. Maybe it's because those articles that use dogmatic arguments to recommend inferior technologies are still on the internet, and they are not going anywhere.
I've seen this more than a few times over the years, and it makes me a lot more skeptical of praise for anything new. Almost always the praise is about technical aspects of a new tech/stack, and the value is almost always in the larger ecosystem. I'm fine - happy, often - with using something slightly out of date if it means there's a community of people who can help support it, answer questions, publish mods, etc. There's a balance somewhere to be found, but I've been burned too many times picking a tool, investing in it, then having much be thrown away for the 'v2' version which is often not backwards compatible (for good reasons, usually, but still problematic).
Marks of maturity of a project - acknowledging upgrade requirements, publishing upgrade guides, supporting previous versions for a publicly stated time range, etc.
All of which did happen for AngularJS. And you could still be using your AngularJS components within an Angular application today - or vice versa - thanks to the tools provided to migrate piecewise. End of life for AngularJS was only five months ago after a four year LTS period that started in 2018, given that Angular 2 was released in 2016 that's a five and a half year period where both frameworks were supported.
Libraries deciding to break everything without warning is definitely an issue that's caused me grief in the past. Moving from AngularJS was something we decided on and planned out well in advance.
I wasn't in webdev-land when the migration happened, but as someone who maintains both AngularJS and Angular2 code, they don't seem all that different.
Especially considering the later versions of ng1 tossed out all the globals (components with isolate scope by default) and moved to class-based directives. And then ng2 came along and rewrote everything into a prettier API (typescript with decorators and shit). But otherwise they both seem to have the same design when it comes to change detection, dependency injection, controllers / views, etc.
I think it's is very possible that it's the next evolution of innovation in the space. It might actually be a Backbone -> React style quantum leap in terms of tech and adoption. The thing is, that won't happen for another 10 years, if it does at all. It could very well turn out to be a niche technology for most people, with minimal real-life benefits compared to the drawbacks of moving off the mainstream.
Every space has new innovative technologies that risk upsetting the status quo. I'm not saying things are completely boring now. Just that, unlike in the mid 2010s, they are actually stable enough.
As far as other innovations Svelte has brought, Vue with the <script setup> sugar looks quite similar to Svelte, as well as compiling to a render function (just like Svelte). I’m not super familiar with the intrinsics of Vue but the VDOM is starting to feel like a thin MIR of the framework which could be swapped out in a future major release, rather then something essential to it.
I honestly think that 10 years is a very conservative prediction.
But that's honestly missing the forest for the trees - JavaScript itself went from asynchronous callback pyramid of doom, to promises and callback chaining, to async/await. The community went through multiple half-assed module approaches/specifications. Several FOTM bundlers with extreme complexity and various tradeoffs. Various build systems.
Features like hot reloading, transpiling, source mapping, shimming are table stakes for any frontend framework and involve a lot of complexity and tooling - because the entire ecosystem is built on a foundation of shit that is JS and the browsers.
So frontend frameworks are the least relevant part here - it's everything that makes them tick that's the problem.
Once people realize the soul devouring chthonic difficulty of doing good modern UI, they've already built on a shit foundation and been forced to realize the full system with a heap of ugly hacks and workarounds.
Then someone thinks "wow, this is way too complex! All I need is a simple UI." Then history repeats.
You can see this with immediate mode clean simple GUI library of the week. They all stagnate after getting all the basics working, and there's a reason for this.
A good mature modern UI is at least on par with a high-end game engine like Unity in terms of feature surface area and difficulty. In some ways it's worse because while the breadth and size of the problem domain is similar the problems you encounter in a game engine are probably a lot more fun. UI is a hell of incredibly hairy state management and a really long tail of edge cases.
My hypothesis has been for a while: UIs essentially are video games. They have animations and interactions that rival the complexity of video games. Sometimes they even have sounds too. The rendering is not quite as complex (usually!), but everything else definitely is.
I'd like to see a UI system that is built by experienced game devs, who also are good at and understand interaction design.
A game engine has a second, hidden, part of the iceberg: The production pipeline for all the 3D world/art assets.
That's actually where most of the work goes -- hundreds of artists go into a AAA game, and all the art they produce must be technically excellent along a bunch of dimensions that have nothing to do with what it looks like (and in fact, generally make it harder to achieve the look you want.)
Game engines that can wire physics simulation to 3D rendering to window abstractions are easy-ish to make, similar to how web UI frameworks are easy-ish to make.
All the production pipeline stuff is where the real meat is, similar to how in WebUI and, package management and transpiling and bundling and deploying is a hard problem. I think the game side has it even harder than the web side, though, although they usually have the benefit of only needing to work on a defined set of platforms, rather than in "the" browser.
Developers, managers, designers, executives, the whole process chain underestimates the complexity of building a stable and maintainable UI.
Everyone feels in their gut how complex building out a data processing pipeline or a scalable backend should be, but even people who should know better can't help but think of the UI as the "easiest" part.
In my experience, the only solution is forced minimalism. A sort of "Dogme 95" for UX. Force your UX to be a haiku, not an open-ended novel. This means pushing back hard on unnecessary complexity and focusing like a laser on what really matters.
In other words, the problems might be technical, but the solution are likely political.
This gives me flashbacks to writing a Java applet (supporting the MS JVM!) in which my boss has decided AWT (no Swing lol) was verboten and implemented his own widgets. Which was great up until I had to implement dropdowns, because then you need a concept of z-ordering, which meant refactoring almost everything in order to include. And this pattern repeated several times for "simple" new features I was asked to add.
Writing a primitive windowing system with nested menus in GFA Basic and getting lost in a rabbit-hole browsing the Turbo Pascal object hierarchy as a teenager was a good way to teach me to not try and write my own UI library if I wanted to get anything else done :)
As shitty as Android support matrix can be - it doesn't compare to IE6 web days (at least in terms of UI development, stuff like OS services is entirely next level - but you can't even start doing that in JS so it's not really a fair comparison) - and we're still paying for the technical decisions made in that era (how many people are polyfiling all the way back to stone age and including hundreds of KB of useless shit ?).
But of course JS needs neither a build system (runs from source files) nor a package manager (runs from URLs) and recently even plugged the "no modules" hole.
If you're linking jquery from your favorite CDN and writing your code inside of <script> tags you're not dealing with the issues this article is describing.
I haven’t heard about this. Do you have a link so I can read more?
Looks like the field is maturing.
Either that or we are on a fake calm before we see a lot of articles about people migrating into wasm in "whatever language has support for it right now" (AFAIK, currently wasm goes with rust).
Managing backend requests is too complicated!(react-query)
You *need* gql don't you?
Don't forget forms. Super hard to do right. react-final form, react form hook, etc
We need a monorepo framework! Nx, turbo, rush, pnpm (too low level), Lerna (too old and unmaintained)
What about bundlers huh? Vite, esbuild, rollup, webpack
I still see plenty of opportunity for teams to ignore persistent issues and just diagnose a new framework without analyzing their current woes. Silver bullets for everyone!
That's very different to say the evolution from JQuery to Backbone to AngularJS to React where you ended up being on an increasingly unsupported platform if you didn't upgrade.
I hope front end development will be more stable in future, but the last two years where full of pretty major changes.
Having only read the docs, Vue redeemed itself with version 3.
There’s the options API we know and love from v1 and the new and intuitive composition API. The docs make it easy to decide and not to mix them up. And no useEffect fuckery.
Lately using remix or nextjs. Not that much has had to change in that time, it definitely feels more stable in the past 5 years or so.
Every new library is using components, just with their own preferred syntax.
Specifically, I know that if we want to bring in some widgets that were created this year, we have a massive upgrade task ahead of us. :(
Those aren't random progressions. On the contrary, they are front-end devs responding to needs of the UX moreso than the UI. There have been major efforts to make reactivity match what the user is trying to do, but we're still in unstable-land because we're building the bridge while we cross (I hate that analogy but it is true).
Just my $0.01.
The frontend "ecosystem" libraries discussed in the article are also subject to a fashion hype cycle, independently of UI/UX design trends. A lot of them don't actually make anything easier, or don't make rapid design iteration easier at least.
I feel like when you have an org of designers they will justify in wanting to redesign everything because why else do you need them? The same can be said for some POs and devs as well IMO.
Initially, users had low bandwidth connections, and web pages were mostly static with links.
Then came JavaScript interactivity and AJAX.
As users bandwidth grew, we started having heavier frameworks and SPAs.
I believe there is another revolution that is happening now because of decreased latency. Recently with protocols such as HTTP2, web sockets, and edge computing, round trip latency is greatly decreased. This is resulting in UI where more of the logic lives on the server and has led to such libraries as htmx (client) and Turbo.
It will be interesting to see where this settles out.
Why Is Front-End Development So Unstable? - https://news.ycombinator.com/item?id=17190992 - May 2018 (354 comments)
Why Is Front-End Development So Unstable? A Perspective - https://news.ycombinator.com/item?id=17182748 - May 2018 (5 comments)
Developers constantly find new ways to implement front end apps, and they are not afraid to break backwards compatibility. This may be bad if you have an old monolith to maintain, but overall it's a good thing IMO.
Also, this is not limited to libraries. Have you looked at what speed Chrome devs are implementing new APIs? It's insane. And great.
It's not great. It is bad, really. It means no one that hasn't dozen millions of dollars can implement or even just maintain a viable browser that can keep up. And since we expect browsers to be free, that means… "complicated" business models cough mostly¹ relying on ads and tracking cough to maintain the Web.
I which it wasn't this way really. There was a time when it was possible for a few people to implement a quite good browser engine in their free time. KHTML. So good, in fact, that it was chosen as the basis of WebKit (and therefore Blink). This does not seem possible anymore.
1. There's Apple maintaining a browser engine without relying on ads, but their business model is also questionable.
Having started to work more in dev ops lately, I no longer think this problem is unique to FE. The number of tools used in the dev ops scene makes my head spin. There are hundreds of products and services one can employ when building out infrastructure that didn’t exist 5 years ago. Everything being built on top of kubernetes alone will send you into decision fatigue and months of research. I see no meaningful difference. Why’s is that? Do we just feel like the gravity of infra is more deserving of the complexity?
"Productive" ecosystems (e.g. Rails, Elixir) usually have one central framework that provides the standard basics. Libraries, tools and other extensions are built on top of the framework to enhance the feature set. Everything typically works well together.
JavaScript has multiple frameworks to implement components, multiple tools to implement bundling, multiple tools to implement modular/extensible stylesheets, multiple package managers with somewhat different features (e.g. when it comes to monorepo support), and multiple libraries to implement basic standard functions.
Many of these are not compatible with each other. Compatibility is a combinatorial explosion problem that cannot be solved without standardization. Without it, you need to have m*n modules to have m things talk to n other things. Extensions to the ecosystem therefore typically have partial compatibility with all the tools, which further widens the breadth of the problem.
There's been very little effort in the community to standardize interfaces and protocols: but for the few things where it has been successful (e.g. see package.json) we've seen much nicer and smoother interop/tool interchangeability. We need more of this, especially when it comes to open-ended "plugin" style stuff (e.g. bundler plugins/extensions, component interfaces, monorepo structures)
Libs like React and Vue are stable enough but when you throw in a lot of other dependencies it is always the question how experienced the creators were. And when unstable libs become popular bugs and security issues are exposed, pull requests are created and before you know it a next version is launched that is not backwards compatible.
Maybe that’s my inner geezer talking or there’s some nostalgic distortion at work but building a website and a small product used to be comparatively easy. Today with the elevated expectations on functionality and the tons of tooling it quickly becomes an almost insurmountable task. Everything appears to be optimized for the large scale, where all the tooling and workflows probably help. There are just so many moving parts, all the time.
I’d like to build performant web sites and products with as little JS as possible, make a good living doing it and spend time refining the foundation. But those jobs are gone. It’s all JavaScript and full-stack development positions now.
Some things have changed, but not that much.
- Typescript was just getting popular when I left, now it's basically a standard, but 1) after having been in javaland for a while, adding typing to JS makes a lot of sense to me and 2) though it's a change, feels like a change toward more stability, not less?
- React was the big framework when I left, still is the dominant framework.
- There's still a lot of option -- eg vue, etc. nextjs wasn't a thing I knew about that I am starting to learn now. Class syntax felt unecessary to me but seems to be de facto these days. But... these all feel relatively small?
I started in FE back in the days of IE 6. jQuery was a godsend when it arrived, underscore was super helpful. I'll grant the shift from "we use JS to add some interaction, form validation, and sometimes interact with Flash" to "we use JS to write actual programs delivered via your browser" was a huge shift, but since we've made that shift it seems most of the "instability" is more around FE devs adopting practices already common in the rest of the stack.
I think maybe that's where this sense of instability comes from -- a focus on the wide array of possible _implementations_ -- but I feel the really disruptive shift from "interactive decoration" to "web applications" was the really big one, and that's a while back now. And even with the dizzying array of possible implementations, there's obvious market leaders -- you're not going to go wrong by learning React, any more than you're going to go wrong by learning Spring Boot. Always good to explore and get familiar with other libraries and frameworks, but if one feel overwhelmed by options, there's some clear well trodden paths that aren't changing _that_ fast.
One thing I will say is that I do think FE is _harder_ than BE, because the scope is wider. You need to grasp all the aspects of good programming, but _also_ get a decent grounding in design and UX, which are their own disciplines. A backend API doesn't have to think about things like screen readers or color contrast or all the weird ways users will figure out to misunderstand how to interact with your GUI widgets. A UI for humans is inherently harder than a UI for machines. But that's not the same thing as saying that the FE is unstable.
I know a few React engineers in my company who can make components and be productive - but they don't know JavaScript and they get stuck when something is slightly different from what they're expecting.
Similarly I'm mentoring a few engineers who started with react and are trying to learn backend and other languages.
Being the field where all the least developer figures start means you'll have tons of people, tons of visibility, tons of cargo culting and tons of crap being built just to make you look cooler. I'm guilty of this as well, I have my frontend framework on GitHub and it's quite useless - even if it's a nice idea.
Of course nobody bothers to maintain stuff and everything is trying to make money on their junior devs fanboys.
The web browser as a platform just sucks to work with, it always has, just now the issues are more nuanced than just dealing with quirks or ms jscipt weirdness.
The first time I had a bout with Kendo was some odd ten years ago, and then I was sure it was simply me not understanding the framework. After all, every component library has its own kinks and it takes a while to get up to speed. After seeing them again and again many times over the years, I've changed my opinion. In my eyes, Kendo is what I like to call an MBA trap. It ticks all the boxes that an MBA manager going by a feature checklist is looking for, but under the hood it's garbage software. I'm glad you've had a good experience, at the same time I don't think I will ever stop recommending everyone to stay away from Kendo.
I think the same happens in front-end dev. It happens here because it's obviously exposed to users and we want to a) follow fashions and b) wow our users. As soon as tools get more powerful and we start to master them we'll start to push the boundaries and everything becomes a pain again and several people will write frameworks or tools to make it easier.
Well, isn't it the case?
One more article confusing web programming with the whole software development!
Front-end development is unstable only for those applications where the nicest, latest GUI is the only value the developer takes to the table. Learn the business, have your application solve an actual business problem, offer a well-thought and on-spot ergonomic interface, and the users will love the features, and the GUI will not look oldish to them after two years.
From my perspective—started front end, gradually went full stack, spent several years fully back end, dove back in a couple years ago—quite a lot of the APIs introduced in the period I was fully back end (and since) are excellent and vastly improve both development experience and the ability to deliver a better user experience.
I’m not saying your take is wrong necessarily, I just don’t immediately relate to it and I’m curious what specifically you find objectionable.
I'd like to see the Web Components spec revisited: it has a) no API for passing non-string attributes to other web components, b) no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them.
Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
First, I agree both of these limitations make the spec less directly useful than a framework, and more likely to be APIs targeted by a framework (however formal or bespoke). That said, that’s pretty much the guiding design philosophy behind nearly all DOM APIs, and it doesn’t seem to me that makes anything worse, just incomplete. I suspect that richer APIs would make things worse. People would still use frameworks, but those frameworks would have to use much more opinionated and much less flexible APIs at a higher level of abstraction. All of that said,
> no API for passing non-string attributes to other web components
This is really a limit of HTML, and not new. But there’s plenty of precedent for raw string attributes to have a more meaningful representation in the DOM state. An area of the spec that seems really well suited to accommodate this is `part`[1]. Like `classList`, it’s a `DOMTokenList`, and has a corresponding CSS selector. It’s a string attribute, but it’s also structured data as a property. I have a long list of things I’m confident will benefit from this.
> no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them.
This really is a footgun, but I’m not sure what the appropriate alternative is. I don’t think any spec could accommodate the fact that people choose different declarative implementations for very different use cases, without essentially defining high level interfaces that expect to be overridden. Even then, those interfaces would almost certainly be ill-suited to some specialization or another. If your goal was purely creation, I’d agree that there should be a declarative API. But for updates? I can’t imagine a design which wouldn't be worse.
> Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
I don’t think the goal of any of these APIs should be to replace frameworks. At that point you’re just using a framework forever. It’s an enormous credit to the design behind all of these APIs and their overlapping specs that they continue to produce useful lower-level interfaces without overly steering the ship.
1: https://developer.mozilla.org/en-US/docs/Web/API/Element/par...
Be hold there are some choices to make here and there, but if you go with a vanilla setting with popular choices (like Webpack for build), things won't go wrong. Not everything needs to be shiny and edgy.
From that angle, the frontend space doesn't seem to be that different from wrapping around pytorch and offer yet another Trainer API with some callback shenanigans and claims to invent an AI framework.
> You miss the replies pointing out some critical inadequacies in X.js, because Medium deliberately suppresses them, and move on to finding a _Y_.
Maybe we need a new HTTP method "SCHEMA" that allows the app team to get the schema directly from the API and stop sharing postman links around in chats.
reagent[1], a react wrapper, has had a stable and tiny api for a decade.
easy, fun, and effective sdlc[2] on mature technology is easier now than ever.
there are no more excuses.
Naturally this attracts developers from all backgrounds to target this platform for their projects. These various influences puts pressure on the platform to morph to their preferences and with the platform still being young; that pressure (and profitability) means it tries to appeal to everyone, creating issues.
- Privacy
Privacy on the web is a challenge primarily because of government legislation. With the exception of the deprecated third party tracking mechanisms, the issues faced on the browser are no different to those faced by native applications - it's just that the scale of the web is much larger.
Any app, desktop application or website can opt to send user data to a third party. Cross-site cookies allow for customer tracking, but they are being phased out.
Service worker has recently started being used by advertisers for tracking. Generally though, advertiser networks can always operate in silos and request from their partners that they send customer data in exchange for compensation.
As a developer you may inadvertently subject your customers to tracking, for this I would love to see greater script sandboxing capabilities. Right now we have CSP and need to iframe anything we don't want to have access to the parent document - it would be amazing if we could sandbox _scripts_ directly, allowing us to grant no permissions by default and add them.
<script src="https://..." sandbox="fetch; dom" />
- Utility
The web platform has had incredible innovation and is going in a controversial direction that I personally love. While simple documents on the web are great, the platform is increasingly somewhere you can go to interact with rich experiences that operate on every platform.
Some criticize this as overreach of the traditional web, but in reality - Linux can now use MS Word and Photoshop natively on x86, x86_64, ARM, RISC5. Tools we use daily like APMs (DataDog, NewRelic), Google Maps, Email are all available on all platforms without requiring a native client. This is good because no one is going to make Linux clients for these applications.
Electron demonstrates that people want to use HTML/CSS as a UI toolkit (rather than platform native UI kits like QT, GKT, SwitftUI, WinForms, WPF, WinUI, Xamarin, Flutter, etc) and demand greater OS access than installable web applications can offer (like IDEs).
Web assembly demonstrates that people want to update this simple UI model using the language they like the best.
Expanding the Web Sandbox to offer lower level access to things like the permanent storage, filesystem access and hardware through user prompts would eliminate the need for Electron and allow for optimisations in a single browser to operate across these installable applications. The inclusion of Web Assembly would allow for more processor and memory efficient applications to be written - removing the stigma of "those bloated Electron apps"
Perhaps marking your web application as a "wasm" application would allow browsers to trim some JavaScript specific runtime logic allow for smaller memory footprints.
- JavaScript, Testability and Performance
There's a lot of investment in JavaScript tooling and a lot of impressionable developers out there are implementing software that isn't testable or well architected. A lot of these tools are used in improper contexts or, in some cases, are plainly bad tools.
By and large, JavaScript is a great language - or more specifically, a great compile target. A lot of the issues with JavaScript can be resolved by applying a pre-processor like TypeScript to it.
The ecosystem is a point of critique. Being as open as it is, it's unopinionated, lacking a standard library or tools and engineers must stitch together their projects. By comparison - Rust, Go, Kotlin, Swift all offer rich test tooling and strong standard libraries.
As a language itself, the language features of JavaScript have become an amalgamation of various developer preferences. Being that it's the only language that can be executed in the browser - it is under a lot of pressure to morph into every other language used by web developers.
If Web Assembly ends up replacing JavaScript as a compile target, the web would become a significantly nicer place to develop for as you can pick your language ecosystem of preference.
Some languages are better suited to testing, have better tooling or dependency management.
Some languages have access to better multi threading APIs and some languages have more efficient runtime performance. These would bring the development and user experiences on the web as comparable to native applications in performance.
- Rant on WASM
That said, WASM has been the biggest tease for me as they have over promised and under delivered. 5 years ago they were talking about it as a replacement for JavaScript as a compile target for languages like TypeScript, Go, Rust. Smaller binaries, faster parsing, better runtime performance and multi-threading support. Here we are today and I still can't make a div from my WASM-compiled C project.
Expectations of users are very high and always shifting. Browsers/consumer OSes are constantly moving targets. Mistakes and bugs, even small ones, stand out in a glaring way, so there’s low forgiveness. There are more code paths and they’re harder to test.
All that means that unless you want to miss your deadline by a year or leave a bad impression on users, you will need a lot of libraries!
Backend/systems specialists always underestimate how hard UI programming is. Then they try their hand at frontend and quickly run into a wall. They find they either need to build something clunky that users aren’t impressed by or else spend a lot of time learning new tools and paradigms (and yes, installing lots of dependencies /shiver). This is a blow to the ego, so it’s better to criticize the language, the culture, the “churn”... anything to avoid admitting the pixel pushers are solving seriously tough problems too :)
That's not how I view it, as a SRE/BE-SWE who has done substantial visual/FE work. From my perspective, the majority of problems in FE are due to extremely poor libraries and standards, bolstered by a community where copying and pasting large chunks of unknown code is acceptable. Yes, there are "seriously tough problems" with trying to develop in that world, but they are of a different world than most BE problems, from my experience. So they feel comparably difficult, but for very different reasons.
Every JS frontend dev I met was speedrunning trying to prove himself by "inventing something new" which in fact was already a state of art.
The amount of rehashing and reinventing the wheel with new catchy names in the field is staggering.
TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.
This is true at every layer of software development.
> TBH, if the field wants to improve -> its time to ditch JavaScript and force Browsers to move to something that makes more sense.
I don’t think I could disagree more. JS is a tool, swapping it out doesn’t remove the unique problems of front end development.
Let’s say we switched to python for the FE. The team wants to use numpy for some of its features. Bam, 30 mb being sent over the wire for one library. What do you do? You decide that’s unacceptable and start extracting the functions from the library you are using. You realize that these functions are useful enough on their own and publish them separately on pypi. You describe the library as fast and only 1kb.
Then someone else comes along and decides this is a tedious task to break up all these libraries and publish small functions as packages. They figure out a smart way to tree shake the library so only the code used gets sent over the wire. Do you see where I’m headed here? In 5 years the python ecosystem for FE development will look shockingly like JS of today.
Your solution does not resonate with me because it does not address the core problems of FE development. The tool isn’t the issue, it’s what the tool is trying to solve for that is the problem.
It’s more fun to write code and make stuff up than to find and evaluate libraries (especially when said libraries are written by self-taught devs), so people tend to reinvent rather than research.
Javascript was never the problem. Today there are bazillions of solutions using another language for the people who don't want to hear about Javascript. The problem is all the DOM and WebAPI available to the developer. You can potentially interact with all that in C++ if you wish, but you'll always be limited by the exact API as Javascript in the browser, by design.
Fundamentally there is a mismatch between how the DOM works and how most people develop complex interactive UI, switching to another language doesn't solve that problem.
JS is just not good enough for what we want it to do.
Someone sooner or later has to make a decision to move further.
Additionally, I'd argue FE draws more junior people in general, because of the theoretical rapid feedback loop, and the fact that you can "make something that looks cool" with relatively little effort (relative to a BE engineer). These junior people add confusion to the chaos of the community because they don't know what they don't know, so they're cocksure about their opinions. And as long as they've "made something that looks cool", even if the architecture behind it is hot garbage, it buys them cred in the community.
Somewhat related, I've been using Flutter for a recent FE project and I'm in love with it. It's more for webs/mobile applications than websites, but the ergonomics of it feel like a coherent vision. The people maintaining it (Googlers) are excellent, and the Dart library community seems to know what they're doing. Furthermore, the FE design choices are based on Material Design[0], which is backed by (some informal) research by UI and UX professionals, so you don't have to sweat usability quite as much as you would starting from scratch.
I'm the opposite of everything about this post. A very experienced dev (>20 years professional experience) that has moved primarily to the front end recently in my career (gradually over 4 years). I won't touch flutter simply because the sole vendor and essential dependency is Google.
Fads are present in every corner of development. As is "not invented here" or the general draw to green field.
I would hate to invest precious years into tech and apps to have the rug pulled out from under me because flutter entered the Google graveyard.
They do have competent engineers, and if they get sufficient community buy-in, I'll be much more open to it.
Plus having Dart (which feels a bit like Java, but less verbose) as the foundation language raises the bar in terms of library code quality (compared to Javascript at least)
A lot of open source projects die when their corporate investor closes shop. The community is often just dependants who want to use the tech but don't have the ability to keep it running. And it is usually not big enough to come up with the funding for a foundation to run maintenance and development.
Flutter is very ambitious as a project. I have more direct experience with other similar projects like react native, which really struggles despite the investments.