I've been building websites for over twenty years now. I started freelancing in the very early 2000s as a teenager, building websites using XHTML, CSS and PHP. That's a long time. (Not that it's a contest; know many people who predate my experience and many who are far more accomplished given less time). It's a long time doing a thing. It's a lot of time honing a craft. Maybe I'll be doing it another 20 years, maybe more, hopefully less, but it's probably reasonable to say I'm half way through my career at this point. I haven't touched a PHP file since about 2012. Last week I was interviewing a candidate who chose to use PHP for their coding assessment, it was unrecognisable from the PHP I had written in the 2000s. That's probably a good thing but it got me thinking about the technologies I've learned and forgotten; what created foundations for my career vs those that came and went without much impact. It also makes me think about how I can spend my time making the most of the rest of my career.
2011 to 2017 was my "consultancy" period, working to instill more maturity in teams around their front-end practices such as introducing them to Unit Testing. During this time I became a core maintainer of Chai, one of the most popular JavaScript assertion libraries in the ecosystem. Despite new tools arriving such as Jest, @web/test-runner, and the built-ins provided by Deno and Node I still find the core puzzle pieces are the same. Maintaining Chai gave me a deep understanding of JavaScript internals, but also in how to test code and what to look out for. It taught me about failure modes, boundaries, and invariants. The time spent was valuable to my career, improving it as a whole. The experience was transferable and proliferated through to other projects.
My consultancy work wasn't just writing tests, it was everything front-end; Backbone, Angular, Ember and more toward the end of my tenure as a consultant, React. I aided in launching a few big projects using React, including leading the initial work adopting React at the Economist. However in 2017 I grew tired of consultancy work and took the opportunity to join GitHub, and from 2017 until about 2023 I hadn't really looked at much React code, instead writing a lot of Ruby and "vanilla" JavaScript. More recently, however, I've found myself back to working on React code. During the 6 or 7 years I was not programming in React, it has changed so much that I barely recognise it from the applications I was building less than a decade prior. Thanks to the advent of "hooks", the React of 2024 is nothing like the React of even 2018. When I think back on the lessons I learned from building those applications in old React, I can't think of much in the way of redeeming transferable knowledge that I can really take from it.
So now I'm left with a dilemma. Do I spend the time to "learn" this new model of React? I have colleagues which are extremely well versed in the rules of hooks but it seems such a uniquely "React" thing. No other framework or tool seems to adopt these patterns unless they're expressly trying to emulate React, and so should I spend time learning this non transferable skill? It doesn't seem like a valuable use of my time.
React proponents might claim that new React teaches you "functional" paradigms. I've dabbled in some functional languages and I can't see any similarity between paradigms like monads and React. React is not FP. Executing a React component that uses hooks results in a Invalid hook call error, it needs to be embedded into the framework runtime to work; it's global state in a functional trench coat. I don't have the time left in my career to waste learning pseudo-functional paradigms when I could instead pick up actual functional languages like Haskell or Elixir.
React proponents might claim that React will teach you modern UI, but from what I've seen it barely copes with modern UI. autofocus is broken, custom elements don't work in all but the experimental version, using any "modern" features like <dialog> or popovers requires useEffect, and the synthetic event system teaches you so little about how DOM actually works. This isn't modern UI, it's UI from 2013 at its inception. I don't have the time left in my career to pick up UI paradigms that haven't evolved much beyond from when Barack Obama was in office.
When I mentor early career developers and they ask me what they should learn, I can't say React, they don't have time. I mean sure, pick up enough React to land you the inevitable job doing it, but it's not going to level up your career. Anyone with $5,000-$10,000 can make their way through a bootcamp and scrape their way through an interview, but it's a competitive market and it's usually quite evident when your interviewing a bootcamp candidate. Stand out by picking up some more fundamentals:
-
Learn JavaScript without TypeScript or React, or pick up another dynamic language like Ruby or Python. Try to use as few dependencies as possible. That can all come later, but can complicate setup and hamper progress for newbies. Try building a server using Node & just add
express, or hack on a Rails app, or a front-end using Web Components or just sling together some vanilla JS, hell use jQuery if you want. There's a plethora of information out there to build apps like this and you won't get stuck on bundlers or the land of analysis-paralysis on picking the "best" state management library. Avoiding frameworks and learning the generic parts will give you the transferable skills that apply to any sub-genres like the various UI frameworks around. -
Learn a strongly typed systems language, but try to pick up a more modern one. Many CS classes still teach Java or C++ but they're a bit of a drag to learn, and less marketable than some of the modern alternatives. Golang, Zig or Rust would be my recommendations. Try to build a command line app in them. Strongly typed languages will better equip you to learn a language with a more, ahem, pragmatic type system such as TypeScript. Learning a systems language will teach you a lot about memory management and give you a better sense of how dynamic languages work under the hood.
-
Read specs! Actually understanding a specification like HTTP 1.1, HTML, CSS, databases, WiFi specs, can set you leagues apart from your colleagues and there's usually nuggets of information you can take from them. The MQTT spec is a reasonably short yet wonderfully crafted spec which is a joy to read and a great example of how to make an efficient protocol. If you find specs a little too dry, try reading HIGs instead - the Apple HIG or Gnome HIG are great guidelines which can teach you a lot about how humans interact with machines; the ARIA APG or WCAG Guidelines will teach you how to build accessible user interfaces and still have an incredibly long runway in their value. RTFM, it works.
-
Contribute to open source. There are fantastic projects with great avenues for mentorship and learning. There is no greater transferable skill than the skill of shipping to customers and Open Source Software is a great way to practice that skill. Open Source is also great for networking.
In my humble opinion, doing some (or all) of those will put you in a much better position than spending that time less effectively. You don't have time to learn React (by all means learn enough to get that bag), so learn something more useful instead.