Ask HN: Tired of trying to catch the JavaScript train | Hacker News Reader

Ask HN: Tired of trying to catch the JavaScript train

21 pointspassy2913 comments

Hi,

Since 4 years, I always tried to be up to date regarding a Javascript framework. Now, I'm really tired. I find that the time spent on learning is not worth the time I spend on projects. I don't know if it'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.

My question is : how do you manage this tiredness ? How do you get over it ?

Regards.

View on HN

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.

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.

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/ 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.

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.

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.

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.

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.

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.

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.

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

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

Elm.

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.

Reply on news.ycombinator.com