JavaScript Fatigue

It's scary that if you don't jump on some kind of framework bandwagon, you'll be half as productive as framework devotees within 4-5 years.

When I joined my current team in 2015, they were still using Python Paste and jQuery for everything, while I was well-versed in Angular + a modern Python server framework. Armed with my modern libraries, I could do more in 1 day than an average teammate could in a week. In other words, my team lost a staggering amount of productivity over the past 2-3 years, just because they were hanging onto old ways that were still legit even in like 2011. And it's obvious that the half-life of frameworks is only decreasing over time.

What will happen when an average framework's half life is 1 year? Or 6 months? Humans aren't built to adapt so much, so quickly. I can gain proficiency with a new library in 3-4 months, but what happens when I get tired of doing that? Will I just fade into the background as some high school kid outproduces me 5:1 simply because he was lucky enough to learn FrameWorkABC a couple months ago while I was busy with a personal issue?

Hopefully by that time, the singularity will be so close at hand that we'll have bigger fish to fry, like basic income, or something.

As people,tools and runtimes move to ES6 modules things will get better and people will no longer have to use these dreadful frameworks. I for instance try to experiment directly with virtual dom and dom diffing, without using anything else.

I have used many frontend frameworks (Backbone, Knockout, Angular, CanJS, React, Polymer). I find React to be overly complex/bloated. It sucks you into a whole new universe which probably shouldn't exist in the first place.

At first, you think that React will take the complexity out of building apps. Soon enough you realize that React on its own isn't enough; you have to follow particular programming patterns like Flux or Redux (which adds more constraints/complexity).

Then, with all the complex data rendering happening behind the scenes (diffing), you start to realize that REST is no longer a suitable medium for transferring data over the wire so now you have to use GraphQL/Relay.

Personally, I much prefer the approach which Google has taken with the Polymer 'framework' - You can setup models (WebComponents) to hold simple, atomic values and you can wire them all up on the frontend (no diffing necessary) - You get all the live binding awesomeness without the insane complexity.

For example, with Polymer, you can setup a dynamic collection of item IDs and then use those IDs to load the individual properties of each item - You can hook everything up to update in realtime (both the collection and the bound properties for each item).

The Polymer approach is simple and efficient - Also, once the WebComponents standard has been implemented in all major browsers, you will be able to run that code without any special libraries or frameworks.

Today I started a rebuild of my website as a technical exercise.

1 working day in, and I haven't written a single line of actual html.

Do a search for "require" on npm. There are 90,000 npm packages. There's "require-dir", and "require-directory" then "require-all". Some are shims for require on the frontend, rather than for the backend.

Every other build tool has its own ecosystem of tools that shim around an existing tool. And then webpack's packages notoriously pollute the package global namespace (-loader, and slightly better -webpack-plugin).

Main problem is both the blessing and the curse of Javascript (and slightly mirrors the ongoing popularity of PHP) - there're so many resources available that it's so damn easy to get in. And it's so tempting to build YAJF/J, and even more so nowadays. And as the author mentions - there's very little community curation.

For someone who doesn't sit in the frontend stack everyday, it's quite frankly madness. It's like playing chess with a hydra. The author has problems with the React startup cost - I think it's a problem plaguing the entire js stack.

I don't get the point of this article.

It posits the usage of small independent tools as a problem, and then provides solutions to the problem that are not much more than prepackaged combinations of these tools and therefore were made possible entirely by these tools being small and independent. But these tools are apparently also bad because you need to think to use them, and write config files to tell them what you want from them.

This doesn't make any sense. The ecosystem is working as it's supposed to be working.

Am I missing something here?

PS: Not sure why you would pick on React for tooling complexity. You can use it with one tag and no JSX, just like angular or jquery or whatnot. If you also want to use ES6, JSX syntax, have your code linted, hot module reloaded, uglified, your sprites auto-generated, and all your assets packaged for efficient distribution that's not react, that's a lot of independent feature requests that require astonishingly minimal boilerplate to get running considering the value you're getting. All of that is completely optional too. If you look at how typical real-world react and angular projects look, they would be very similar in terms of build tools used.