JavaScript development is not fun for me anymore
medium.com
medium.com
At my company we picked a stack and stuck with it. That happened to be React and Redux. I hear Angular 2 and Vue are really great frameworks but I feel under no pressure to really investigate them because we're doing fine as it is.
Two years later and we've barely changed aside from some package versions. We've got a very stable front-end with high code quality and component reuse.
You don't have to listen to the hive-mind. Frameworks don't rust.
Ah, the optimism of youth. Frameworks don't rust if you don't mind sticking with the security bugs of 10-year-old kernels. If you need to upgrade your OS, you need to upgrade your programming languages, which means you need to upgrade your frameworks.
Everything rusts pretty quickly. Maybe you don't need the new features, but you definitely need the new bugfixes.
But to the point you were making - it's not impossible that browsers could evolve to the point where our current version of React is unusable and it's been long relegated to the buzzword graveyard. Of course in that situation we'd have to maintain our own React branch or rewrite in whatever was a popular front-end framework at the time.
My point is that getting stressed out about the front-end JS framework churn isn't helpful to anyone. Pick a stack and stick with it, and only move when it's simply not productive to stay.
What form would the transaction take?
I am low-key building a marketplace for this, because this really should exist. The problem, as a marketplace, is identifying projects both important enough that people will pay for it and aren't* already functionally owned by a company that has a vested interest in their own project management.
(Are you a maintainer who's interested in something like this? Are there projects you would pay for this for? I want to hear from you. com dot edropple at ed)
You always allow people to move forward their subscriptions, but never backwards. You provide migration paths for each supported release.
People will pay for it.
It's a little much to ask from an unpaid open source maintainer, and if you really want it that bad you should be willing to pay for it. Companies like Red Hat have made a living off of people willing to make that tradeoff.
I mean, you could have separate bugfix and feature releases for a relatively low cost, but that would only alleviate the problem for the duration of a release cycle.
In the JS world, there's no mastery. People just keep jumping to newest versions and spend all of their time fighting the new problems. Just. Stop.
The company I work for almost standardized on react/redux. We're not done getting rid of our old stack that people are already looking at Relay Modern, Apollo, MobX, etc. If it wasn't for our investment in a massive home grown React component library, there would probably be VueJS all over the place.
So we lose the ability to help each other. Every team is different, dealing with different problems. We can't build libraries since we don't have a platform to target. That to me makes us much weaker.
So I welcome boring. I welcome the day when people are no longer interested in it so they stop spamming npm to check if a new version of their favorite library is out to upgrade to it when the existing one is working fine.
The frontend framework we use has had six major releases in a year and a half. And I am talking, rip the guts out and change how it works major releases (How semantic versioning is supposed to work).
Like I appreciate that they are doing active development and making it better (because it is getting better, to be honest), but I still feel like you could fix bugs in some minor versions and do like cut major releases to like every six months at least.
I think the irony is that all the freedom I used to see frontend people using is coming back to bite them and their mindset is slowly moving towards what backend people have been doing for a long time.
Right now, if you're in a tech hub and you tell FE people "Sorry, we're standardizing on <thing from last year> and we're gonna hold off on major release upgrades without a good reason", you're gonna lose some people and have trouble hiring or deal with constant internal complains. Why? Because their buddies in <other company across the street> aren't dealing with that restriction.
You need some serious charisma to tell people you're sticking with last year's tech and get away with it. If you're in an environment where you can do that AND still hire fast enough to grow, consider yourself lucky and hope your boss never quits :)
You aren't proving you are resilient to changes by using one of the most current buzz-word filled frameworks out there for two years. The real test happens when your framework of choice truly becomes obsolete, like with what happened to Angular 1.
Perhaps frameworks don't rust in the sense that they deteriorate in terms of capabilities over time. But that doesn't mean that they don't become obsolete. Especially when you're building a product and trying to stay competitive, all the while all the the innovation surrounding a framework has packed up and left for a nicer camp.
The two-way binding/digest nature has really become our enemy. Everything we write has to account for digests and we've wound up with some terribly ugly code to account for digest problems.
Angular 1 is great for hobbyists and it makes implementing simple forms easy but when you use it for an enterprise app, it hurts.
Our app is still vastly better than decade-old 1.0 we've replaced, but we sure hate the digest now.
Good god. You chose Angular 1 two years ago? As in 2015? When its horrific shortcomings were already known and the Angular devs were working on Angular 2.x?
But I agree, I do not think everyone is jumping ship to Vue (or whatever) over the license.
The problem is the marketplace and the companies that will demand the skills when one is job searching.
When we evaluated what tech to migrate to from Angular 1.4, we looked at React and Angular 2. We were also hiring, and the overwhelming majority of devs we spoke to had experience or wanted to work with React.
The marketplace is directed by both buyers and sellers.
We still had to maintain them though as the clients had no money to what would effectively revamp the entire stack to something a lot more maintainable.
Working with a (relatively) unpopular & outdated framework seriously took its toll on both the quality and the developer passion. We had a few really talented people leave simply to avoid working on these projects.
Edit: To echo sixsence's sentiment: Our React & Redux projects have proven themselves to be very resilient over the past few years.
(I personally don't mind working with less popular tech part of time as long as I also work with something that sounds good in CV.)
To be fair, I would put react in the same generation of frameworks as Angular 2 and Vue. It just got to the same basic virtual dom + modular components design earlier than the rest. Vue and Angular 2 don't really offer much besides marginal performance boosts (react fiber, preact etc erase this) and a more familiar way of programming for programmers in the last generation of frameworks angular 1/ember.
Unless the framework is iron [1], of course
Web dev is fun because the browser is a freaking awesome plateform.
However, it is _despite_ of JS.
There's not a single characteristic of this language that makes it better than any other mainstream high level language out there. We use it because we have no reasonable alternative on the browser. It has always been a pain to use, requiring:
- avoiding part of the language that is badly designed to escape traps.
- recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc.
- fight with the various implementations to find some code that will work for most of your customers.
- use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS.
The fact that the community is now shooting itself in the foot by providing so many incompatible, badly documented and breaking-compat-all-the-time tools is just icing on the rotten cake.
P.S: since this comment is getting upvotes, I will say that having used in prod vanilla, jquery, react, angular and Vue, I will stick with Vue for the next years. I'm done. My quest is over. It takes 3 hours of reading to be productive with it. It requires no tooling and yet can be used with existing tooling. It's fast. It's well documented. I can now focus on writing software again.
It's not so bad now. The language is evolving and gaining these kind of features (modules, standard methods to manipulate data structures). Lodash is just like #include <stdlib>.
> - fight with the various implementations to find some code that will work for most of your customers.
Again this has gotten better over the years. We write vanilla ES5 code with Angular 1.4 and it pretty much just works in every browser. With transpilers it's even better.
> - use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS.
TypeScript and the various babel transforms generally give you a superset of JavaScript, not a different language. JSX lets you write more JavaScript, not less, compared to frameworks that have templating systems.
I'm a bit surprised at these comments if you're writing JavaScript today, for me it's much more accurate of the state of affairs 5-10 years ago.
This is universally true for any mainstream language where age > 10 years.
> - fight with the various implementations to find some code that will work for most of your customers.
That's an understandable tradeoff from the ability to write code that can run on thousands of different devices. It's very much preferable than writing native code for each platform and all the various implementations that would require.
Basically agree with your other points.
Consider the wide range of devices that a JS code must support. There is some pain in supporting all of them, but compared with Android development, the transpilers and shims available in JS seems like magic. Cross platform programming is hard, and JS seems wierd because any JS code must consider it, while many C programmers never need to think about it. Taking cross-platform into account, I prefer copying some shims from MDN to using IFDEF WIN32's.
Or consider GUI development. The nice API for working with DOM, lots of available UI components, and specially the asynchronous programming model made possible by Promises is really nice by GUI-programming standards.
Also the good parts/bad parts mindset belongs to the past. I can't remember the last time I even thought of using == vs ===, prototype hacks or similar "bad" parts. The usual post about strange behavior of ">=null" on HN is just amuzing, not problematic for my JS coding experience. As said in other comments, maybe everybody should just stick to using their prefered JS framework and master it.
usually do not have to think about it anymore.
If you don't like the language, that's fine. There's no shortage of languages out there.
But when it comes to the language itself... speak for yourself. Up until about 5 years ago, I thought JS development was a blast, and I was enjoying it enough that I was using Rhino as my alternate language for the JVM and having fun there too.
And I've built things in a dozen languages, so this isn't didn't-know-much-else-ism.
The fun didn't start, though, until I stopped expecting it to be something else.
"avoiding part of the language that is badly designed to escape traps" == understand the language well enough that what you expect to happen is what actually happens (and accept that just because you're familiar with one behavior in other languages doesn't obligate any other language to replicate it -- those expectations do not necessarily constitute the principle of least surprise).
"recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc." == understand the features that exist in JS well enough that you know how they can do the job you expected features from other languages to be required in order to do
And that's been true of any fun language I've found. There are some languages that never became fun for me because either I don't want to do things the way that the designers do (and in some cases because I expect the designers don't want anybody to have fun, they just want it to be a tool), but all the ones that did become fun required me to actually learn them first. And if somebody actually likes dynamic scripting languages at all, I'm baffled if JS-the-language isn't something they can't achieve contented productivity in. In fact, I'd go so far as to say I'm skeptical that a developer who can't achieve that in JS can genuinely achieve it in Python or Ruby.
"remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS."
For one thing: coffeescript has never been anything other than JS semantics, saying that using babel is an attempt to avoid using JS is like arguing that using Python 3 is an attempt to avoid using Python, and JSX is entirely orthogonal to this topic as it's essentially a templating tool that happens to be a language extension (like E4X) instead of a string processing library.
For another thing... I do remember that 10 years ago that among the contenders for JS libraries there were a number whose central conceit was that the problem with web development was that JS wasn't enough like development in some other language. Prototype's ethos, for example, seemed to be that it wasn't enough like Ruby.
jQuery was like "nope, the chief pain point is our browser APIs, what if we had some that were more amenable to concise practical use, took advantage of JS's functional strengths, and were normalized across browsers?"
I think it's pretty obvious in retrospect who had the key insight.
And I think that most of the progress from this point will come from people who have the same insight: understand JS's strengths, play to them, don't treat the browser or the language as if they need to be some other platform, think about what the general project pain points really are.
Then I came back to React and babel/gulp (later webpack). Suddently there was structure in the front end that was easy to get into a project and contribute. Building components just felt right. Also js was almost a modern language now and I could use it even if the browsers did not actually support it yet.
With the huge number of frameworks/libraries/guidelines out their for JS developers, if you can't find a combination that works for you... then front-end work just isn't for you. A lot of people moan about the massive choice of frameworks and libraries. But even the most popular, most maintained and most loved ones will be replaced in a number of years. So find your combination, learn it inside out and ride it's wave until it's time to learn something new that changes paradigms and mindsets.
The idea to concisely manage the state together with dom diffing, are my personal favorite game changers.
After that I would pick the state management tool I want. Either Redux or Mobx as both are popular and have their advantages and disadvantages. I think it is worth going through both their official tutorials as they are pretty good.
https://facebook.github.io/react/tutorial/tutorial.html
There are of course tons of videos but I think the official tutorials are a great start and using react-create-app instead of trying to dig into webpack and all that is really good at the beginning.
I actually sent a donation the very first afternoon I started to read their doc, because I decided that even if I would not end up using it, I wanted the author to be supported for just existing in the universe.
Of course I ended up using it anyway.
For me the selling points of Vue are:
- You don't need tooling to use it. You can use tooling, but you don't need any. It makes it freaking easy and fast to start a small project with Vue and increment on that. Webpack can wait.
- Vue doesn't force components on you. Since most of my "widgets" are not reusable anyway, I really loves this. I write components only when I need to, usually a dozen per projects.
- You don't have to pass state around using callbacks and props to make it works without a store. State is just an easy mutation away. I'm not facebook, most of my projects don't need a flux pattern, and having Russian dolls data passing shenanigans just so I can update my UI is a pain.
- Vue documentation is stellar. It's wonderful. Like a walk in the parc with a friend.
- Vue is so easy to start with. React took me a while to click. Vue took me 20 minutes. It's incredibly easy to train new people coming to your project. And as a professional trainer, the difference with students is just night and day.
- Vue is very, very efficient. The lib is so small. But yet it's faster than react.
- Vue has a lot of helpers that you can tell have been made by a pragmatic author. onclic.prevent and v-on:customevents are poetry to me.
- After after hours and hours of react, I still have to look at the docs. I still have surprises. With Vue, the surprises stopped after day 3.
- I hate JSX. Matter of taste of course. I like the Vue template language, but Vue can optionally use JSX if you prefer it.
- Some very vocal people in the React community are dishonest. They will tell you you can use react without tooling or JSX because technically you could. But technically is not pragmatically. Nobody would. And you are on your own if you try. I hate fan boyism. Compare to Vue: the author even has a comparative page of most frameworks with Vue. He co-wrote the react part with react authors to get it fair. That, I like.
I was always feeling, that I'm missing out on something and that I needed to learn new things. Switching to python actually made writing code enjoyable again.
(Also, hey neighbor—I live right off campus)
If you're at BigCo making internal apps, each one is basically dressing on a way to make various interactive UI states. How you get there is no big deal. How the data flows is no big deal. What test runner you use is no big deal.
As a JS dev, my passion is to learn completely non-JS related things. Cryptography, Blockchain, CS Fundamentals I missed. These are much more interesting than the churn.
We've never had more options available to all of us to build complex systems, applications and services using highly-targeted tools. The new-framework-a-day pace at which these become available to us is fine, but honestly doesn't move the needle for most of us.
A former leader of mine once said: you build things with tools, not popularity contests. I've found keeping such a perspective makes my stress level manageable.
After many, many years of tutoring students in a variety of subjects, there is definitely a connection between the last sentence and the first. People who work hard to get good at a particular subject often find themselves enjoying it a lot more. But humans don't care much for delayed gratification. If we have work that we could be doing that we enjoy more than some other work, than the hated work gets put off. Often indefinitely, as no skill in it ever gets developed, the more it is put off.
Stopped reading right there. CSS-in-JS is one of the main reasons I'm even using React to begin with.
Focus on getting good at the web platform standards. I personally jump at any opportunity to learn new web platform APIs, graphics techniques, design patterns, data structures, and different business domains, and stay away from technologies that are fad-driven.
Get good at a few basic tools and focus on application development. It's not about the code its what we make with the code.
1) Build systems suck. Millions of plugins and adapters, opaque json configurations, silent errors, finicky and difficult optimizers, source maps upon source maps, shims everywhere, etc.
2) Browsers have unpredictable noncompliance with standards, HTML doesn't work well for user interfaces, CSS is obtuse, etc.
I found the light at the end of the tunnel with Riotjs. It is close enough to the bare-metal JS runtime to keep you sharp in that regard, but also provides a lot of utility around building components without tying your hands in any particular way. For someone who is trying to build the best UX experience possible, I feel like riot or even vanilla JS provide a much better experience for expressing yourself.
Front-end frameworks seem to me to be just a way to systemize the UX/UI problem into a thing that back-end engineers can reason with. Staring down a blank HTML/JS/CSS document without any constraints imposed on you can be a very daunting task until you truly get a feel for it. I strongly believe that one can be VERY productive on even the most complex web project without use of any frameworks, assuming they have the correct "artistic" mindset and the ability to balance that with systemizing the problem. My perspective is that the web is 3 languages (HTML/CSS/JS) and they need to be treated as equals. Any time you bring in a framework that does not consider all 3 with the same priority, I strongly feel like you are losing something.
Since switching to riot/vanilla js, I have spent WAY more time thinking about how I want the UX to be than how I can force it into the various boxes some framework wants me to. In the Angular world, things like "it would be nice if that checkbox turned into a DDL when checked" would result in sweaty palms and much googling for phrases like "dynamic element swap directive" and an entire afternoon wasted. When you are used to working with DOM directly on a daily basis, this is a hilariously trivial activity requiring about 2 seconds of deep attention.
But I think Angular 2, React and Vue are all getting to that point if not there already.
I dislike build tools and all the little doo-dads that we have to have now. Like, sometimes I just want to write some CSS and launch it with `npm start`
Fear not, we have the technology.
Has anyone played around with the Web Animations API?
I noticed that Chromium now lets you use elem.animate to animate SVG elements-- even properties like "width" which aren't technically presentation attributes in the 1.1 spec.
Anyway, it's a very handy interface and easy to play around with inside about:blank to prototype things.
I like making SPAs, but there is really no need to do that. In many cases making an SPA is not even desirable.
This rings true to me. It's also partially why I don't really mind front-end development like I used to.
I develop apps---not traditional websites---so I know this colors my experience. But every single tech change that I've made the past 4 years has been motivated by a real need. (Of course this assumes I have control over the tech: I'm grateful that I've only been forced to work on one Angular project for work!)
I started using React in December 2013 after a shootout of the competing view libraries at the time because I didn't like having to be Sherlock Holmes to figure out how to change someone else's (or my own!) wild jQuery code, and I always inarticulately felt like I was fighting against a natural flow when using the old MVC frameworks. I now haven't churned my basic framework for almost 4 years. And don't expect to for many more! (I know that to an extent I got lucky: it's easy to forget now how much shit I got at the time for using dumb React lol compared to Angular). Ember is fascinating, I'm glad Preact, etc is around as a backup...but churning would solve no problem for me, and most jobs I'd get (for years now) require React, so why worry about changing?
I've been a redux user for over 2 years now. I eagerly switched over the codebase I was working on because it solved a need I had: getting rid of a bug-prone, undocumented state solution of my own design which everyone else had to figure out for themselves. I expect I will switch out redux one of these years. But haven't seen anything to motivate it yet. Mobx-state-tree is very interesting, but until I see the benefits are worth the switch, why churn?
I did really hate having to worry about babel, webpack, etc since it distracted from writing actual product code, though ES6 was just so obviously better than old JS that it was worth it. But now create-react-app and its siblings make the dev environment a matter of typing a single command. Contrary to this article, it points out errors that could easily have gone undetected in the the old world of wild web dev. No churn here. CRA all the way. Until I run into a need for something new.
Styling solutions are something I have actually churned. But because I knew I wasn't committing, all css-in-js library code I write is in two or three "ui library" files. The app code itself only uses a jsx prop interface. So swapping these libraries on a mature app takes an afternoon at best. Though for the first time I now expect that I'll stick with Glamorous. I expect I'm going to stop churning here because I'm aware of no problem I personally have that Glamorous does not solve, unlike previous css-in-js libraries.
I don't know, this guy's rant just put me in the mood for ranting lol. Anyway, I'm glad this guy found his real interest now might be as an animator and UX designer and I wish him the best! Those are important contributions too, possibly more important.
Developing a framework doesn't look very much like doing front-end work; frameworks are generic, planned, and built from scratch, whereas the typical front-end developer is used to making highly-specific, ad-hoc changes to existing code (either because they've come in on a project started as a proof-of-concept by more senior developers, or they've used a boilerplate generating tool). Being more like so-called "real" software development, only "real" developers should be allowed to work on something ostensibly so important and complex as a "framework".
The front-end developer has been indoctrinated into believing she (and it's very often a she, 'cuz design work is women's work, amiright?) has no business writing code, and that the code she does write is woefully "WRONG, WRONG, you're doing it wrong! What are you even trying to do?" by the karma-craving, bottom-feeders of StackOverflow. To avoid further public shaming—lest there be some hidden defects their inexperienced eyes cannot detect, no matter how trivial the bit of code may be—they avoid the actual act of writing code as much as possible and spend an inordinate amount of time searching for packages that may be imported from the gods. Thus left-pad, and the ensuing post-hoc rationalization in that debacle's aftermath that such trivial micro-packages are somehow a good development practice.
I don't think there are a uniquely numerous quantity of framework projects in front-end land. Systems developers make custom tools all the time. But systems developers don't have a general fear, uncertainty, and doubt about their own work sewn into them, so it's more common for systems developers to jump into writing their own code than looking for pre-existing tools in whatever they might deem as trivial. Instead, I think a plethora of front-end tools reach a unique tipping-point level of popularity giving the perception of many more tools total, because of a general fear of falling behind. The front-end developer sees themselves as having no business criticizing their "betters" and must therefor accept what is handed down to them without question. If the front-end developer cannot prove they are a good little worker bee by keeping pace with any and all frameworks their benevolent employer or more-senior, more-"real" coworkers may spring on them, they risk having to go back to working as a barista.
Something to think about while replying to a seemingly "simple" questions.
I'm glad I get to call the shots where I work, and I've steered my team clear of all of this stuff. If you have a deep knowledge of the core technologies -- HTML, JS, and CSS -- you can build a great front end with a reasonable amount of time and effort. If something breaks, it's likely going to be our own code, and much easier to diagnose and fix.
A framework is (like it's namesake) a frame that you can build around, it's a tool that enforces restrictions on you by design. Obviously there is some overhead to learning that framework, but the idea is that the framework is built by someone who spends their day-job building the framework. They are going to do a better job of designing a framework than you will in most cases.
Yes, you can build something great without them, but for any moderately sized project, you will end up re-inventing a set of rules and restrictions to apply to your own internal code. You will in-essence create your own framework.
And that's fine, I'm almost positive that your "framework" will do some things very well, probably better than most of the competition, but you need to ask yourself what your main goal is. Are you setting out to build a framework? And/Or are you trying to build a product?
If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Doubly so if that framework isn't designed to be reusable at least in your organization. Not to mention the overhead of having all new devs have to learn it anyway.
However if the answer is that you are setting out to build your own framework (because the current ones have a limitation that you can't deal with, or some problem that you need to solve yourself), then by all means go for it! But that can't be given as "general advice" as for many people (I'd guess most people), as they don't have those same goals as you do.
Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. (but not all cases!)
My own framework will do exactly what I need. No more, and no less. It will only solve problems that I actually have, not ones that I don't. My framework will suit my needs better than theirs will, each and every single time.
>If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one.
Time is not the main factor. I would rather have something lightweight that does exactly what I want, and only what I want, than some sort of generic one-size-fits-all thing. I don't want to deal with upgrades that are not backward-compatible. I don't want to spend days debugging someone else's to figure out what I did wrong.
> Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases.
I'm not telling anyone to do anything. I'm only sharing my own personal views on the subject of the article. For a lot of people, I don't doubt that React or Angular is the best course, for a variety of possible reasons.
It's obvious to me that you and I approach the craft of software development from two entirely different angles. It's obvious that you perceive a great deal of value in these framework, so your best bet is to continue using them.
And I do apologise for going off on the tangent there about not telling people to do X or Y. I got a little wrapped up in it and that comment was less targeted at you and more at other people I see advocating for it.
Also, I wouldn't say I perceive a great deal of value in these frameworks, just that I use them like tools where they make sense. Across our codebase we have 2 react applications (one with webpack, one with just script tags), one node.js application without any real framework, and one jquery+vanilla-js codebase. We use the frameworks where they make sense, and don't where they don't. And while i'm absolutely certain that a purpose-built framework would serve us better in many areas than something like react will, I don't have confidence in my skills to create something that will stand the test of time. I know what I don't know, and I'm pretty sure that I made the right choice externalizing that work on to someone who has a team of people working just on that aspect.
I try to spend my time where it's best used, and in the vast majority of cases I've found that it's best spent working directly on my problem domain, and not on aspects like state management, rendering performance, cross-platform compatibility issues, and more where it's not needed.
If you're building anything else, say, a hand mixer, you're going to spend just as much time on the cnc machine trying to design toy truck whisk attachments as you would have spent just building a new mold with the incredibly powerful cnc you already have.
It goes like this:
This is hard
=> I want to do one or two slightly different things
=> Building custom things feels like valuable work
=> Use the CNC machine!
The word 'overspecialized' is a bit sour for web frameworks. There are billions of web sites, most of which are astoundingly similar. Squint at the front-end UI and most engineers are basically building Asana, over and over again, like a boot stamping on a human face – forever. The ways they are differentiated are generally not related to code at all, instead business or meta-engineering needs (e.g. NYT dataviz graphics production, or a small team trying to maximize output).
In contrast, everyone needs a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things. If you think Angular (which, stripped down, is ~20kb gz and very basic indeed), or really any framework is too specialized for some set of needs which includes the above four things, you are attacking a very frightened-looking scarecrow with the might of the U.S. Navy. Framework churn is part of this problem; people think they have such big engineering tasks ahead only the new shiny thing can solve it.
The point is, needing the whole CNC is _very rare_. Anyone who thinks that all of the big or even little front-end frameworks are too specialized should go look in the mirror. If, when you do that, you literally see a company with 300 engineers or incredibly specialized needs – like immersive interactive media, or you need IE6 compat, then go build your crazy stuff while the rest of us churn out decent apps with near-zero friction.
[1]: https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensi...
With the cnc, you can pick parts and modules from a much bigger pool, then cut your enclosure to match. A widgetized, self-contained module is much easier to adapt to a particular use than a framework, for the same end result.
No matter what if you are using 3rd party libraries you will be writing some "glue". You will need to hook into their API and have it work in your application. Yes frameworks tend to enforce a structure on what that API has to look like (at least from a macro view), but that's a pro of them, not a con, and it's almost never "required" (you could just as easily use the library directly. If you can build a "connector", then you can use it directly whenever needed if it's not much code).
Yes, you may need to write more adapter code than you would if you weren't using a restrictive framework, but once written that "adapter" can be treated like a widgetized self-contained module. And it's instantly understandable to the rest of your dev team because it acts just like the other components/widgets in your codebase, using the same data flow, using the same UI system, etc...
Great: the dragula library handles lots of common drag/drop patterns.
Not great: it relies 100% on the jQuery model of 'truth in the DOM', and the glue code makes a feeble attempt at flipping that around. When you drag, it literally moves the element and notifies you that it has done so. If you want to customize it, you reply to callbacks that give you the literal elements, and maybe read a data-attr off them. The glue code can automatically mutate an array to match what happened in the DOM, which has been an unmitigated disaster judging by the hundreds of GitHub issues mostly about this one thing.
The problem isn't the restrictive framework that doesn't let you do what you want, it's the API that's not designed for rendering from a non-DOM data model. If you ask 'would it be easier with vanillaJS?' the answer is no – it would still be a stupid way to write drag and drop code, unless you were coding your vanillaJS in an equally abhorrent way.
Using a framework because it happened to work last time isn't a good criteria for selection. More and more I'm seeing over-engineered projects that took longer to build than they needed to and are currently harder to support than necessary, all because someone wanted to use their favorite tool.
But conversely, common problems and issues with frameworks are easy to find via Google and StackOverflow.
For anyone with a background in classical software, it makes JS 'feel more real'.
I can't imagine writing more than 50 lines of JS anymore.
I like that we're starting to think in a more systematic way about how to organize applications, and I think that bigger codebases and teams probably benefit from using static types. But god, sometimes when you open up these codebases they sometimes hardly look like JS anymore. Not to mention the tooling and build stuff, which still have a lot of maturing to do.