
Ask HN: Tired of trying to catch the JavaScript train - passy29
Hi,<p>Since 4 years, I always tried to be up to date regarding a Javascript framework. Now, I&#x27;m really tired.
I find that the time spent on learning is not worth the time I spend on projects. 
I don&#x27;t know if it&#x27;s specific to the Javascript world, but I find that it moves very fast. Too fast.
The problem is not with the language itself, but more with the frameworks and tooling.<p>My question is : how do you manage this tiredness ? How do you get over it ?<p>Regards.
======
bbcbasic
If this is for your job (and you are not a consulant chaning client every
week) then they probably stick with the same frameworks for a long time, so
just get to know those and ignore the rest.

If it is for a side project just use whatever you find comfortable. You don't
have to learn them all.

E.g. for a side project just use vanilla JS, script tags (not NPM, Webpack
etc.) and maybe a view framework, maybe JQuery and that'll probably sort you
out. Then focus on building stuff rather than learning new frameworks.

------
mbrock
Do you really need to "keep up" with whatever changes are happening?

Are you using frameworks to solve your problems or are you learning about them
because of some vague idea that you should?

I start my JavaScript projects with just an index.js and no dependencies and
take it from there.

If I turn out to need some actual complex UI updating stuff, I'll throw in
React and use it in the simplest way I can.

------
itamarst
What are your goals?

* If your goal is making money, find something that is longer lasting in terms of employer demand.

* If your goal is technical challenge, maybe switch to a different tech stack. E.g. start moving into other parts of web stack (see [https://codewithoutrules.com/2016/04/27/which-technology/](https://codewithoutrules.com/2016/04/27/which-technology/) for ideas).

* If your goal is using all the cool new technology, maybe it's time to pick a new goal that is less frustrating. Or, perhaps, a more stable tech stack than front-end web.

------
rpeden
It helps to take a step back and see that the JS ecosystem is a bit crazy
right now, but it is quickly becoming more sane and more mature.

For a long time, the tooling available for building complex JavaScript
applications was limited. Unless you were Google; the Closure library and
Closure Compiler provided tools for building large, complex JavaScript apps
long before the current JS ecosystem got up to speed. But they were relatively
difficult to learn, and the available documentation wasn't great.

Right now, the JS ecosystem is rapidly relearning and iterating on ideas and
concepts that other language communities learned long ago. This isn't all bad,
as the JS community _does_ appear to be converging on a decent set of best
practices. I've seen a lot of interested in code optimization, and reduction
in the size of JS bundles sent across the wire to browsers. Rollup does a nice
job here, and I've seen a renewed interest in the Closure Compiler - there's a
Webpack plugin for it that does a good job of intergrating it into the JS
build process.

I understand your frustration, though; if possible, maybe try not to worry
about keeping up for now. Just use JS in a way that works for you, and in a
year or two, check back in to see how things are going at the leading edge of
the JS community. I can't say for sure, but I believe the pace of change will
slow down a bit, and converge around a few major tools and frameworks.

------
douche
I don't think you can do it. Just pick what you actually work with, and try to
stay up on that.

Someday, maybe, the churn will slow down. But I wouldn't bet on it. Just about
the time JS settles down, WebAssembly will be finalized, and there will be a
Cambrian explosion of new frameworks, as developers are freed from the
shackles of JavaScript on the front-end and can use better languages. Once
again, it will take years for a consensus on best practices to emerge, and a
thousand flowers will bloom in the meantime.

------
eiriklv
Take a step back and focus on JavaScript the language. Really learn how things
work. Then take a step even further back. Learn more about data structures,
about abstractions and how to think declaratively vs. imperatively. Rinse and
repeat for the rest of the stack.

That way you'll have a solid foundation to build on top of. At some point
you'll start to see patterns, and that all the "new" things are just
incrementally improved materializations of patterns and concepts that have
existed since way before the web was even thought of.

Spend most of your learning/experimenting time on fundamentals (timeless).
Learn actual implementations and specifics when you need to, just in time.
Avoid learning specifics (lib/fw) just in case.

Source: My own personal experience + the very insightful experience of
teaching classes in JavaScript and React the last two years.

------
wayn3
Just ignore this JS nonsense until it consolidates. If you build something
with it, pick a framework and use that. If you do not, why even bother?

Here's some truth.. if you're somewhat good with math, have a couple years of
experience and have built real things, nobody is going to "not hire" you
because you don't know the flavor of the month crap. Its going to change
anyway. Because its flavor of the month crap.

Don't act as if you couldn't pick up react in a week if it was a job
requirement, because that's how easy it is.

Spend your time on picking up a new paradigm. Never did functional
programming? Learn some Elixir or Haskell. A lot more bang for your time than
js framework #317 that is oh so much better than #316 until next month when
there's another paradigm breaking framework that really just reduces syntax by
a keyword.

------
edblarney
It is more specific to the JS landscape than others.

That said - once you do 'catch up' \- staying on top should not be so
absolutely hard - you need to pick and chose your battles.

Node.js is probably something you need to learn.

Most other frameworks ... you can wait until they are popular, but then you
should toy with them.

Once you get used to the concept, learning new one's won't be that-that hard.

You don't need to an expert in any of them - very few people are.

------
godmodus
since you've amassed so much JS experience, why not go into the stack, stop
chasing the newest EMS standard and just put a product together using the MEAN
stack?

time to settle, start earning, and slowly tweak/hone your skills.

edit; mind you, i see it all around me, how chasing the newest fad keeps many
of my friends from doing anything. while me and my good ol` _linux skills_
just picked up vagrant and will hopefully be doing DevOps stuffs. I use
whatever i need to get jobs done - Bash? no problem! JS? sure thing. Php?
Python? some ambiguous framework? give me a couple of days to read up and it's
done.

to quote Voltaire; ""A good plan violently executed today is far and away
better than a perfect plan next week.""

just be a problem solver, and use your know-how and ability to learn as a tool
to fix/do things. chasing dragons is often detrimental to growth.

------
kaonashi
Know enough about programming that learning the n+1th framework isn't a
particularly high bar to cross.

------
Matachines
Move to backend or another domain entirely like smart developers do.

------
lgas
Elm.

~~~
bbcbasic
Given the OP concerns I don't think Elm is the way to go. It is a very cool
language and might be the future of web development BUT to get anything done
requires mastering functional programming, the Elm way, the Elm FFI.

You can't (AFAIK) just drop in a Calendar control or whatever from the outside
world, because the virtual DOM only allows Elm virtual-dom children. So you
have to use the one calendar control in the libraries and hope that is good
enough.

Then the embedding controls story is not mature enough IMO. Lots of
boilerplate to bubble around the messages. Changing page on a calendar
control? Yes your global state needs to deal with it. Maybe not directly know
about it but some plumbing needs to be in place.

I'd recommend Elm for those diehard enough to keep at it despite the quirks
but not for someone who is tired of all this learning new stuff in the JS
world.

