“Yet Another JS Framework” isn’t so bad after all

Summary: The web is evolving. Fast. The default reaction is framework fatigue: “Another JS framework to learn? Ugh!” But there’s a hidden upside to the rapid evolution in front-end web dev, and it benefits your happiness, your mind, and your wallet.

We’re seeing rapid evolution in the web development space. Not only is JavaScript and HTML evolving for today’s needs, but numerous frameworks are popping up to leverage the new bits and help you build better web apps.

This fast-paced evolution can be difficult for web developers. There’s a never-ending stream of new things to learn, and that gets overwhelming.

My experience In the last 2 years testifies to this: I’ve built web apps with plain old jQuery, then Knockout, then Durandal, then Angular. And with today’s announcement, I’ll probably write my next one with Aurelia. That’s 5 different libraries/frameworks in just 2 years! Web devleopment is a beautiful soup.

But this does lead to developer framework fatigue. On Hacker News today, for instance,

Having to learn new stuff all the time and trying to keep up is fatiguing and can be overwhelming.

But there’s another side of this to consider. Rapid evolution leads to better ideas, keeps your mind fresh and your job more interesting. It gives developers an opportunity to stand out with new skills and make more money.

Better ideas rise to the top

Make no mistake: web development has improved by leaps and bounds in the last decade. Rapid library and framework evolution are to thank.

(If a crotchety developer pining away about “the good ol’ days” tells you otherwise, he’s not telling the truth. Those old days were not good. They were littered with browser incompatibilities, unmaintainable apps, no concern for architecture or testing. It was truly the wild west of coding, and it sucked.)

When I started web development, front-end JavaScript meant adding a single giant JavaScript file where you’d do your DOM manipulation and event handlers. The DOM manipulation was usually using browser-specific APIs, and the handlers were hooked up in the global namespace.

This was like the Visual Basic era: put everything into a single file, maybe even a single giant function! We didn’t care about maintainability, testing, separation of concerns.

It was a simpler time, yes, but it was also the time when web development and JavaScript received ugly reputations that persisted until only recently.

Back in the bad ol’ days, web apps themselves generally sucked, too, as a reflection of the code underneath. Great web apps like Gmail, DropBox, Evernote, Pandora…these didn’t exist because building web apps was hard. (Pandora existed…but as a plugin-based Flash app back then!)

Since then, things have vastly improved. How?

Instead of a spaghetti mess of $(“#someVal”).parent().adjacent(“<div>”+ someVar + “</div>”), we’re doing nice and clean logic on variables. Through the magic of data-binding, those variables will be displayed in the UI automatically. The code is modular: simple HTML pages data-bind to controllers containing logic. Controllers wire up to services to load data from the server. The code is arranged in modules with single responsibility, well-defined application architecture, easy to test, easy to modify and extend. This results in better web apps with fewer bugs.

Intellectually stimulating

I actually like the fact that I must keep learning.

It’s true; web development can be overwhelming with all the new technologies and JavaScript frameworks released almost monthly. (If you’re overwhelmed, remember: you don’t have to learn them all.)

But at the same time, I like learning. It keeps my mind fresh. It keeps my job interesting. I like building things, and learning new and better ways to build things is intellectually stimulating.

Consider the alternative. In a space with slow evolution, such as mainframes, there’d be practically no moving technology forward; we’d be doing the same thing for decades, over and over again. See something that sucks about your dev stack? Too bad, you can’t change it.

As a developer and entrepreneur, I want to be doing new things, interesting things, moving the software craft forward. It is a little ego-stoking to think that moving software forward actually moves technology and civilization forward, even if in a small way.

I don’t believe there’s a world in which my skills go stagnant and I still enjoy building technology. It would get old, I would grow tired of my work, become demotivated. My job would become only a means to pay the bills.

I don’t want that career. I like a career that remains fresh, regularly infused with new knowledge. That new knowledge can then be used outside of the professional realm to build your own projects of value to you, personally. (I’ve done this with Chavah, MessianicChords, and EtzMitzvot.)

“Look ma, I’m worth a lot of money”

Knowledge is power. The more I consume, the more powerful (and valuable) I become. Therefore, I am actually grateful to be in a career that requires knowledge growth.

My last 2 gigs as an independent consultant were aided by my knowledge of a single JavaScript framework. And my hack-at-night job gives me money because I know another JavaScript framework. And my startup exists because of the new knowledge I’ve learned in the last two years.

Rapid evolution demands me to acquire more knowledge to remain relevant. I’d be hard-pressed to find work if I was still building web apps like it was 1998, or worse, building desktop apps like it was 1995. (Goodbye, CListViewCtrl. No tears.)

Summary

By continually learning, not only am I intellectually stimulated, I grow in professional value. Corporations pay a lot of money to the niche few who keep their skills relevant. They stand in awe and fork over the dollars by the truckload for the magical wizards who pound on the keyboard and produce revenue-generating, business-critical apps.

So yeah, Yet Another JS Framework was announced today. And I’m OK with that.

Advertisements

Share this:

Like this:

LikeLoading...

Related

Author: Judah Gabriel Himango

I'm Judah: disciple of Yeshua, technologist, builder of things that produce goodness. I blog on the intersection of Judaism and Christianity at http://blog.judahgabriel.com. I'm the creator of MessianicRadio.com.
View all posts by Judah Gabriel Himango

16 thoughts on ““Yet Another JS Framework” isn’t so bad after all”

My counter to this would not be that it’s _another_ JavaScript framework, but rather that it’s another _JavaScript_ framework. It’s a language that tries to follow a number of paradigms and yet doesn’t follow through with any of them, so every little framework and library has a different concept of which paradigm mix to aim for. And with some of the features being introduced in ES6, I can honestly see the confusion increasing.

It may be true that JS isn’t a great language, and it’s being pulled in all directions. And yet, JavaScript still wins thanks to the pragmatic reality that web apps run everywhere with zero install. It’s one of the reasons the web always wins.

So, JavaScript is just along for the ride, an incidental success that merely rides the coattails of the success of the web. Maybe it would have been better to have a Ruby or a C#-like language in the browser. (Or, God forbid, VBScript.) But that opportunity passed long ago.

If language is the hangup for you, have you considered CoffeeScript, which is basically a Ruby compiled to JavaScript? Or TypeScript, which is like C# compiled to JavaScript?

I’ve definitely looked into them, but the problem seems to be almost the opposite: not _enough_ library or framework support.
I may be mistaken, though, as I certainly haven’t checked too deeply whether incompatibility is really an issue.

And all of what you said is wonderful when you’re young, single, childless, don’t own a home, and have no other interests outside of technology. As I’ve grown in age I’ve acquired a wife, a house, pets, and other hobbies. I can’t dedicate the 8 hours a day that I’m not at work and not sleeping to learning the flavor of the month. And then there are the recruiters who no doubt are, as I type this, asking for people with a year of Aurelia.

Don’t misunderstand, I’m not promoting stagnation by any stretch of the imagination. I would, however, like to see a slightly slower pace to the innovation. These days you can barely finish an application before two new-and-improved frameworks have been released.

Thanks for the write up! In regards to your opening summary, I’d be interested in your thoughts on the following counter points.

1. Increases your happiness
I don’t really see any argument in your article that shows why adding more JavaScript frameworks would increase developers happiness and there are a few reasons why it wouldn’t. The constant churn of the same ideas in a different light can be hugely demoralizing (framework fatigue) but is the somewhat necessary cost of letting “Better ideas rise to the top”, problem is people are caught in the middle.

2. Increases your mind
I agree that exposing yourself to lots of different frameworks can give a good opportunity to stand back and analyse why some concepts worked and why others didn’t/identifying points of friction, however, like anything, how much of that knowledge you will use in the future varies. For frameworks like AngularJS, there is a lot of knowledge that is “throw away” and I’d argue that frameworks in general have a pretty poor ratio of transferable knowledge to ‘framework specific’. The human mind can only retain so much complexity, we compress things into concepts, linking ideas, muscle memory etc rather than memorization, and the more special exceptions you have to carry around when dealing 10 different frameworks, the harder it is to context switch between different projects (just my opinion).

3. Increases your wallet.
This one I don’t disagree with, I have been (and still am) the beneficiary of this fact. However, finance is a 0 sum game (with the exceptions like countries printing money), you are potentially taking money away from a project/business and giving them what might be a long term problem because the framework chosen becomes the bottom part of letting “better ideas rise to the top”. Obviously this is more of a project management issue, but developers feed into this a lot. So while this benefits individuals wallets, in my opinion, it can come at a steep price to others, including other developers. Consultants get to walk away, but there is a good chance some one is going to have to maintain what you build/help build for years to come.

I think the best thing for the JS world is some stability, but this seems extremely unlikely. The biggest concern is the constant churn of varying frameworks is going to introduce a mountain of tech debt that will just keep reoccurring (great for consultants I guess) due to the poor maintainability of JavaScript compared to other languages. Developers would rather rewrite than build on poorly thought out concepts from people trying new frameworks only to realize what they have done is just write a big ball of mud that’s difficult to extend/maintain. Throw away, rinse, repeat.

If you don’t think ‘too many frameworks’ is a problem, what do you think of ‘it takes way too long to study frameworks enough to reject the unfittest ones’?

Fine, make all the frameworks you want. Just disclose exactly what each one’s pros and cons are so everyone can do their rejections faster and spend the saved time learning the details of the good ones.

This is a problem that I have worked a lot to solve. I made a nice, neat, comprehensive (1400+ item long) list of possible framework ‘pros’ with YESes or NOs to indicate whether each framework does or does not provide each benefit. Instead of taking days or weeks for a developer to unearth the tradeoffs between two frameworks, it takes seconds.

Sound good? Well, not to most of the framework makers. Egos are on the line. They want to spin and they want to hype and they want to win. They don’t want to fully disclose everything that’s good and everything that’s bad about their babies side-by-side with all the other babies.

This has been an enlightening but disappointing human nature experiment to see whether technologists behave better than nationalists. If the goal of framework makers had actually been to hasten evolution and advance the state of the art, they would be happy to clarify everything their technology can and cannot do in order to save people time that they could otherwise spend learning and improving the best option. I’ve written to all of them. Fewer than 10% agreed to disclose the pros and cons of their technologies in exhaustive detail – an ongoing task that would take them a tiny fraction of the time it takes me because they know their respective technologies inside and out.