
JavaScript Fatigue or My History with Web Development - akras14
https://www.alexkras.com/my-history-with-web-development-or-javascript-fatigue/
======
alanfranzoni
To me, it is incredible that the frameworks matter THAT much in the JS world.
Once you know about Javascript, the web, and browsers... any good dev should
be able to pickup such part of the tech stack (frameworks, libraries, ecc)
quite quickly.

In other environments (e.g. Python, Java) nobody expects you to know
everything about the specific libraries used in a company; once you know the
language and a bit about the technologies (e.g. work on Linux, on a webapp or
a desktop app), you're good, you'll pickup the details while working.

Forcing a technology change because it's not the "latest and greatest big,
shiny thing"... I find this is a slightly disturbing trend in frontend
development.

~~~
andrewstuart
It's a myth that developers follow trends because they're cool.

The reason one picks up a new JavaScript technology is because it is a better
and smarter way of working.

Wave after wave of innovation is bringing better and smarter ways of doing
things.

There seems to be some sort of vague idea that JavaScript programmers are
following new libraries and frameworks like there is a Solid Gold Hit Parade
of JavaScript and they all jump onto the number #1, and next month there is a
new #1 so everybody changes to that simply because it is the new #1. That
would be stupid.

I use ReactJS because it is a great way to program and gives and application
an excellent and functional structure. I use ES2015 and ES7 because they make
JavaScript very much more powerful than ES5. If something radically better
comes along then damn right I'll switch to it if I can, because "better" means
smarter, easier, faster, more powerful - some combination of those to a
greater or lesser extent.

The JavaScript community desperately needs a fresh wave of innovation - but
this wave must be about simplification - ideally the almost complete removal
of all the pain associated with configuration of JavaScript build tools, which
right now is excruciatingly and unnecessarily complex and painful - create-
react-app has started this process and sets the standard for other tools
moving ahead - the right amount of configuration is zero.

It is necessary to use a bunch of painful JavaScript configuration and build
tools in order to get your stuff to run. Waves of better, simpler and smarter
build tools overrun the previous generation because they have found simpler
and easier and more powerful ways to work.

Lets just drop the idea that JavaScript programmers are a bunch of airheads
who follow the latest trends whilst they pull on their flared pants and fancy
hairstyles.

~~~
gkya
I'm sorry but no, that's not a myth at all, and innovations aren't coming in
waves. It's mostly a mistaken perception of the sheer volume of action in the
JS sphere, most of which is not innovation at all.

~~~
ojr
With React, Redux, Babel, Webpack, I would say there are a lot of innovations
coming in through there, and the plugin system is being moved from angular,
jquery, gulp to these, if you're writing old javascript to target ES5
compliant browsers more power to you, targeting the next version ES6 increased
in volume a lot just recently the version is literally called ES2015

~~~
ehnto
The long view of the innovation in React is that it is a tool enabling a
change in pattern from "separating concerns of the view layer" to "modular
components that get fed data" which is definitely a shift in the way we have
previously worked with the frontend and I find very cool. It was also
specified in the Web Components spec that is set to become a browser native
technology, so React and friends will hopefully be replaced by native
components and maybe we can all start focusing our efforts on building
standard libraries of re-usable code that will be easily portable, and we can
all forget the JS Gold Rush ever happened.

~~~
RonanTheGrey
This is honestly the direction I see us going. Angular has also created a
component concept nearly identical to React, the only difference is
implementation details. It's a natural way to go, because it decreases
cognitive load.

I am intrigued and ponder the idea of there being "JS Standard Libs" and
wonder which ones will initially get picked for the honor. I don't think it
will be React or Angular but definitely "something" like them, even if it is a
version of Web Components.

That'll also mark a huge change in performance and download metrics, because
if your browser already has your framework built in, your delivered code base
is suddenly a fraction of what it was. And then there will be more
opportunities there, too - dynamically providing the framework where needed in
a separate code split, vs. a browser that does not need it.

We're just at the beginning, really. Browsers stalled for 15 years and have
shifted into a period of innovation again.

------
ericssmith
That conclusion made me laugh. In the early to mid 90s, I was working on 3D
interactive software. The video drivers and chips had advanced so much in one
year that all of the lovingly handcrafted assembly I had written over that
time was useless. I thought to myself, "what an unstable industry to build a
career in". I also made comparisons to accounting, medicine, and law, thinking
perhaps I had made a wrong choice.

Turns out that adapting to rapid change is a critical aspect to this career
choice. It is also a problem for businesses, which you start to grapple with
as you move up the chain of command. The mistake is wistfully hoping that
things would slow down enough for you rest on your hard-won knowledge, as in
other fields. There is no competitive advantage in aging technology.

~~~
geebee
There can be a competitive advantage in aging technology. For instance,
suppose you were writing an app that makes heavy use of scientific or ML
libraries in python, but your UI is a mainly layout and forms with admin,
login, accounts, and so forth. I could easily see huge advantages to keeping
it in python, using Django, with a bit of CSS and javascript sparsely applied
where needed.

Some of this comes down to personality, too. A lot of people talk about how
people were abandoning ruby and rails once it was no longer the "new hotness".
Plenty of us (who like rails) came to it somewhat reluctantly, only after the
benefits were very clear and the initial chaos had started to subside. We, the
reluctant ones, just tend to be a bit quieter about things. I think we're
reluctant because we see greater danger and risk in a constantly evolving set
of technologies, and we don't like spending a lot of time figuring out how to
get a drop down list to populate, not when there's limited time and there's
value to be added on the back end.

I've been at this for a while, and I'm getting more and more ok with sticking
with an aging technology - even when I know the technology is becoming
obsolete. Right now, it's pretty clear to me that web based UIs in the future
will be more asynchronous and elaborate, but there will be a lot of false
starts and dead ends as we get there. Remember spring mvc, spring di, iBatis,
hibernate, tapestry, pico, tiles struts, struts 2...? Yes, the old request-
response servlet with jdbc was unlikely to remain a choice for new
development, but honestly, I think it might have been a good idea to stick
with it for a while and stay out of that mess. Yeah, you'll need to change and
adapt, but that doesn't mean you need to jump into the swirling mess.

...unless you do! There are, of course, remarkable opportunities when a new
technology hits, and if you wait for it to settle down, you may often find
that others have too great a lead. You just really need to figure out if
that's you. Because otherwise, you may find that instead of improving the
accuracy and speed of some critical calculations your users need to improve
their supply chains, you instead spent all your time figuring out how to
asynchronously update a drop down list depending on where they clicked on a
map. And a round trip to the server and an extra second to load that drop down
list might not have been all that big a deal compared to the actual business
use of your app.

------
finchisko
It was said million time here. But if you don't like trying new stuff, learn
one stack and stick to it. Nobody is forcing you to try new stuff and then
talk about js fatigue. Personally I'm exact opposite, I love where js is
headed and like all the new stuff and stacks coming. No fatigue at all for me.

~~~
BigJono
> Nobody is forcing you to try new stuff and then talk about js fatigue

This is just not true. I recently had a discussion at work where I was flat
out asked "how do you expect to learn new things if you don't try new
libraries?". Coming up with a solution yourself (assuming these libraries are
even introduced to solve an existing problem, which is sadly not always true)
was not seen as an acceptable answer...

The options appear to be assimilate into this culture, or find a new industry
to call home. Front-end dev doesn't appear to be for people that care more
about a lean, pragmatic stack than a trendy one.

~~~
degenerate
Your work buddies have it wrong. You don't need to "try" new technology, you
simply need to "learn" it. When something new pops up, see what people on HN
are praising/hating. Hop on StackOverflow and see what the noobiest questions
are for a taste of the installation and compatibility issues. Read some of the
questions with multiple replies but no accepted answer to see how toxic or
hepful the community around it is. If the new tech has an official forum/chat,
hop in there and browse around for a bit. You'll pick up pretty quickly if a
new stack, DB, or framework is worth using or not... you don't even need to
touch it.

Scientists publish papers so other scientists don't have to run the same
experiments over and over. We have HN, SO, and other developer communities for
that purpose. Read, learn, watch, wait. "Try" at the point you think it sounds
so perfect, you have to try it.

~~~
bsaul
Your comment makes me realise there should be a way to categorize technologies
solely based on stackoverflow post metadata analysis (number of questions,
number of answers, answer scores repartitions, time between question and
answers, etc..)

~~~
johnny22
also average activity on github. Get a feel for how issues and PRs are
handled.

Sentiment analysis on issues/PRs would be nice there too.

------
Animats
_“My dear, here we must run as fast as we can, just to stay in place. And if
you wish to go anywhere you must run twice as fast as that.”_ \- Lewis Caroll,
_Alice in Wonderland_

Coming up next, WebAssembly for strong obfuscation.

~~~
SamUK96
Proprietary code blobs running in everyone's browsers. God what a recipe for
absolute carnage...

~~~
maeln
Javascript already does that. If you look at any website nowaday you will find
minified JS that is impossible to understand. What's the difference with a
binary format at this point ? It does not change the fact that those blob are
executed in a sandboxed environnement with a permission system. At least
WebAssembly is more efficient and will make it finally possible to use
staticly typed langage for web developpment.

~~~
freddex
A minor point: To be fair, minified JS is not exactly a hard barrier.
Conventional minification is just removing extraneous whitespace, newlines,
comments, etc.. Except for the lost comments (which are definitely a pity if
it's well-commented code), it's easily restored with an unminifier.

------
preordained
All this great "progress" and "innovation"...and yet, have you _been_ out
there lately? The web? Everything just _barely_ works, and I haven't the
slightest illusion that I'm using anything but a patchwork networked
application. Most times I'm trying to kill or avoid whatever the hell this
page is trying to do and just get my text or content, or submit the stupid
form.

I feel like if the front-end dev world is so keen on reinventing itself, it
should just go all the way...repackaging HTML/CSS/JS in new and interesting
forms and frameworks isn't getting anyone anywhere, IMO. Scorched earth, a new
protocol for web applications...don't even call it the web anymore...just put
on your CS hats and start over...kill the whole thing with fire.

~~~
noshbrinken
The last part of your comment blames front-end developers for the shortcomings
of the web platform. I think many would be interested in a more uniform,
stable interface. But they're not the ones with the power to change things on
the protocol layer.

------
shubhamjain
I think the problem is more common than people think. It takes lots of bad
frameworks to establish a single dominant one. It reminds me of the similar
issue PHP landscape was fraught with—lack of a framework/approach with no
downside.

Figuring which PHP framework to use was a problem of choosing between dozens
of options, each with their own mighty cons. Every time a new framework came,
it demonstrated an ability to fix all the known problems but time and again it
faltered (Kohana, CakePHP, Yii). In the recent times, Laravel has provenly
become a better choice than what was available only a few years back. It has
grown a community of a considerable size and it's unlikely it would getting
supplanted in future.

I am guessing at some point in the future, the landscape would stabilise and a
single approach would become the obvious choice for JS just like Rails is for
Ruby.

~~~
aaron-lebo
You're right, it is common and it's easy to forget that.

Python in 2007 was Django, web.py, Subway, Turbogears, Pylons, Werkzeug, Zope,
and a bunch of tools a lot of people have never heard of competing for space.
Who needed all of those frameworks anyway?

It took awhile but slowly what works and what doesn't was figured out and
we've got better approaches. Web programming circa 2007 was by its nature
simpler and despite that the Python community (which is a blip compared to the
JS community today) churned out a lot of stuff.

You can still build websites like it is 1999 but you've got a lot of other
options now, too. Use the best parts and dip your toes into that stream of new
stuff when you feel like it. Competition and progress beat the hell out of
stagnation though.

------
patatino
I fell in love with web development over 15 years ago because it was just a
request to the browser and an answer.

I've worked on windows applications and just hated it. All this code handling
the state of controls depending on the input/action.

Sometimes I have the feeling I'm doing this stuff on the web again which I
haven't for over 10 years and it just feels wrong.

~~~
aaron-lebo
What's difficult about it?

The underlying model is incredibly simple. You have a visual model/datastore
that you manipulate and the UI changes as a result. Interactions with the UI
drive events which might call out to a server or do a calculation, which in
turn changes the view model/datastore and that changes the UI and so on and so
forth...

You probably get that, but I've down programming with wxPython, Qt, etc. I've
done Django, Rails, Flask, etc. and frontend frameworks are so much more
powerful and easier to use than those old models and getting them up and
running takes a few minutes. When I see how much difficulty and how much
anxiety this new tech is causing people it makes me wonder if the frameworks
are just covering up how easy all this stuff is and how powerful it is.

It's really exciting stuff, it sucks if people are missing that.

~~~
rimliu
Your comment reminds me "how to draw an owl" joke. Yes model is simple. But
the devil is in the details and web has a loooooot of details.

------
raquo
JavaScript is a small language because it needs browser support and backwards
compatibility. A small language that can't change much over time can't afford
to have opinions on how to build dynamic interfaces.

Therefore, all the complexity of building interfaces will be in the libraries
and because opinions on such complex issues vary, there are many libraries to
do the same thing.

Eventually the interior ones are recognized and culled. They typically are
supported for quite some time after becoming uncool, it's just that no one
wants to work with lame, obsolete tehnology for good reasons.

The solution I see to this are compile-to-JS languages that make it possible
to use a different ecosystem of libraries than te JS one, like Scala.js.
However, those tools are also still evolving, so one way or another you're
dealing with a lot of library churn in frontend development right now, so
learn to pick winners and stick to them until it's as weird to use them as
jquery for complex UI was in 2012.

------
sutee
While it's easy to get frustrated especially if you are following each twist
and turn that js takes, I think if you step back a little, you can see things
are getting better as a whole.

For the longest time, js was just a thing I did on weekend or as part of
tertiary projects at work. I first used js as a kid for my geocities page,
used jquery and YUI for a work projects starting about eight years ago,
experimented with Angular, and most recently embraced React and es6.

Almost two years ago, I quit my job and started building a side project in
React and Fluxxor for fun. At this point there were a bunch of Flux
implementations and no dominant library had emerged. I got frustrated with the
build process and then got distracted with other life experiences.

I returned to javascript less than a year later and was amazed at how much
better things got. I could do npm install and npm start and there was a good
chance things would actually work. I was doing the same google searches but
noticed that the documentation was a lot better. I also had a friend this time
around and he steered me toward Redux and es6. Javascript suddenly became an
enjoyable language for me enough that I plan to focus on it. This is after
more than close to twenty years of fits and starts.

------
unclebucknasty
I dunno. I'm starting to wonder if writing disciplined code with jQuery for
support is a better approach than the framework soup we've been dealing with
in recent years. I know, I uttered the "j-word that shalt no longer be spoken"
but that's kinda' my point--what's wrong with writing code anymore?

If you use simple, clean modular coding patterns, componentize for reuse, make
judicious use of promises, and sprinkle in lightweight templating and routing
libraries, etc., you'd effectively have your own mini-framework on which to
continue building. After all, frameworks themselves are code under the covers
--code that encourages patterns.

Sure, some say it's reinventing the wheel to write JS without someone else's
framework. But, it seems to me that the frameworks are re-inventing the wheel.
Not only is there a new one every day, but they are even re-inventing
themselves (I'm looking at you Angular). Looking at the mere scaffolding alone
for some of these frameworks makes me think, "what are we doing to
ourselves?". Generate an "empty" project on some of these guys and prepare to
be overwhelmed with opinionated cruft. Rolling my own code is not reinventing
the wheel, because Angular, et. al. are not the wheels I'd invent in the first
place.

Until a framework comes along that truly abstracts away HTML, CSS, the DOM and
the rest of the old Web, so that it genuinely allows construction of clean
event-driven, componentized _applications_ , I'm not sure I see the benefit of
playing the framework du jour game.

~~~
zer0tonin
>Until a framework comes along that truly abstracts away HTML, CSS, the DOM
and the rest of the old Web, so that it genuinely allows construction of clean
event-driven, componentized applications

So react?

~~~
unclebucknasty
More like Swing.

------
fetbaffe
Frontend development in JavaScript has become a hellhole.

Projects can have three plus build tools that each take a long time. Massive
list of dependencies plus bad dependency management, lack of documentation,
everything changes so fast you need to find the correct stackoverflow answer
for this week solution to your build problems, build tools depends on other
build tools configurations in undocumented ways, reimplementation of the model
& business logic of each project, constantly reinvention of the wheel.

And the end result? Web just becomes slower and slower.

Developers today build software that fits their paradigm, not the users
experience.

~~~
lllr_finger
That last sentence succintly describes my primary issue with front end
developing, and why I'm starting a new job in a few weeks that is almost
purely backend.

Most of my recent web work has been trying to manage shared libs and duct
taping the build process together. Every feature branch has major shrinkwrap
merge conflicts because there is so much module churn.

------
rectangletangle
Man... when it's laid out like that, it does seem a bit insane.

By comparison Python's primary web framework in 2012 was Django, and today it
remains Django. Despite this relatively glacial pace, there's been a ton of
improvement to Django, and the surrounding Python ecosystem. A more
conservative development culture can pay off sometimes, since it allows the
community as a whole to focus on polishing the existing ecosystem. As opposed
to dropping Django when "real time" Websockets were all the rage, there was a
concerted effort to include it in the framework with the Django Channels
project.

~~~
polskibus
Don't forget that move towards microservices and Go caused many Django devs to
move away from it.

~~~
rectangletangle
That's certainly true for that particular niche. However Python has certainly
come into it's own over that timespan, with the rise of various machine
learning approaches. This reinvigoration, seems to have manifested in the web
side of the language too, seeing as many models eventually need some form of
HTTP server.

Admittedly though the community isn't perfect. There was quite a schism over
Python 2 vs 3 for a while. Thankfully it's looking like that may be past us.

Anecdotally the Python community seems more active than ever.

------
manigandham
From the article > _How much has medicine, accounting, politics, law,
construction, or math changed in that time period?_

The webapps that services those industries has changed massively in the past
decade. The web has evolved from simple documents to complex applications. The
browser is the new app delivery platform, and it's perfectly reasonable that
this would bring increased complexity.

Backend development has countless languages, compilers, frameworks,
toolchains, CLIs, OSes, containers, etc. - so it's really not that strange to
see frontend dev catch up.

What's rather amazing is that there's just 1 language with everything else
being frameworks and tools that let you shape it to your needs (and also runs
just as well server-side with nodejs).

------
drumttocs8
Can anyone tell me why I shouldn't still just use standard, ECMAScript, and
(gasp) jQuery? There's so much churn in the JS world, sometimes it makes sense
to just build something, and then optimize it later.

~~~
ElatedOwl
The problem I always have with jQuery is it turns into a maintenance nightmare
(read: spaghetti everywhere) and there's a lot of repetition.

I'm sure there are some people with organized jQuery front ends, but it's way
too easy to have a mismangled giant ball of mud. Going with a framework you
can of course still have a giant ball of mud, but it's a lot harder to get
there. Anything component based is a big step up in organization.

My other big issue is 90% of what I'm doing on the front end is ajax calls and
keeping the UI state up to date. A framework like Vue makes it so trivial.

I sincerely encourage you to give something like Vue a try. You don't have to
adopt it all in, you can use it for just a single on page component and see
how you like it. The getting started guide is great - if you have a solid
understanding of JS you will be up and running in an afternoon.

I was hesitant like you and as soon as I tried Vue I haven't looked back.

~~~
unclebucknasty
What's the best way to manage templates in Vue if you don't want ES6-style
string literals everywhere _and_ you don't want a build step?

~~~
ElatedOwl
You can do script style templates, e.g.

<script type="text/x-template" id="component-name-template"> <div> {{ msg }}
</div> </script>

Then when setting up your component you specify the template property with the
id, e.g.

Vue.component('component-name', { template: '#component-name-template' });

Honestly though this sucks if you plan on reusing components. Can I ask why
you don't want a build step? The single file components are _great_.

~~~
unclebucknasty
Thanks. Yeah, I looked at that option too and agree that it does suck. :)

Just didn't want a build step due to complexity. I know it's not that
difficult, but wanting to keep it as simple as possible.

I don't really get why Vue opted not to support URLs for their templates. It
could be easily managed via co-location of templates with components and/or
naming conventions. You actually wouldn't even need to specify the URL. It
just grabs it from the component's directory by name.

Anyway, for me, this is a weakness. I get that they want to maintain the
single file component model, but I'm not sure it's worth it when your choices
are literals, script templates, or an extra build step. OTOH, co-locating a
dependent file is no biggie, even if you don't get to claim single file
components.

EDIT: I was close to going with Vue for a project a month or so ago. But,
wading into it, I realized the build step would be necessary to do it "right".
Suddenly, you're downloading plugins, xcode, and all kinds of other stuff,
then setting up a build. It just seems a lot for, essentially, single file
templates. Granted, several steps are automated, and you're just issuing npm
commands, etc. But, I started thinking, "do we really want all of this magic?
What if the build just doesn't work one day or we need to reconfigure? Now
we're troubleshooting and figuring out the linkages that were created and the
other magic.

The whole process was a stark reminder that you're in someone else's world.
Maybe I'm too big on control. But, I don't want to be sucked into too many
dependencies.

~~~
ElatedOwl
I absolutely had a lot of the same concerns, and I was just as confused as you
as to why Vue wouldn't support remote url templates.

That said, once I decided to roll with it, it took about a week* to get it
configured how I have it now and have a decent understanding of how/why it was
configured. *not a straight week of banging my head into webpack, but some
bits of time here and there as I did development

The one other thing that kind of pushed me over the fence into going down the
build step route was that I get a minifier, a LINTer and get to use ES2015 (or
typescript, or whatever) syntax.

>"do we really want all of this magic? What if the build just doesn't work one
day or we need to reconfigure? Now we're troubleshooting and figuring out the
linkages that were created and the other magic.

Totally valid concern and I see where you're coming from. Once I got into it,
though, I realized the only webpack specific syntax is the configuration; how
you link your JS files together is just through import/export statements
(ES2015 and beyond module system).

~~~
unclebucknasty
That's good feedback. Yeah, I was really close. As with other frameworks, I do
think Vue surfaces too much "old Web", but I also think it was the cleanest
and simplest of the contenders. I could see it making dev at least somewhat
more enjoyable, organized, and productive.

> _it took about a week to get it configured_

Funny, that's about what I thought it might take--a week of somewhat committed
effort. Felt like we didn't have that to spare though, and wasn't 100% sure
about the ROI on that time. Felt like a roll of the dice.

Now, whether we'd have already recouped that week is an open question, and
setting up a structured JS project was also no small task. But, likewise, we
now have a good pattern/mini-framework with a component inheritance model. So,
we're recouping that investment as I write this., and we're not tied to deep
dependencies or magic.

Next time out, I may have another look at Vue. But, I am really hoping for a
more componentized-event driven model that completely abstracts the old Web.
Even moreso than React, but with more simplicity and only JS or Typescript in
the mix. Kind of a Swing for JS is the best analogy I can make.

------
nice_byte
How do you end up with like six "build systems" for web applications? What
even is there to build? Why can't you concatenate all javascript and run it
through a minifier with a shellscript?

I haven't done webdev since 2010 and now that I look at it, it just seems so
bizzare.

~~~
duval
Yours do that if you want, but then you might have customers using large parts
of the code base that other don't have access to so you want to use code
splitting. You probably have some images and want them to look good on all
screens but also want them to be a small size so you use image srcset but you
need to output 6 images for all the sizes. If you're using svgs you might want
to inline these. I mean it goes on and on really, just look at all the
headings within the webpack docs if you want more insight. I can understand
why it seems crazy and perhaps it is more crazy than I think but if you want
you can just concatenate all the scripts, if you want more bells and whistles
then you can too

~~~
pdkl95
> code splitting

That should only take a few lines in a Makefile.

    
    
        JSTARGETS = foo.js bar.js
        
        build-js: $(JSTARGETS)
        foo.js: foo_main.js lib_a.js lib_b.js
                cat $< > $@
    
        bar.js: bar_main.js lib_a.js lib_x.js lib_y.js
                cat $< > $@
    

With make's builtin topological sort, adding dependency information to control
the order or other unusual build requirements isn't hard to add.

> output 6 images for all the sizes
    
    
        IMAGES=( baz quux )
        IMGSRC=(patsubst %,src/images/%.jpg,$(IMAGES))
    
        IMGSML=(patsubst %,build/images/%-small.jpg,$(IMAGES))
        build/images/%-small.jpg: src/images/%.jpg
                convert $< -resize 25% $@
    
        build-images: $(IMGSML)

~~~
ricardobeat
The main difference is that the JS source is being parsed, and most of the
build steps operate on the AST. This is what allows things like transpiling
modern language features to more broadly supported versions, doing dependency
resolution, pruning, and automatic splitting (imagine your Makefile with 300
js files). Remember that JS does not yet have a built-in module system -
simply pasting source files together means you'll be rolling your own.

~~~
RonanTheGrey
Yep, alot of people forget that - because JS is delivered to the browser and
not preemptively downloaded (or executed in a compiled form on a server),
there's NO opportunity to do things like optimization, tree shaking, etc. that
other JITs do, or compiled languages do.

And the moment you accept that it is necessary (and why wouldn't it be -
languages are for developers, not computers, and that means they by necessity
will include cruft), you require a build system to at the very least, run the
optimizer and minimizer.

It seems like a trivial problem but it isn't. We are long past the days when
JS was only used to make an image blink.

------
vmware505
Why I've never seen any Ember.js dev writing about javascript fatigue? Because
healthy community, matured framework, happy developers never felt that. Ah,
and there are plenty of jobs with much higher salaries.

------
TeMPOraL
> _I’ve only been a full time web developer for the past 5 years. It’s barely
> enough time to start calling myself a “senior” Software Engineer._

Offtopic, but when does one start to be "senior" then? I've been coding for
the past 17 years or so, including about 6 years professionally. Do I get to
be a "senior" dev now? How do I convince my boss?

~~~
RandomInteger4
Ask your boss if you can get a promotion / raise and if they deny you that,
then ask if at the very least you can have a new title, then use that on your
resume for your next job.

------
hugs
Every time I read an article like this I wonder: "Where are all the three.js
users? Am I the only one? And am I the only one not suffering from JS
fatigue?"

------
stanislavb
...and that's why so many devs secretly (or not so secretly) hate JS

------
superasn
I really don't understand this hate for Angular 1. I think till date it is
among one of the best things to happen to the web after jQuery. Yes, I think
jQuery is great and Angular 1 is fantastic for making website super quickly
and maintaining them.

~~~
RonanTheGrey
I can't stand Angular 1 the framework or the language.

I also credit them with promoting modern web development and producing a
realistic expectation that browsers can actually present some really cool,
sophisticated applications. It is largely because of Angular 1 (and other,
less known libraries) that we currently are seeing an explosion of innovation.
I may not have liked the framework, but I cannot deny the incredibly powerful
(and in my estimation, positive) effect it had on the industry.

~~~
superasn
You're right about that.. It's still my favorite framework even though I too
have my pet peeves (no lazy loading, really?).

Anyway, what are you currently using? Why?

------
richardknop
Another option to avoid this JS fatigue is to switch to a different web
development job. Get a job which focuses on backend and APIs.

Or you can even take it further and go focus on more networking / sysadmin /
devops area. Les fatigue there.

------
holydude
My advise is when you care about your "career" stick to the one with the
largest user base (or depending on your location). Learn it, love it, embrace
it. Then experiment with whatever you want to.

------
draw_down
Just a thought, but: you don't have to write JavaScript. There are lots of
other languages than JS, and lots of areas of programming other than the web.
So it's really, really possible to not write JS if you don't want to. Just
think, you could be free! Forever!!!!!

------
Yuioup
I'm curious about the statement "React has become the champion"

I've recently moved from ASP.NET MVC/jQuery to Angular4. I'm extremely happy
with the transition and I intend to stick with Angular. After not worked with
React (yet), what am I missing?

~~~
RonanTheGrey
These days I split my time between React & Angular 4. I love Angular as much
as React. Both very cool platforms to work on, if you are happy there, stick
with it! There are tons of jobs these days on the new Angular.

------
gotofritz
Oh not another one of these

I have "JS Fatigue" fatigue

------
mstijak
I fully agree with the OP. I used Bootstrap/jQuery, Ext JS, D3, Highcharts,
Angular and React. Each of these felt right for a period of time. Now, I'm
using my experience to put the best features of all these into my own
commercial framework called CxJS - [https://cxjs.io/](https://cxjs.io/)

