Redefining Developer Experience

Cole Peters (@colepeters@mastodon.online) on begin.com:

For years now, the most popular JS frameworks have carried out intense marketing initiatives based on the premise of improving DX

The whole thing goes, however, as in other ecosystems that developers categorically exclude other frameworks as "bad" and some now and then only see the next nail they can hammer.

My toolchain consisted of HTML (version 4), CSS (version 2), and a sprinkling of jQuery on those rare occasions when I could understand how to use it.

Those were the days. I still fondly remember one of my first jobs, where we uploaded our .jars (built by Jenkins, after all) to the production server via FTP. Don't worry, I'm not suggesting that now as the better alternative to a CI/CD pipeline. However, I did learn a few things about Java and application servers there that still help me today.

The same goes for jQuery and co: HTML and CSS I learned from books, and jQuery was at that time™ finally a way to use JavaScript sensibly. AJAX was a phenomenon... but back to the actual topic.

I’d learned to wield several major versions of React with substantial expertise (starting with class components, then function components, then hooks…), along with the wider React ecosystem. React Router, Redux, Redux Select, Redux Saga, the Context API, XState, React Query, Styled Components, Styled System, Radix, React Spring, Framer Motion, React DND, DNDKit, Jest, Enzyme, React Testing Library, NextJS, and others were all under my belt, and in most cases my experience in using them tended toward the skilled end of the spectrum. And this was just to render and test UI!

Deeper under the hood, I was working with NPM, Babel and Webpack to manage packages and builds (having previously worked with tools like Bower, Grunt, and Gulp), and deployment providers like Heroku and Vercel. Of course, all of this was managed through GitHub version control, with some of the pipeline instrumented with GitHub Packages and Actions, and with everything running through ESLint and Prettier to catch formatting inconsistencies, opportunities for optimization, and potential bugs. Underlying all of this were my ongoing efforts to stay on top of developments in HTML, CSS, and JS/ES-What-Year-Is-This, including aspects like accessibility and performance, but also with respect to concepts like functional programming and frontend architecture in general.

Web development is often too more complicated than necessary. Look at the amount of libraries and frameworks you need today, regardless of ecosystem, to build a simple single page application. The trend to move this to the server now (looking at you, Next, Nuxt, Remix and friends) may make the whole thing incredibly fast but may inflate it unnecessarily. There is an alternative, which we should perhaps seriously consider as an option more often.

It’s true that many modern JavaScript frameworks began as attempts to fill in some gaps in web standards, but in 2023, many of those gaps have been filled by the web standards themselves. HTML now has templates and custom elements, CSS has an incredible range of APIs for animation and complex, dynamic, and responsive layouts, and JavaScript itself has evolved to become a powerful programming language without the need for supersets or frameworks.

Browsers, meanwhile, have become better at converging on implementations (for the most part, anyway… WebKit has some catching up to do) and at offering built in optimizations like back/forward caching, and they automatically update so that end users have access to the best new features. Cloud based deployment solutions and general increases in global internet speeds have done much to mitigate slow response times (providing you’re not shipping megabytes of JavaScript over the wire), allowing multi-page applications to become just as fast (if not faster overall) than single page applications.