
JavaScript development is not fun for me anymore - jspekken
https://medium.com/@paulvm/javascript-development-is-not-fun-for-me-anymore-ac4e9d7b89a3
======
gtsteve
I don't think there's that big a problem with how many front-end frameworks
there are, and the pace of development. I think the problem is people who feel
they have to use the latest and greatest feature and they have to know all the
frameworks.

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.

~~~
StavrosK
> 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.

~~~
amelius
The problem is that everybody publishes bugfixes alongside new features. This
practice should be stopped, because it leads to dependency hell.

~~~
eropple
Open-source maintainers should _totally_ leverage this opportunity to make
their projects sustainable. _Sell your backports. Enterprises want them._

~~~
rattray
That actually sounds like an interesting business model.

What form would the transaction take?

~~~
amelius
Yes, and how would maintainers know which versions of their software are
actually still used?

~~~
ebiester
You mark releases as "Stable and supported" and have corporations subscribe
against releases. If you are subscribed to a release, you get bug fixes for
that release. If someone does not have a subscription to a release, it does
not get updated, and if there is no current subscription for that release, you
don't accept new ones.

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.

------
sametmax
But JS dev has never been fun.

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.

~~~
turtlebits
Async is super simple in JS. Yes callback hell can be an issue, and it may be
ugly, but there's many a time where I wished for it in Python and ended
writing a script in NodeJS.

~~~
tdbgamer
Python has asynchronous coroutines (the async/await thing) so you don't really
need to do callbacks as far as I know. I personally find that syntax much
easier to follow than callbacks.

------
cc81
React + (early flux and later mobx) made web development fun again for me. I
was burned out at the end of the jquery era with all the different homemade
structures and the limitations of browsers.

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.

~~~
alexfl
I feel the same way... web development was hard, until I've learned about
es6/babel, webpack, redux and react (I'm using morphdom as react replacement,
but idea is the same). Now web dev is easy and fun. I have state, components,
events and routes. That's it. Update the state and stay calm.

The idea to concisely manage the state together with dom diffing, are my
personal favorite game changers.

~~~
mring33621
Can you provide some guidance/links to a backend Java developer who wants to
learn & use a quality long-term, front-end tech stack? Is there a kickstart
example project for your preferred stack? Note that I prefer to avoid nodeJS
for any back-end production use but am ok with it as part of the dev
toolchain, if required. Thank you.

~~~
cc81
I would say just start with the React tutorial and use the react-create-app
(uses webpack etc in the background and is a npm package) that they use in it.
Then after the tutorial I would go into the docs and read through them and
maybe test some.

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](https://facebook.github.io/react/tutorial/tutorial.html)

[http://redux.js.org](http://redux.js.org)

[https://mobx.js.org](https://mobx.js.org)

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.

------
tabeth
Just pick one and stick with it. There's some serious FOMO going on in the
JavaScript community. When you read articles talking about all the great
benefits they see from switching frameworks, _what you don 't see are the
gains they'd have if they just rewrote everything in the same
language/framework, taking advantage of the increased experience since the
original write._

------
robodale
14 year .NET veteran here. For me Javascript (actually Typescript) using Vue
as the front-end reinvigorated my joy of creating web applications again.

~~~
sametmax
Vue is the only glimmer of hope a JS project gave me for the last 5 years.

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.

~~~
ng12
Out of curiosity, what did Vue do for you that React didn't? I've been writing
React for three years now and I can't find a compelling reason to even try Vue
out.

~~~
sametmax
Nothing.

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.

------
einrealist
I totally agree with the sentiment. While others tend to use SPAs with their
complex build system and lifecycle for everything, I follow principles of ROCA
[1]. I don't understand why people think it is better and faster to make
complex clients that include logic, that has to be verified on the server
anyway. Everything I saw / see in the enterprise world is reinvented for
client-side development again.

[1] [http://roca-style.org/](http://roca-style.org/)

------
arrmn
The last time I've really touched JavaScript is about a year ago, I'm just
working with Python these days. Thinking back, I had 2/3 newsletters about
JavaScript and whenever I've read them there was a headline "why X is better
than Y", "Y has no chance against Z" "Good old X is better than Z,Y".

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.

------
abhisuri97
I teach a course at upenn on intro to javascript. Perhaps the most useful
advice I give to my students is that often the simplest tools will get the job
done i.e. you don't need React, Redux frontend stack because for most cases
jquery will get the job done much quicker. Only worry about the frontend
libraries when you feel it's getting out of hand, otherwise, the simple,
straightforward tools will suffice.

~~~
amorphid
I haven't coded much JS since ES5. With the improvements to vanilla JS, are
there still a lot of things that jQuery provides that vanilla JS does not?

~~~
abhisuri97
Yeah vanilla js still is a pain to access the Dom with.

------
gorpomon
The desire to constantly switch JS frameworks is really confusing. I find each
one different, exciting in their own way and fun to learn. However, and this
is a big however, none of them radically change the work you'll create, so I'm
happy with React, and not interested in learning just to learn. Maybe in a
year or two, I'll try Vue, it won't be too hard to pick up.

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.

------
jroseattle
Speaking as someone who has seen the ebb and flow of frameworks galore on the
front-end and back-end, I've found many devs swing back and forth between love
and loathing. It's just a natural evolution of how we use tools, and quite
often the over/under application of those for the problems we're trying to
solve with them.

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.

------
moron4hire
> After I was done with the front-end of a project, I hated that I had to do
> the back-end. I also was not good at it.

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.

------
adamc
I think this is a good description of how front-end development has become a
"tool zoo", where new versions of libraries and frameworks are often radically
different, and new libraries/frameworks keep popping up. I compare this to
Python, where most of the time learning a new library will keep paying off for
years and years. It makes front-end development an expensive (educationally)
place to work, and the maintenance costs of the code are substantial.

------
Kiro
> How to use styled-components to make JavaScript in React do what CSS can do
> on it’s own.

Stopped reading right there. CSS-in-JS is one of the main reasons I'm even
using React to begin with.

------
iamleppert
Spend your time learning something that isn't subject to fads. In five or ten
years, React will be a distant memory. Just like all the PHP frameworks are
now.

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.

------
saosebastiao
I hate JavaScript with a passion, but 95% of that is fixed with TypeScript.
But the thing that TypeScript can't fix isn't really related to JavaScript,
but rather everything around it:

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.

------
bob1029
I started to feel the same way as the author when 2016 rolled around. I found
myself getting caught up in the paranoia of using the latest, greatest, most
popular (i.e. supported) framework. Teammates would come to me with a bunch of
proposals about how to use X over Y. We questioned continued use of Angular
1.x and had similar negative experiences with the build processes around the
latest javascript frameworks. It really had gotten a bit out of hand
considering our scope.

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.

------
tjpnz
Despite its flaws I tend to stick with Backbone whenever I need to do anything
sufficiently complex on the frontend, and jQuery if it's any simpler. When
writing software for money I've always found it pays to take a conservative
approach.

~~~
nrhk
I wouldn't jump too far ahead when writing software for money, it's always
better to use something you know will work and have enough familiarity with to
adjust around its deficiencies.

But I think Angular 2, React and Vue are all getting to that point if not
there already.

------
madamelic
It sounds like he doesn't dislike JS, he dislikes what web development has
become.

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`

~~~
buchanaf
Well create an index.html, inline a style tag in said file, write some CSS,
npm init, npm install http-server -g, update package.json to with this script
"start": "http-server", and profit.

Fear not, we have the technology.

------
vosper
My biggest complaint about Javascript development is the config... OMG the
config. So many modules, so many dependencies, so many build steps, so much
half-baked documentation, so much assuming that you already know X, Y, and Z.

------
Zelphyr
To put a finer point on his argument; I'm working on an Angular project at the
moment. Every time I refresh the page I have to wait 10 seconds before I see
any of my changes while Angular compiles everything. I calculated that, given
the number of times I have to refresh to test my changes, all of those 10
second compilations is costing my client tens of thousands of dollars every
year in wasted productivity. So I can't help but wonder how Angular and their
ilk are better?

------
Kaotique
$ ls node_modules | wc -l => 872 * Starts crying _

------
mattacular
It's been fun again since I stopped worrying about keeping up with framework
churn and all the tooling. I still feel bad when people ask what framework we
use and I can rattle off a list of trendy new stuff but I quickly remind
myself how asinine that is and go back to making perfectly fine, successful-
in-production JS apps with stable boring things like ES5 and Backbone.

------
jancsika
> So that’s why I’m now learning to be a Web Animator and UX Designer.

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.

------
pier25
Well, that's what happens when you move the problems from the server to the
browser (routing, dynamic data, auth, etc). instead of focusing only on UI you
are working on a complete application.

I like making SPAs, but there is really no need to do that. In many cases
making an SPA is not even desirable.

------
acty1
Using Typescript with Angular2 + RXJS is like my second wind and a breathe of
fresh air. It's like web development is "real" software development now.

------
randallsquared
> [Front-end is] looking more and more like the back-end

This rings true to me. It's also partially why I don't really mind front-end
development like I used to.

------
arstin
I must admit having a hard time relating to all the complaints over js churn
and the new world of...compiling code. I hated website dev in the past, hated
using jQuery, hated being driven insane by the css cascade, hated wasting all
my time on arbitrary and stupid browser incompatibility bugs with magic arcane
solutions.

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.

------
pendar747
He wasn't a programmer since the beginning. He was a designer.

------
moron4hire
I think Framework-itis is a result of front-end developers—who are often
junior developers who may not even have CS degrees—inculcating the false
message that they are not "real" developers. As an industry, we have treated
front-end development work as entry-level, occasionally even frivolous work,
as it grew organically out of the left-over work that systems developers gave
to the designers.

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.

~~~
atoko
You're drawing from quite a lot of assumptions. Consider that until recently,
"front-end" work was done mostly on the server.

~~~
moron4hire
I think I know what the history of web dev for the last 20 years has been,
considering I've lived and worked through it. Your comment doesn't change
anything. There has always been a client-side component of web apps. While in
modern times it has become more richly interactive and complex, it's pretty
clear the people who work on it have not received a similar upgrade in
respect.

------
rhapsodic
_> Plus, now I have to learn what Redux is, and how Vue is the next best thing
that happened since Angular 2.0. How to use styled-components to make
JavaScript in React do what CSS can do on it’s own._

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.

~~~
Klathmon
To me this kind of thinking sounds so strange.

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!)

~~~
rhapsodic
_> They are going to do a better job of designing a framework than you will in
most 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.

~~~
Klathmon
If time isn't the main factor, then by all means you have the right idea! But
I've never really been in a situation where I can afford the time and manpower
to do everything myself, so my view is skewed by that.

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.

------
alexasmyths
Please try TypeScript. It's the only tech I will actively promote as 'not a
fad' but a very useful thing. So useful, I stopped writing JS the first day I
tried TS.

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.

------
whipoodle
JS moving in the direction of being compiled, statically typed, and adding
lots of boilerplate for various reasons. When I started writing JS, it was
partially to get away from these things in the .NET world. So, to be honest I
don't enjoy these changes in isolation, but I understand why they are
happening.

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.

