
Do Not Follow JavaScript Trends - nikolalsvk
https://pragmaticpineapple.com/do-not-follow-javascript-trends/
======
andrewl-hn
I vividly remember 2016. I was doing backend programming at the time, but no
one I knew were using Angular.js at that time for new codebases.

React emerged in 2013, by 2014 the hype was at full swing, and by 2015 React
"won" the framework battle.

It's been 5+ years since then, and React JavaScript world was remarkably
stable. Fashion changes were largely superficial: React.createClass vs ES
classes, Heavy use of Decorators vs not using them, and now Hooks. These were
mostly cosmetic choices, and if your team picked the wrong side they could
migrate over relatively painlessly or straight up ignore the issues for years.

On the other side of spectrum we have Ember that maintained backward
compatibility and ease of upgrades since ~2013, Angular 2+ is doing the same
for many years, too.

The whole "JavaScript fatigue" meme has to go.

~~~
ehnto
You make it sound like we're all using React and that's all there is to it.
That's not quite true, and it's just one of the choices you have to make. So
you've decided on React, but what about state management, transpilation, do
you use GraphQL? What am I doing for styles, should I write them in Javascript
too now? Oh no! Webpack isn't for me! Can I use modules yet? Ah bugger, we
need SSR, suppose I should have managed state the "Right Way (v28.6)", doh!

~~~
wzy
I even got fatigued reading your list of choices and you even missed critical
choice such as flavor of SSR.

------
mxschumacher
A good way to not be completely overwhelmed by all the new tooling and
frameworks is to have a strong grasp of the fundamentals, here are three
foundational resources:

"You don't know JS": [https://github.com/getify/You-Dont-Know-
JS](https://github.com/getify/You-Dont-Know-JS)

"How browsers work":
[https://www.html5rocks.com/en/tutorials/internals/howbrowser...](https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/)

"High performance browser networking": [https://hpbn.co/](https://hpbn.co/)

~~~
recursivedoubts
Agreed. I think a lot of folks suffer from not understanding how web 1.0
worked and really groking REST/HATEOAS (which has since been hijacked for JSON
APIs, which is complete nonsense.)

Sometimes I jokingly call htmx "web 1.1 tech", but increasingly I wonder if
I'm really joking.

~~~
thanatropism
In 1996-1998 as a teen I "made some websites" for local businesses. The one I
made for my parents even had a search function (in PHP) in a CSV with their
products (which were like 100). The CSV was generated by taking whatever Lotus
Approach (their desktop DB) generated and transforming it with some custom
Haskell code (I was a teen, what did I know). They clicked an icon to pull the
data and another to run a FTP batch file.

Fast forward, I understand _nothing_ of the website being developed in React
for my startup. The othe technical cofounder does grok it, but I could _not_
lend a hand and can barely even supervise the outside help we brought. I like
to think of myself as well-versed in a generalist manner. I can hack a custom
sparse matrix (with a very particular structure I was able to prove an
iteration for) inversion algorithm, but I understand _nothing_ about painting
the background the correct shade of blue!

~~~
recursivedoubts
I have something for you:

[https://htmx.org](https://htmx.org)

~~~
thanatropism
Yow. I have an application growing out of control in Streamlit
([https://streamlit.io](https://streamlit.io)), which is a rshiny-type
interactive dashboard gizmo. I'm now able to consider rewriting it with a
proper front-end.

It's like a whole world I had been sealed off from has reopened.

~~~
randyzwitch
(Note: I'm Head of Developer Relations at Streamlit)

Out of curiosity, which features are you looking for in a "proper" front-end?
Flexibility?

~~~
thanatropism
Streamlit is _magic_ and I don't want this to come off as a dismissal, but it
can be unpredictably unreliable. I keep having this issue if I run > 0.58:

[https://github.com/streamlit/streamlit/issues/1440](https://github.com/streamlit/streamlit/issues/1440)

It's over a month old now, with multiple people reporting the same bug and
iterating on the problem with no apparent narrowing towards a reason for why
this happens, let alone a solution.

~~~
randyzwitch
Thanks for clarifying. Since HN isn't the right place for a detailed
discussion, I would invite you to comment on that issue and try to help us
work through it.

As one of our engineers mentions in the linked issue, this bug is hard to
trigger (as is the nature of many bugs), and she is working on a solution[1].
This issue has also been reported here[2], with the solution of adding
time.sleep(1) inside the loop usually resolving that problem.

[1]
[https://github.com/streamlit/streamlit/pull/1494](https://github.com/streamlit/streamlit/pull/1494)
[2] [https://discuss.streamlit.io/t/displaying-images-from-
opencv...](https://discuss.streamlit.io/t/displaying-images-from-opencv/3014)

~~~
thanatropism
Yeah. What I should have added here, but didn't want to sound brash and rude,
is that Streamlit should focus on having a reliable working product before
spreading out as an org with a Dev Relations department.

I know this is a complicated problem domain ( _because it 's the web_,
Mathematica did this well with complex graphs in the mid-90s), but as it
stands now my project has an input on which the graphic depends and a default
value; the image breaks before the input control is touched. And it's not a
slider, it's a dropdown that makes the app query a db first... I mean, I think
I can do this in plain Ajax if I get my story right about sending images. But
it's a hobby project meant to explore mathematical ideas...

If you can't do sliders reliably, they should be moved to a beta branch.
Streamlit overpromises and underdelivers. But it's a great project, I don't
want to be too negative about it.

~~~
randyzwitch
I see you've both commented here and on GitHub, so I'll make my last comment
here and then we can address the specifics on your ticket (I didn't realize I
referred you to your own GitHub issue).

As I mentioned, there is a pull request already created for this issue; our
head of engineering/founder says its being held up by a lack of tests before
merging. This problem isn't a slider issue, but a race condition in our
session state manager.

Regardless, one month is a pretty trivial amount of time as far as open-source
projects go, as well as in the history of Streamlit (project became public Oct
2019). Like all projects, we try and address things in the order of severity,
and as far as this issue goes, it's a pretty isolated one, not an indication
that the library is unreliable or somehow reflects that our engineers can't
design at an early-90s level of engineering.

------
duxup
I'm a little lost on the examples.

There are reasons to use fetch and hooks, and the article seems to relegate
them to being unnecessary 'trends' without doing what it suggests, actually
evaluating what value they might have...

In React you can use hooks with a class heavy application and still be just
fine / get the benefits of hooks in a given component(s).

If you want to use fetch, that also is hardly an ordeal to do / should not be
a big cognitive load for anyone.

I get it, resume driven development bad, we get it, we hear it in opinion
pieces all the time. Also you should think about it before rewriting an entire
application. Yup, that makes sense.

But here we have examples of small changes that are pretty light weight... and
no effort is made to do exactly what it suggests, evaluate those choices.

~~~
runawaybottle
But do we get it? If we get it, why is frontend churn so prevalent?

I don’t think we get it.

~~~
christophilus
Is front end churn really so prevalent? I hear this opinion all the time, but
React is 7 years old. I've been using it for around 5 years, I think. Redux is
5 years old. How old does the most popular web framework need to be before we
consider it to be low churn?

[Edit: Also, anecdote: before JS, I was mostly a C# developer, and the churn
there was at least as bad, maybe worse in my personal experience. Over 15
years of my career, I had to learn ASP, then ASP.NET, and in the Windows app
world, we went from WinForms to XAML, then .NET Core came out, and things
shifted again... See Rails' history for more examples of churn. It's not like
every other platform is a paragon of stability. Clojure is a bulwark of
stability compared to just about anything else, but it's hardly fair to hold
the front-end community up against that gold standard...]

~~~
quxbar
JS has always been relevant as an ecosystem because it incorporates new ideas.
I liked jQuery more than what came before it, and I like React more than
jQuery. They make the task of translating an idea into a work app much easier
for me, and other programmers I work with also benefit from more readable
code.

I wouldn't re-write an existing app to use fetch or hooks, but now that I've
taken the time to learn, I'm happy I did. The vast majority of the mental work
was done by other people, and I get to reap the benefits. The alternative to
this is stagnation, and relegation to legacy systems... I guess the author
wishes they could work in COBOL?

------
joshribakoff
I find it interesting the blog post mentioned Kent Dodds article recommending
everyone rewrite fetch. I just argued adamantly against Redux docs about
writing tests being switched off of Enzyme to his library because it’s “more
trendy”.

[https://github.com/reduxjs/redux/pull/3708](https://github.com/reduxjs/redux/pull/3708)

Unfortunately, the community overruled me and the docs no longer show how to
test Redux apps with enzyme. It only shows Kent’s “react testing library”. The
library authors are complicit in this. Rather than showing the pros and cons
of both, the trends are being pushed, leading people to falsely believe they
must rewrite their whole code base in my experience.

The troubling part for me is often those creating these trends may be working
on a very different type of app. When you’re writing something complicated,
and the ecosystem is dominated by patterns (also preached by Kent) that work
best in simpler apps like “only write integration tests” it can be
frustrating.

If Kent thought enzyme promoted anti patterns he could have technically made a
docs PR or just written a thin layer on top of enzyme. Now we have yet another
divisive issue. Getting him early access to new react apis and officially
recommending RTL in the react docs (while he sells his training videos) make
it sit worse with me. It doesn’t feel like the trends are always based on the
merits, it feels more like “not invented here” and “nepotism” driving some of
these trends for sure.

~~~
acemarke
As I said in that issue, I'm not completely against having Enzyme info in that
page. However, we're not obligated to have the Redux docs show information on
_every_ other tool that exists in the ecosystem, and our own recommendations
may change over time.

Right now, we have an entire docs page on how to use Immutable.js with Redux
[0]. That page was submitted by a user who cared about Immutable.js. They took
the time and effort to write it, and the information is useful.

However, at this point we now actively recommend _against_ using Immutable.js
[1], and _do_ recommend using Immer [2]. So, that docs page will be removed in
the near future, because it now goes against our recommendations.

As I said in that thread, I personally would not recommend Enzyme at this
point. Doesn't mean it's useless, or that people shouldn't use it at all, but
it's not something I would use or tell people to use. Given the focus of that
specific Redux testing docs page, I also don't see a _need_ to show both
methods at once.

I agree that the ecosystem shouldn't just chase new shiny, but there's also a
lot to be said for actually keeping docs and recommendations up to date. I
understand your concern in this particular case, but it also feels like you're
extrapolating rather broadly from one specific issue.

It's also the case that sometimes creating _new_ tools is the right answer.
Yarn's release forced NPM to wake up from stagnation. There were dozens of
Flux libraries when Redux came out. In the case of RTL, Kent created something
because he saw a need, the community has seen that it's useful, and he's well
within his rights to promote the tool that he created.

[0] [https://redux.js.org/recipes/using-immutablejs-with-
redux](https://redux.js.org/recipes/using-immutablejs-with-redux)

[1] [https://redux.js.org/style-guide/style-guide#use-plain-
javas...](https://redux.js.org/style-guide/style-guide#use-plain-javascript-
objects-for-state)

[2] [https://redux.js.org/style-guide/style-guide#use-immer-
for-w...](https://redux.js.org/style-guide/style-guide#use-immer-for-writing-
immutable-updates)

~~~
joshribakoff
Really all I want is instructions on wrapping the component under test in the
redux provider that don’t presume I’m using Kent’s library. It should show how
to wrap, not how to call RTLs proprietary helper function.

I’m not arguing that you’re violating anyone’s “rights” here, I’m arguing some
of these trends feel like nepotism. The fact Redux and React are seemingly
abandoning official support of Enzyme, after years of recommending it, after
some of its users have written 100s of thousands of tests, is my issue, and I
feel like is directly related the article about "trends" OP posted about.

~~~
mchandler06
You've been on this crusade for over a year. There's a thread on reddit
between you and @acemarke from May 21, 2019 on this exact topic.

In that time, have you stopped to consider that perhaps the incredibly narrow
"legacy maintenance" use case you've been bandying about (which isn't enough
to justify dedicated documentation space in a project that isn't enzyme) and
your overly insulting insinuations about the authors of popular libraries are
not a winning combination?

------
memexy
Shiny new thing (SNT) comes along, sales people and thought leaders get
excited about SNT because they can sell it, everyone piles on as SNT picks up
more and more hype, SNT falls apart as soon as it hits real world use cases,
sales people and thought leaders start looking for new SNT and the cycle
repeats.

I can not stop the cycle. You can not stop the cycle. All we can do is notice
it and let it pass and hope some SNT will eventually be useful instead of pure
hype. Oh, and also, avoid joining any cults:
[https://www.infoworld.com/article/3440104/10-software-
develo...](https://www.infoworld.com/article/3440104/10-software-development-
cults-to-join.html).

~~~
ChrisMarshallNY
That is a great article!

Thanks!

BTW: I did write a bit about this phenomenon, here:
[https://medium.com/chrismarshallny/concrete-
galoshes-a5798a5...](https://medium.com/chrismarshallny/concrete-
galoshes-a5798a55af2a) _(Scroll down to "It's Not An Either/Or Choice")_

------
mxschumacher
From a developer perspective, changes in frontend web development have been
pretty dramatic: CSS Grid / Flexbox, React, WASM, extensions to the web API,
lots of new JS features, countless frameworks, plugins and build tools more
homogeneity between browsers. There is always lots of change and excitement.

I wonder how much of that "innovation" really makes a difference to users. As
a programmer, I get a bit cynical about having 50 ways to do the exact same
thing. What is possible today that was very hard to do 10 years ago in web dev
land?

If we think about users first, maybe we can feel a bit less guilty of not
having deployed React Hooks to prod yet?

~~~
phailhaus
> What is possible today that was very hard to do 10 years ago in web dev
> land?

Declaratively writing components and reusing behavior (e.g., hooks) across
components/applications was basically impossible with the tools of 10 years
ago. The benefit to the user is more stable interfaces and a faster release
rate.

~~~
dahfizz
> benefit to the user is more stable interfaces

Doubt. Websites are _constantly_ redesigning their interfaces so that they can
use the latest trendy technology.

~~~
phailhaus
Is that the fault of the frameworks for existing? That's like saying we'd be
better off if we didn't have so many programming languages.

------
underbluewaters
As a software developer I consider the most important part of my job to be
evaluating new tools and techniques. This craft is in its infancy and our
profession borders on complete incompetence when it comes to predictably
building usable tools at a reasonable budget. Nobody can afford to miss out on
productivity enhancements and that means following trends, but with a critical
eye. If someone is "tired" of this process it might be time to consider
another profession.

~~~
mtts
> As a software developer I consider the most important part of my job to be
> evaluating new tools and techniques.

Really? I would argue it’s building software.

> This craft is in its infancy

We’ve been building software since ... dunno ... 1950s? 1960s?

> our profession borders on complete incompetence when it comes to predictably
> building usable tools at a reasonable budget

This is probably true, but I suspect chasing new tools isn’t the solution.
I’ve seen a lot of very much with it development teams fail at building stuff
because they couldn’t get their shiny new stuff to work predictably.

> If someone is "tired" of this process it might be time to consider another
> profession.

On the front end, yes, it’s probably par for the course. I suspect it’s
because front end development is even more removed from rigorous engineering
practice than back end development.

On the back end, however, lots of stuff is still built in Java and C(++) and
it all works reasonably well.

It’s just not very exciting.

------
furstenheim
The user does care. At a previous company we started migrating from angular to
vue. Vue was so fast that those parts would be completely rendered and the
rest would be white. It was also snappy.

Of course, one has to be mindful about the transition. You cannot stop
business, but you can take a little extra time whenever there's need to modify
a section to improve quality (both code and ui). Actually that's why we chose
vue, it allowed to a progressive migration out of angular.

BTW, someone had the "great" idea of not using a framework for an internal
admin portal. It turned immediately into a huge ball of mud.

~~~
kqr
> BTW, someone had the "great" idea of not using a framework for an internal
> admin portal. It turned immediately into a huge ball of mud.

It's never the case that you "don't use a framework" for something like that.
You'll use a framework, alright. The choice is between using something well-
built based on best practises as we know them, or... building it yourself.
Other than in very rare circumstances, I fail to see the point of reinventing
that wheel. UI frameworks (web front-end or not) are a quagmire of edge cases
and other infinite time sinks.

------
erwinh
On the react bandwagon for almost 5 years now and haven’t regretted it a
single day. Started using it because it allowed me to build d3-type data
visualisations but with way more flexibility in terms of hierarchy and
grouping of DOM elements in what for me felt like a very intuitive format of
components and JSX. So I would say thrust your own judgement when considering
which tools! Not all trends are pure hype, there might be something real
behind it :)

~~~
yen223
In my opinion, React is one of the few libraries out there where the gains
from using it is much larger than the effort needed to learn it. It has a
relatively small API, more so now that you can get a lot done with just
function components. In return, once you grok the whole "components as a
function of state" concept, designing data models and designing app components
becomes very simple.

I really like react, and I'm glad to see other environments adopting a React-
like approach to UI development (Apple's SwiftUI and Android's Jetpack
Compose, to name two)

------
lmilcin
Almost every time it is better to invest in learning your framework well and
learning patterns to work around framework's issues rather than learning a new
framework.

First, it is naive to think the new framework does not have any problems.
Marketing would like you to think everything is perfect but if that ever
happened, why do we have new frameworks all the time?

Second, you will pay with decreased productivity while you are learning the
new framework and you are not guaranteed to be more productive than with the
old framework.

Third, due to decreased initial productivity, even if you potentially get more
productive with new framework, it is going to take time to realize any
benefits. If you are switching the framework too frequently you are cutting
yourself off from the benefits.

~~~
lmilcin
I forgot to mention there is actually one reason to learn new frameworks and
it is to educate yourself on the tools that are available. If you do it
correctly you can get 90% benefits with 10% effort.

Just don't decide to build your new production application with a framework
that you don't know or did little more than hello world.

------
Tade0
I feel like these problems are endemic to React and the surrounding ecosystem.

Since its introduction in late 2016 Angular 2+ has had no major changes on the
scale of hooks and is unlikely to introduce them, because its target audience
- large companies making large-scale applications is fairly conservative.

Vue I think had one measurably large syntax shift around v2.5(or 2.6) and will
have another one with 3.0, but that's about it.

Meanwhile in React every year there's this new convention that isn't
explicitly mandatory, but for some reason "cooler" than the previous one.

All this won't matter once the next gen compiler-frameworks reach maturity. My
take is that hooks are React's swan song.

~~~
mark_and_sweep
> Since its introduction in late 2016 Angular 2+ has had no major changes

As someone who has used Angular 2 since beta, I can tell you, it's been a
bumpy ride nonetheless.

> its target audience - large companies making large-scale applications - is
> fairly conservative

React was built for Facebook, which is a large company building a large-scale
application.

> All this won't matter once the next gen compiler-frameworks reach maturity.

And here I am using HTML and CSS with tiny sprinkles of JS for most websites,
and it's working just fine, and has been for many years.

Personally, I hope that server-side rendering will be the new ~old~ trend.

~~~
Tade0
> As someone who has used Angular 2 since beta, I can tell you, it's been a
> bumpy ride nonetheless.

Oh yeah. I remember the "let's just apply the good parts of AngularJS here and
there" in v4-6.

"React was built for Facebook, which is a large company building a large-scale
application."

 _One_ large scale application, which is not enough to create stable
conventions that are badly needed in a framework that's supposed to be used in
multiple such projects done by very different organisations.

 _Personally, I hope that server-side rendering will be the new ~old~ trend._

Users don't tolerate the inherent delays caused by this approach anymore.

All those hoops current frameworks are jumping through so that we can eat the
cake and have it too are there because of this.

~~~
yxhuvud
> Users don't tolerate the inherent delays caused by this approach anymore.

Well, I certainly also do not tolerate the delays in contemporary React sites
either. Take Reddit for example, which used to be lightning fast when it was
mostly serverside, which now is painfully slow, especially on mobile.

~~~
tfleming
Yep, I agree. Was just talking to my wife about Reddit. It's so slow now,
especially on mobile. The page constantly crashes on my Android phone and they
always recommend the app. No thanks.

~~~
nefitty
Today is the day I decided to switch to old reddit... My Mac can run
garageband and vsc and 40 chrome tabs at once, but as soon as I click a front
page Reddit link, that modal is like pouring sludge into my computer.

------
ChrisMarshallNY
Not just JS. JS is an enormous ecosystem, so it shows this issue, but pretty
much all tech (and other industries, as well), have the same problems.

We can have problems when folks start suddenly painting "The New Thing™" over
classic designs and architectures.

In my experience, that's even worse than rewriting everything.

Also, it can become a requirement for hiring, because some manager, or their
"top tech," have suddenly latched onto a technique/technology they encountered
at a conference.

I remember applying at a company, and they gave me a "take-home" test.

Fair 'nuff. I like these better than the silly "draw spunky" tests that are so
_en vogue_ , these days.

They said I needed to use a certain third-party library, and use MVVM, or PM.
That made no sense to me. It would result in the dependency being "married" to
the application.

In my response, I used dependency injection to add the third-party library
they wanted me to use. I wrote the app in about three hours, and incorporated
the library (which is a great library, but one I had never used before). I
delivered an app that met their specs -very quickly-, and of remarkably high
quality. It also featured the ability to easily "swap out" the dependency
(which is a huge reason for using dependency injection).

Dependency Injection is not a new thing. I think the name may be a bit new,
but it's a fairly classic pattern that is a great way to encapsulate
dependencies (which is something I always do).

It Freaked. Them. Out. I have no idea why. They literally shredded my résumé,
at that point.

I have my suspicions why. I think they found out something else about me
during the process (my age), and that may have been a contributing factor.

~~~
memexy
I once worked with a group of people that were afraid of makefiles. I doubt it
was your age. People are always afraid of things that are unfamiliar. This
applies to snakes and spiders just as much as it applies to programming
languages and associated technologies.

~~~
ChrisMarshallNY
_> I doubt it was your age._

Wish I could share your confidence, but I have run face-first into this
phenomenon.

 _[...removed some stuff that I don 't feel like backing up...]_

We are an unpopular bunch. It used to get me quite upset, but I’ve learned to
make it quite clear that I am no youngster; right up front. Avoids stuff like
what I mentioned.

~~~
memexy
Really? Do you have specific examples. In my experience hacker news tends to
be much more friendly and sympathetic towards older programmers.

~~~
ChrisMarshallNY
I'll withdraw the post (rather than spend a bunch of time, hunting down
comments that just get me depressed), but the tide may be turning.

Now that the VC money may not be as easy to get as it once was, there may be a
bit of a demand for software that _ships_ , as opposed to glossy slide decks.

Us old farts ain't so bad at that.

~~~
memexy
Indeed. Focus on fundamentals never hurts.

------
wereHamster
Let me make the argument against axios.

Even if you are happy, your users may not. Axios (btw still on version 0.x
despite being one of the older javascript packages, means it can introduce
breaking changes without any warning, think about that) adds 4.4kB
(minified+gzipped) to your bundle. Do that a few times and you have hundreds
of kB of additional code your users don't need to download (and execute!). If
all you need to GET or POST, without any special needs, the w3c fetch function
is definitely better for your users.

~~~
heipei
My argument for using axios is developer ergonomics. There are a few libraries
that I use both in the frontend and the backend, for which I gladly accept the
increased bundle size: axios, lodash, moment, Q. My users get the benefit in
me being able to ship features faster because I don't have to constantly keep
up with which feature ships in which browser version etc. I also found the
fetch API horrendous to use. It's a tradeoff I'm willing to make.

~~~
whycombagator
Do you take on the entire of Lodash as a dependency?

If so, do you use any of the Lodash features not described here?[0]

If you use more than described, or if a specific Lodash feature is more
performant, you can selectively import[1].

[0] [https://github.com/you-dont-need/You-Dont-Need-Lodash-
Unders...](https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore)

[1] [https://www.npmjs.com/search?q=keywords:lodash-
modularized](https://www.npmjs.com/search?q=keywords:lodash-modularized)

------
ctvo
No one I know has moved away from React as the base of their front-end UI for
the last three years.

Maybe I'm out of touch? It doesn't seem like the churn is as much of an issue.

------
gitgud
The underlying problems are mainly psychological in my opinion. FOMO (fear of
missing out) and attaching your identity to a language or tech stack.

People get so religiously tied to their technology sometimes that they cannot
change without changing themselves.

It's the same case with the fractured ecosystem of Linux distros, there's
tonnes of them! From the outside it looks overwhelming as all these projects
are concurrently developing similar things. But the benefits are a rich and
diverse ecosystem meeting a range of needs.

Imagine if everyone used one language like Java and never created new
packages... and simply maintained existing libraries... that's not a world I'd
like developing in...

------
chadcmulligan
I agree totally with this - but if you want to get a new job, you have no
choice but to follow the latest javascript framework, because thats who's
hiring. They want to build their new doodad in the latest doodad - react, Vue,
...., because thats what their google turned up thats the latest and greatest.

Further if you're looking at getting your next job, you'll make your next
project using the latest doodad, because thats who's hiring when you finish
this project (as long as your project doesn't take to long and you miss the
boat - you can probably quit midway, I suppose)

------
recursivedoubts
Javascript has always gone through hype cycles.

Interestingly, it appears to be somewhat correlated with market manias and
peaks near the tops of markets.

Generally, following industry trends appears to be good for individual careers
but bad for code bases (on average, but with occasional big payoffs.)

~~~
User23
Since I own my career but signed away all rights to the code I write as a
condition of employment I'm OK with this trade-off.

------
tsdlts
Agreed entirely. Now all you have to do is convince my team of this without
being bombarded with the platitude of "don't reinvent the wheel."

------
jaeming
Have followed the trends and I now know Ember, Angular(both legacy and new),
Vue(with and without typescript), and React(both classes and hooks). I've also
used Svelte, and Stencil JS in my personal projects. In addition, I've also
dived headfirst into GraphQL and Typescript pretty heavily lately.

Do I regret investing time in learning any of those frameworks or
technologies?

Not at all. It was fun and interesting at the time I learned something
different from each of them. Perhaps the most valuable thing I learned was
that it is worthwhile to evaluate new technologies and to continue learning
new things.

Does it devalue me as an Engineer to learn many things as opposed to becoming
an expert in a single tech stack?

Much the opposite. A lot of the underlying principles and architecture remain
the same and yet, I find each framework offers something new. Whether it's
questioning some convention, or approaching a problem with a different
paradigm, or just being heavily opinionated, I feel like I gained some value
from each of these and had fun while doing so.

~~~
koheripbal
The downside probably being that an employer paid you during that time of
learning and didn't get much work product out of it.

Learning for the sake of learning is an infinite endeavour.

I try to practice strategic learning - learning skills/frameworks/topics that
will have a high likelihood of being used in the course of my _current_
project.

There's just so so much out there... focus is everything.

~~~
jaeming
I am actually paid by my employer to do 5 hours of training per week. It's
required and I am allowed to study anything I want, whether it's a new
framework or a self-improvement book.

I usually spend that time studying something that I think may be useful or
related to my job but I have been encouraged to explore. My employer is a big
believer that innovation comes from exploration.

As you pointed out, it is an infinite endeavor. I'm okay with that. If I just
stuck with the current technologies that were used when I first came in, we'd
probably still be using jQuery and .ERB templates. Instead I personally pushed
for using new technologies and my team is personally responsible for
introducing Vue, Typescript, and GraphQL to our stack among other
technologies.

------
dpix
One problem I have with that hype cycle diagram is that it appears to show
that all technologies that get a lot of hype will eventually even out and get
good adoption once they go through some growing pains.

Realistically though a lot of new tech will get into the hype stage and then
everyone will realise that is in fact no good or just disappear for some other
reason.

People see that diagram and think it doesn't matter if you jump in at the hype
stage because _eventually_ this tech will become mainstream, when a lot of the
time that graph just drops to zero after the hype stage.

------
codingdave
Agreed. I approach it more from a "Draw a line in the sand" perspective.

We start a project, pick our stack, pick framework versions and features to
use. And then we code for a year using those decisions. We do watch to see
what new things come up over the course of a year. We also learn lessons from
our choices. When our year is over, we talk about new things, evaluate them,
decide what we want to adopt, and move the line in the sand to include the
changes that make sense. Then... for another year, stay where we are.

------
WA
One thing that is, unfortunately, a bit neglected in the post: dependencies
deprecate and JS has a lot of them.

One npm audit shows a lot of vulnerabilities for the long trail of
dependencies in my Angular 4 app. My web app uses Hapi 17 and many plugins
have changed APIs in the more recent version.

This fact alone leads to many heavy refactorings and even rewrites.

As a solo dev, I can only try to reduce dependencies (taking a massive hit on
productivity) or keep up with the newest way to write stuff in my former
self’s framework of choice.

------
DoubleGlazing
This lustrates a problem I've encountered on a few recent projects - we are
suffering an embarrassment of riches when it comes to front end technology.

I found myself slipping in the architect role on a few recent projects with
various employers and being forced to make the call on which front end
framework to use. The problem is that there are so many to choose from and it
very hard to predict what you will need in terms of features from your chosen
framework six months or longer after making your decision.

Plus, your fellow devs will probably be arguing with you over which one is
better based on their experience. All the emails and messages pointing me to
various websites claiming React/Vue/Angular etc is best with stats and graphs
I really don't have to the time to get my head around.

It's that fear of making the wrong choice that bothers me. The idea a year
down the line the front end seems a bit sluggish and someone then points out
that {other_framework} would be flying with the same workload.

Don't get me wrong choice is good, but with so much going on in the world of
front-end right now coupled with all the hype and shouts about which is best
it is hard to just pick one and run with it. Especially in the metric driven
world we live in where a manager who doesn't get tech will berate you for
choosing the wrong framework or wonder why you aren't buying in the latest
hyped up framework.

That being said my preference is to use a framework to prototype and then
convert to plain old JS where possible.

------
sdfhbdf
I think Software Engineers' role is to pick the right tool for the job -
taking into account all the advantages and drawbacks of each one. Following
the trends is a good way of knowing if any of the drawbacks of the previous
tools were alleviated in the new ones. Of course the refactoring time must
also be a deciding factor in a switch - most of the times it won't be worth
it. I think what the author meant was don't follow the JS treds _blindly_.

------
Aissen
Let's reverse the question: if you didn't follow the trends, were a decision
maker, and wanted to bet on a frontend "framework" for the next 10+ years for
a greenfield (or full rewrite) project. What would you chose in 2020 ?

From where I stand, it seems vue or react aren't going away anytime soon. But
the same could be said of angular, ember, and probably many others. What would
you chose and why ?

------
diffrinse
The problem to me isn't so much hype trains for this or that framework but
that, as a Front-Ender myself, many Front-End Devs don't know how to do
anything without a framework; the person I report to, the Front-End Manager,
had been mucking about with jQuery for 15 years straight and didn't know about
CSS animations.

I was able to work alongside a very saavy consultant for a year when I started
out who I feel pointed me in the right direction wrt coding 'from the problem
itself', if you will, but they'd have me do interviews and I'd be astounded at
what applicants didn't know or grasp who'd been doin this front-end thing much
longer than I.

If there were better solution design pedagogy instead of React's original
marketing of "We know better about efficient DOM updates than you" I think
you'd see substantially less reliance on these types of things, and probably a
lot less unmaintainable code disguised as maintainable because it uses "a
framework".

------
k__
I'm teaching frontend development to designers right now and after almost a
semester, I have the feeling I have to cut out much more concepts.

There are just too many ways to do things to teach a beginner in one semester
and they just should be able to create basic prototypes anyway.

~~~
itronitron
Serious question, why do they need to know anything about creating prototypes?

~~~
k__
The argumentation went like:

We did design projects for companies and showed them our ideas as mock images
and they didn't like them.

We then implemented the exact same designs as prototypical apps, they clicked
around in it and loved it.

~~~
robjan
You can mock user interactions in Sketch and Figma.

~~~
k__
I don't use these apps.

It were design teachers that hired me, so I guess they knew and still wanted
their students to learn a bit programming.

------
dpweb
I think either vanilla js, or the other route, a full blown batteries
included, like Visual Basic 6 was for windows development. Either abstract
away nothing, or everything.

In the middle, is developing with a framework. The problem is you have to know
the language + the peculiarities of the framework. New frameworks and
"features" happen on too short a timeframe. And, frankly, it costs too little
to just invent a new framework. So, 10000 frameworks.

There is a mental cost that increases exponentially with every layer of
abstraction. When people have to post questions about why they can't
understand such "features" of panacea x , that's the problem.

~~~
worik
Been a while for me, but I agree

But when I spent a year doing Javascript I found that in JQuery there were a
lot of shortcuts I was writing my self to lower the RSI from typing long
Javascript statements.

Beyond that there is nothing useful in JS frame works. They make simple things
easy and the complicated stuff (which is design and logic) stays hard.

------
thesuitonym
I just wish more developers would stop trying to improve their products by
chasing the newest, coolest standard, and instead work on fixing bugs. But
that's not en vogue these days.

------
seph-reed
I don't use frameworks, and have found more efficient, better organized, more
native ways of doing everything that frameworks do.

It took a lot of time and effort and being a stick in the mud, but the trick
was ultimately an algorithm/abstraction I call source derivation (SDx).

Here's a simple example of the algorithm:
[https://codepen.io/SephReed/pen/gOaeQLv](https://codepen.io/SephReed/pen/gOaeQLv)

------
nsonha
Unfortunately we work with others and sometimes powerless in this. I worked in
2 front-end teams both using redux inherited from the early stage of the
projects. In both cases the marority of the team don't like it but we're too
deep in it to get out without affecting our roadmap. Another case I had to
talk a college into not using graphql just because he could, felt like a jerk.

------
dilandau
I remember having a coworker who was "learning clojure". That guy did more
damage than could even be imagined.

------
atum47
this is a fight a developer alone cannot win. my first job after college was
in a company that created a software to manage industrial production. they
were on their third refactor of their frontend. first was polymer?, then
angular and now they were trying vue. I spent a lot of time and energy trying
to convince them to write they own framework, if they like frameworks so bad.
funny story, that's how I built FOS, the framework I use on my website.
anyway, I was hired by some other company and don't know the end of the story
there, but I'll bet they went with vue, just to rewrite the whole thing in
react in a couple of months

------
mattwad
I recently started a new app using Material UI, after doing web dev since pre-
CSS days. I'm trying to grok CSS-in-JS, and it's only been a few weeks but it
still feels so completely unneccessary.

------
jchook
tl;dr: use TypeScript, but don't worry so much about hooks.

\---

I recently switched my JS + PureComponent mobile app to TypeScript and FC
Hooks. I felt motivated to do so because:

\- You cannot use hooks in PureComponent render(). The two modalities do not
play nice together.

\- Many of the libraries I use like react-spring and react-navigation have
fully embraced hooks, sometimes without an HOC equivalent. So I felt forced to
also embrace hooks or write complicated wrappers to facilitate them, for
example new component lifecycle methods (e.g. componentDidFocus).

Some things I noticed...

1\. TypeScript is amazing. Combined with Intellisense it has given me coding
superpowers. I can write code faster and with dramatically more confidence.

2\. You can incrementally shift your JS app to use TypeScript. You can even
write type declarations for your JS code without rewriting it in TS. Most of
your favorite libraries already have such type definitions (see
DefinitelyTyped).

3\. Hooks require a significantly different mental model than PureComponent.
It feels horribly wasteful at first but apparently relies heavily on JS
interpreter optimizations and memoization to achieve superior FMP
performance[1]. My app feels noticeably snappier now, but it took a good bit
of tuning to correct issues introduced during the port.

4\. It IS indeed possible to write a functional wrapper that provides
otherwise unavailable hook support for your Component or PureComponent. The
tricky part is that you need to use a ref to invoke lifecycle methods on your
wrapped component[2].

In retrospect I think I would recommend _against_ porting an existing React
project to hooks. However I would absolutely recommend porting to TypeScript,
even if you do so slowly and incrementally.

1\. [https://medium.com/@dan_abramov/this-benchmark-is-indeed-
fla...](https://medium.com/@dan_abramov/this-benchmark-is-indeed-
flawed-c3d6b5b6f97f)

2\. [https://medium.com/reactnative/custom-lifecycle-methods-
in-r...](https://medium.com/reactnative/custom-lifecycle-methods-in-react-
native-f84c7257eaa6)

~~~
BossingAround
I was initially kind of worried about TS. It has kind of a high barrier to
entry with linter settings, typescript-specific setting, solving how to
compile your code easily, learning the new syntax, etc. etc.

I literally spent like an hour reading up on it and learning it, and I
realized I never want to go back to a plain old JS. TS feels way closer to
Java than to JavaScript, with its own quirks and way of functioning of course.
The barrier of entry seems perceived, but not really that big of a deal.

I wonder what are the cons of TS.

~~~
reificator
> _TS feels way closer to Java than to JavaScript_

You and I clearly have different understandings of Java, JS, and/or TS.
Typescript's structural typing feels like the opposite end of the spectrum
from Java's nominal types.

~~~
BossingAround
> Typescript's structural typing feels like the opposite end of the spectrum
> from Java's nominal types.

Be that as it may, I said nothing about type systems. I said that TS feels
closer to Java than it does to JS. Seeing as JS has no type system, I fail to
see your argument.

~~~
reificator
> _Be that as it may, I said nothing about type systems._

Typescript is nothing more and nothing less than a language that adds static
typing to Javascript. Any discussion about how Typescript changes the feel of
Javascript is a discussion about type systems.

> _Seeing as JS has no type system, I fail to see your argument._

Javascript absolutely has a type system. It's not static, and there are lots
and lots and lots and frankly too many ways to automatically coerce types, but
it definitely has a type system.

------
darepublic
I remember 2016 as the year my peers started telling me that jquery was evil.
Also a year of switching from angular to React/redux

------
jaquers
Didn't read. Follow JavaScript trends that make sense for you and your team.
Ignore the noise, get shit done.

You know what I hate more than "JS fatigue" \- it's ppl complaining about "JS
fatigue". Software evolves, and I'm always looking to bring a better
experience for my users - and then means replacing components sometimes when
there are clearly better alternatives, whether that is for developer
experience, smaller bundle sizes, etc.

~~~
worik
Depends if you want your code to be maintainable into the future with other
teams.

If you do not care about the future (which os OK in some contexts) then you
are correct

------
mot0rola
Stay curious, try new things! Party of being a developer is exploration and
discovery. Do not discourage!

------
awirth
Some days I miss using prototype.js and script.aculo.us

------
pldr1234
Article very empty of any real, tangible advice.

------
nsonha
What do these have to do with managing fads?

------
0az
A while back, I got tired of dealing with the mess of Gatsby, Next.js, and
Vuepress, so I made my own static site generator in Python.

I don't want a GraphQL database for my static site. I just want something to
template out my site's boilerplate, and I don't want to deal with Webpack
speed, or lack thereof. One file, ~200 loc, and I understand all of it.

The tentatively named Zhi works fast enough for full rebuilds triggered by
fswatch. It does one thing and does it well:

    
    
      fswatch -0 -e .venv -e out . | xargs -0 zhi build
    

If there's interest in a simple, understandable Jinja-based static site
generator, I can clean it up and release it:
[https://github.com/0az/zhi](https://github.com/0az/zhi) (empty repo).

~~~
BossingAround
If you didn't like Gatsby, why not simply use one of the tens of simpler
static generators? Hugo is extremely popular, but also just Jekyll or
something similar. You won't understand the whole codebase, most likely, but
on a user level, it's literally just a "put a markdown file in this directory"
type of a thing for most of these generators...

