I recently became a frontend developer. Again. The last time I was, was back in 2014. And it's pretty much like riding a bike: if you haven't done it in 5 years, you're going to feel pretty damn wobbly. Especially if the bikes started using create-react-app and Sagas in the meantime.
So, with all the wisdom of a child who just fell of his bike, I'm going to try to share a few insights on the state of ~biking~ frontend in 2019!
5 min read
By Jøran Vagnby Lillesand
December 5, 2019
In 2014 I wrote my first big application using Backbone. Not particularly early to the party, I know, but it was definitely a step up from my former favourite frontend framework, jQuery Spaghetti 2.0. TypeScript was out already back then, but for some reason that was mostly for the .Net developers. Us Java guys were too cool. So instead we just passed around objects called
opts, and console logged them to figure out what the heck was going on. And then we forgot to remove the console logging, and the application crashed in Internet Explorer in production.
"Oh great, even this guy caught the leftpad drama," you're probably thinking, and you're right. I did. Back in the day, the npm micro package ecosystem was all the rage. And why wouldn't it be? Everyone was super tired of Java, Spring and the whole one dependency to rule them all approach. So we did the only reasonable thing, and over-compensated by creating a million small packages.
Soo… leftpad happened. But that's obviously just one small symptom. How many packages do you currently have installed on your local development machine? How many different people authored those? How many of those authors are NSA or FSB? Oh well, best not to think too much about that.
For those of you too young (or too old and senile) to remember, there was a beautiful period of 5-6 years when we played Frontend Framework of the Year, where we would choose a new frontend framework to get excited about every year. And then run along and rewrite everything from last year to that.
Just kidding. Kinda.
I'm happy to see that React has gained some kind of permanent foothold. That kind of stability is good for tooling, good for developers, and certainly good for whoever is footing the bill. It also leads to sensible innovation, such as React Native. Which I've recently learned that also is available for web. React Native for React. What a time to be alive!
So although there are interesting alternatives like Elm around, it looks like React is going to be worth your investment for at least a few years to come.
I guess that just comes with maturity. Before a language has any use in enterprise applications (which I'm starting to figure out means 'real world' applications), the last thing anyone wants to deal with is dependency management, backwards compatibility and other boring enterprise stuff. But that quickly passes once your 20 million dollar business starts to fall apart because someone upgraded Babel.
With the maturity of the toolchain, developer tooling has improved. React and especially Redux provides some great debugging functionality, but overall, I'm a bit disappointed that the state of things aren't better than they are. Source maps are good, but the fact that the standard debuggers can't evaluate variables properly with source maps is a bit of a bummer.
There might be things I should know here that I don't, but I was hoping that we'd be well past the point where
console.log and attaching things to global state are reasonable approaches to debugging.
All in all, things are not bad in the world of frontend. The community is thriving, and innovation is both rapid and reasonably well directed. So, I guess I could reasonably say that things used to be worse. The coffee was bitter, and the developers were too. These days the coffee is single lot, the function scope is predictable, and the developers are hopefully slightly less bitter than they used to be.
So, if you yourself is part of the frontend community, enjoy it! Frontend as an area of expertise has undergone huge changes the last few years, and I dare say most are for the much better.