I learnt a lot from the article Modern JavaScript Explained For Dinosaurs[0] (featured on HN recently), which explains the history of developments from vanilla JS to 2017, "a historical context of how JavaScript tools have evolved to what they are today". I thought it was brilliant at making sense of the jungle you describe.

I'm pretty sure it will remove the dread.

[0] https://medium.com/the-node-js-collection/modern-javascript-...

Thank you for this, this is fantastic. Exactly what I was looking for (not a dinosaur, just a back-end dev who's curious about a lot of front-end tech).

Thanks for this, that was actually very clear and informative.

This was a good article

Thanks.The article is very helpful.

The official React tutorial starts you out by installing create-react-app. I know that vue has something similar and I wouldn't be surprised if others did as well (are there even other important front-end frameworks besides React/Angular/Vue at the moment?)

https://reactjs.org/tutorial/tutorial.html

This allow you to start off with a great setup and skip the configuration so you can get started with just writing React. I highly suggest starting with official docs before writing these off. A lot of other tutorials are of varying quality but you can trust the official docs for sure until you learn more about the community and which resources are worth it (or just use this https://github.com/markerikson/react-redux-links). It can be overwhelming if you aren't actively following the front-end world but the reality is that you need very little node knowledge and can go a very long way without ever touching webpack + babel. Even then, once you get to the point, learning to configure those things won't take much time and to me, it's worth it for the developer experience.

If you really want to dabble in just writing React code, you can also try these browser IDEs if they float your boat.

https://codesandbox.io/ https://stackblitz.com/

Case in point: Vue does have a vue-cli which is similar to create-react-app in intent.

However, official vue guide starts with simple examples and jsfiddle[0]

[0] https://vuejs.org/v2/guide/

The "Quick Start" section of React docs that introduces concepts one by one uses CodePen which is similar in spirit to JSFiddle.

https://reactjs.org/docs/hello-world.html

I could have written this myself. I did a lot of web development before JavaScript exploded and have since done mostly back end work. Every time I hype myself up to learn any of this stuff I feel like I'm chasing my tail.

"Wait, I can't learn this until I understand that, but that requires some knowledge of that other thing which is best understood in the context of..." It's exhausting. I have written code professionally in a dozen languages or more on projects ranging in size and scope, but I have never felt so lost as when trying to learn the labryinth that is the JavaScript ecosystem.

I come from backend programming experience with a little bit of jQuery and Bootstrap experience.

I run into similar experience when trying to learn new JavaScript frameworks. Documentation for these frameworks is usually written as if you already are expert in another JavaScript framework. And then it is really hard to understand benefits of tooling they have. I could do simple apps or tutorials but trying to use any of these technologies in a real project is such a hassle that I end up using good ole jQuery. Sometimes, i feel like these frameworks and their extra tools have no real purpose but to help one pad their resume.

Only reason I keep diving into these frameworks is because I worry that if i don’t learn new technologies, I ll be outdated soon.

From what I see, we are moving away from a heavy server which does the heavy lifting to thin server layers that just send data and feature rich UIs that process the data. This is possibly because the browser has become a widespread means of distributing general software.

As a result, the domain of "backend" engineering has bled into the frontend and thus frontend engineering has gotten more complex.

If you purely want to learn React in a way that allows you to do some light modification of an existing architecture then something like create-react-app or some browser codepens will be the best way to get involved with the library.

Otherwise, if you want to understand React from a more fundamental sense, going away and doing some backend courses or learning some basic CS and/or FP architecture may serve you well in understanding the paradigms that inform React's design. As a bonus, these skills will never be useless.

As for JS tooling, it's not ideal and is definitely a lot to learn all at once. Your best bet is to abstract over as much as possible and learn only what you need to when you have to. Though, again, the skill of picking up and using new tools is a valuable one in this line of work.

Thanks for articulating this in an intuitive manner for us non devs.

If you want to learn Vue, here's a great 3 hour starter that doesn't use any fancy setup - just specifically about Vue:

1. https://www.youtube.com/watch?v=utJGnK9D_UQ

2. https://www.youtube.com/watch?v=ulHt78ad890

3. https://www.youtube.com/watch?v=ez0y_XKtEIc

Yeah, In my day to day work I do a little bit more than the OP and know some react/webpack and such.

But the last time I needed something a little complicated I ended up using VueJS. If you don't want to do it the "right" way (ie, a whole build system and such) you can just toss the file onto the page with a script tag and get to work with your scripting wherever you feel good about doing that.

> If you don't want to do it the "right" way (ie, a whole build system and such) you can just toss the file onto the page with a script tag and get to work with your scripting wherever you feel good about doing that.

The "wrong" way, in this case, is not only the "right" way, but the only way. Any javascript framework, no matter how esoteric or abstract, has to wind up generating one or more javascript files to be called by script tags in an HTML document.

And any framework that recognizes this and just tells me up front where a prebuilt script is that I can just include and use is a plus in my book.

While it seems kind of pedantic, I take your point.

And I agree with your assertion that it's nice to be able to shove a pre-built script somewhere... but I've been working on toy react/redux apps and I feel like no, that would miss the point of the tooling and workflow that I want to learn.

Same. Recently I had to do some web work and it is so daunting. Any tutorial for a given technology asks you to use a bunch of other tooling dependency that you don't understand. It's just mixed up dependencies everywhere even for little example projects.

Something like create-react-app that is supposed to help you learn react. Set it up and just look at node_modules. Just a shit ton of dependencies and you have no idea what any of them do. All this sort of scaffolding set up that you're supposed to ignore.

I just can't learn that way.

> Set it up and just look at node_modules. Just a shit ton of dependencies and you have no idea what any of them do. All this sort of scaffolding set up that you're supposed to ignore.

Yeah, good luck going through legal/license compliance audit in any serious company doing software.

Security is more of my concern: these things change constantly and versions can even be completely replaced, so even if you convinced someone to do a full security audit (and they checked all the dependencies of the dependency, etc. etc.) I still don't think I'd feel entirely secure.

> checked all the dependencies of the dependency

Is it even possible? I once checked perhaps at the depth 5-6 and it reached maybe thousands of items. At some point though there were many repeated dependencies, sometimes on different versions of the same module.

Funny, I've worked with multiple companies and their lawyers who were very serious about license compliance and what not. It took all of fifteen minutes to prepare a spreadsheet of our licenses (planned, anyway). Not a complaint from any of them, other than an "oh, that's more than I'm used to seeing."

The one sticking point was webpack 1; they had some dependencies with unlicensed dependencies. Fortunately, we were already leaning towards browserify anyway at the time. Webpack 2+ resolved those issues.

Fair enough. Now imagine that your product or service is gaining popularity on the market where Google or Facebook consider you a competition.

The idea that you should consider "what to do if your company grows to be a competitor to Google" in your technology decisions is quite frankly some of the worst bikeshedding I've ever seen. That question shouldn't even enter in to the process at the start.

If that happens, and it probably won't, but if it does you will have a team capable of dealing with the issue by then.

Considering that both Google and Facebook are heavily invested in this scene with Angular and React, there's not much to imagine. They're both fine with lots of licenses.

They will buy you first.

Acquisition by Big4 is not everyone's dream, imagine.

I'm coming from a similar background and mindset but over the past few months I've been doing a lot of prototyping and some production using Vue without the build tools. I just include vue.js and use x/template scripts for the templates. It's definitley saved me hundreds of hours already.

Does this mean you use regular js and not es6?

I can't comment for the parent, but I've done that, and yeah, I just toss the vueJS file, any additional files for components/polyfills, and my script file into the page via a tag and it works as expected.

I've dabbled but I don't use es6 much. I assume you assumed that because how the build tools allow you use es6 and compile to a lesser es. A good chunk of what I write is used by devs so I don't necessarily avoid es6 due to browser compatibility, I just haven't found there to be a ton of useful features in es6. Variable scope has never been an area of concern for me; I've always used snippets, which covers most syntactic sugar; and I definitely don't want to start using OOP in JS.

I'd recommend trying out create-react-app if you want to learn React without having to worry about all the build tooling craziness. Eventually you'll have to start fighting with those if you build some real life stuff, but create-react-app is great for just getting up and running so you can learn the actual library (the fun stuff) first.

It discourages us full time FEs too. Webpack and a full transpile pipeline is still relatively new to JavaScript but it seems like we’re starting to land on some assumptions (and thus making this a more turnkey process)

ES6

Route based lazy loading

Some sort of typing (TypeScript or FlowType)

CSSModules

React with JSX

Redux

The reason it’s been so difficult is because we’ve had a sort of Wild West mentality where we want to throw everything at the wall and see what sticks. Hence the extreme configurability of Webpack. But this seems to be the preferred configuration. I speculate we’ll see a more turnkey build pipeline in the next year rise.

Parcel is a new configuration-free build pipeline that's new.

https://github.com/parcel-bundler/parcel

It's still missing a few things like dead-code elimination.

My shop does not use any front-end build system because of the trouble of setting it up and we don't like cli to create a template for us too because it takes time to study how to change such a template to suit our need. If parcel gets mature support of vue, we may use it and skip webpack for the next project

ES7, ES8, styled-components...

Im learning all this stuff now after 30 in person and phone interviews and no offers. Ive been a Design coder (bootstrap, html5, css3, jQuery) since 2010 and never had an issue finding work before.

It's ok though because you got to keep up with the benjamins or become a useless dinosaur in this field.

My biggest struggle is knowing why a certain thing is done. I don't want to simply build on a layer of magic, I want to know why I am using a particular framework or library. But without much experience having done it prior, it is hard to evaluate why the current trends exist at all.

I came from the same background, and got hired onto a team that uses a modern stack, and it really wasn't that painful to pick up. A few weeks of working day-to-day in such a codebase, and you'll get it. You might not like it, you might prefer the old school ways of coding, but feeling sorry for devs who move to such platforms isn't necessary. We're doing fine.

Considering there is easily (in US) 60-80K+/year difference between doing HTML + CSS + JS (mostly via jQuery) and say React. Spending 1 month to learn webpack + React looks like fairly sound investment of time.

There are no longer any HTML, CSS, JS jobs posting without the fact of needing to know one or multiple JS frameworks.

If you are currently working and using no frameworks in your current job you better learn them before looking for your next gig. Because if you don't you are no longer relevant .. .speaking from current job hunting experience and 30 interviews yet no offers.

One interesting question might be why the reverse isn't true: if companies could spend 60k less per head (or even 30k less per head) by hiring developers who demonstrate facility with HTML+CSS+JS+jQuery and then training them over a few weeks in webpack+React (while getting them up to speed with the particulars of their codebase, which is inevitably going to be a thing anyway), why wouldn't they do that?

Two reasons: recruiting departments head recruiting and they use keyword filtering tools to limit their nets.

The second reason is that nobody (as far as I can tell) seems to be hiring to train anymore. They just want full capacity from everyone and there’s a lot of myth out there about how an unskilled contributor can be a huge detriment.

Forget about Babel / Webpack. Pick one of the simple ones that can be used without a build process: choo, Hyperapp, Preact. Read the source. The change in paradigm is the main takeaway.

That's how I feel configuring networking and load balancers and other backend stuff. I know its essential but for some reason front end and all its quirks makes more sense to me

It makes little sense to us as well, that's why we've invented the term "DevOps", and offloaded the real work to those (mostly bearded) dudes.

That's the opposite of DevOps - that's the old model of separate development and operations teams (the "throw artifact over the wall"-model).

Eeeh, configuring load balancers and networking are not backend tasks.......

I mean yeah, that's done on the backend as well, but that's generally not what people mean with that term.

It depends on the developer. Myself I like to get in touch with where my code is deployed. So I like to do that stuff myself but most of the time there Is somebody dedicated to that.

I got so fully discouraged in web development that I'm now moving towards software engineering. Before, I was fully invested in being a web developer

I think about it like this:

The number of projects is simply a sign of how popular the language / platform is (is becoming).

When you start to understand / recognize the different "types" of projects you'll see they all (generally speaking) fall into probably less than 10 total categories of projects.

Your goal is not to understand all of them well, but to understand them well enough to know which ones fit their use cases the best. When I think of these things in this way I can generally dismiss ~90% of the projects after I've read a handful of pages of their documentation to know whether they're on the right track or not.

Then, for the ones I've dismissed, if I start seeing those projects pop up more and more on forums like HN I might reassess, but other than that once you get over the steep edge of the learning curve it's no longer intimidating to see so many projects popping up in the ecosystem.

EDIT: Or just get your skills to a point where you're confident enough that you understand the fundamentals well enough that you can fit into any project no matter what front-end libraries / frameworks they're using.

Lots of replies here, so not sure if you will read this. If you do, I hope it will help you in your career going forward.

"Pure JS" and "Mostly via jQuery" are actually at odds with each other in your description. jQuery itself is a huge library/framework and requires at least as much specific knowledge as any of the frameworks you list. The main difference for you is that you already know it, and so it seems simple/obvious/unencumbered/whatever. Understand that when people describe their framework of choice they are coming from exactly the same place you are. Their preferred setup seems simple, obvious, reasonable and everything else is bloated, complicated, and foreign in comparison.

Especially when you are at the start of your career, or if you have had a career made up of pretty much the same thing, it's easy to see the world outside your sphere as confusing, complex and unnecessary. The computing world changes quickly, though. People complain about the JS world, but it's not really as crazy as most people make out. In my career, I've been paid to work with no less than 15 programming languages (and probably more that I'm forgetting). Each of these programming languages come with multiple ridiculous frameworks. How many X Windows widget libraries have I used? Windows? Old Mac? OS X? Java has it's own! Web frontend frameworks? Then how many DB frameworks? How many communication frameworks? How many IPC libraries? Seriously, I'm just getting started.

Programming is programming and if you don't want to be constantly learning new things, then this job is not for you. I don't for a second think that's the case ;-) Every one of us gets "new framework fatigue". This isn't Pokemon. You don't have to learn them all. However, you should keep learning new things that interest you because each one of these things has valuable ideas in it. Each one uses a technique that you can use later in your career -- even if you aren't using that framework/library. Similarly each one of these frameworks and libraries has huge drawbacks. Really understanding those drawbacks makes you a much better programmer.

I've got a lot of friends that are still DB2 programmers. Others that are MFC programmers. There's a good chance that if you are under a certain age that you don't even know what I'm talking about. They have to hang on to their jobs with a death grip because they will never get another one. Move on. Learn new things -- you don't want to be like my friends.

P.S. I have used almost everything you've listed -- except jQuery. :-D

This is for React Native (which lets you make mobile apps), not for web, technically, but you can try learning React with https://snack.expo.io/ which is 'batteries included' and lets you write the code in the browser, no setup required at all, just a mobile app (Expo) on your phone that can load the code you're writing to display your app. No webpack, babel, grunt... involved!

Check out Wes Bos’s courses. He does a great job of making this stuff accessible. http://wesbos.com

I second this recommendation. Really great videos chunked into bit-sized steps where you're building something that is more than just a To Do List.

Same happened to me when starting with iOS programming. It requires some time but it’s totally worth it. after all this is why i love coding... challenges :) I wish people to complain less and enjoy more the road to master a technology.

I recently started to build an electron application using the electron-vue boilerplate. Dear god, there is a ton of garbage in that boiler plate! Not to mention boilerplate is such a code smell.

With so much base stuff baked into that base, it makes it difficult to add new components and really understand what's going on.

Still I'm glad my first step into Vue is through an electron app so I'm not dealing with figuring out browser comparability. Still it makes me sad we don't have very many cross-platform desktop app tools, that we have to use electron and package a 100MB web browser and VM as part of our app.

Slack, Discord, etc are all at least 90MB. That's kinda messed up.

Qt, wxWindows, etc.

It's ok, the people who have picked a weekend to learn it feel sorry for those stuck in 2005 web design, too!

Sometimes I think web devs specifically and devs in general forget just how much you have to know to get started even with something "easy" like Django. You gotta know HTML (it gets new features, too), CSS, SQL, Python, Javascript, and the tools necessary to each of them. You gotta learn all that while a framework abstracts it from you. And that's not even considering the choice before that. Why not Rails or something else? Frontend dev is pretty simple in comparison, you're just familiar with one and not the other.

Node is an interpreter that runs JS on the backend. If you understand what Python or Ruby do, then you understand it. You of course can use it on the backend, but the main reason frontend devs use it is to compile the most recent versions of JS down to stuff that works on browsers. You're free not to do that, but JS has evolved for the better over the last decade. Babel is the main tool people use to do this, and webpack uses something like Babel to "pack" your app/components for the frontend. In a lot of cases, if you are using webpack, you don't need grunt. But both of them are build systems, which all language ecosystems use.

Most of it is optional but quasi-necessary and fits a defined role and need. But don't miss the forest for the trees, don't let choice anxiety get to you. What you want to learn is the underlying model, which is a huge step up from what people were dong 10 years ago. If you don't want to get complicated, there are a few "no choice" options.

1) Use React or another view library without any fancy schmancy tools.

2) Use a small, full-stack framework like hyperapp or Elm. This is the entirety of the model you want to understand, and both are small and easy to learn (we're talking a day if not an hour).

3) Use a bigger, everything included framework like Vue. There's no guarantee it won't be passe like Ember or Angular in five years, but there's an existing community and documented way of doings things.

Pick one of them, any of them, but don't get in that dread of choice. The great thing is once you've learned any of them, the concepts are wide enough that you can pick up another framework really fast. As in I can look at any of these and understand what they are doing the same way you can look at a web MVC framework from 2005 and know the hows and whys of what they are doing in an hour.

The great thing about the churn is it's like Christmas every day. You don't have to pick up any of the new stuff coming out, but I'd rather have options and evolution rather than not. The alternative is stagnation.

It's really fun and empowering. I encourage you and others not to get discouraged. Oh, and don't feel sorry for your coworkers. They're learning new stuff. What's better?

I'm not a web dev (I'm backend/HW communications). But I dabble. For me, it's not that I don't understand all of this (it's all relatively simple). I just don't want to do so much just to get something on the screen.

I've used webpack for well over a year now, and while there is a lot to learn in webpack if you really wanted to write your own config or just learn for learning's sake, you really don't need to learn it to dabble. The thing that makes comments like these absurd is that you really need to learn almost nothing about webpack, grunt, gulp, broccoli, rollup, etc. Just to dabble. Almost all of the boilerplates and starter kits do this for you.

No, no misunderstanding. I was being snarky and referring mostly to the laundry list of items that most FE devs have running or install just to start building a FE. To me that seems ridiculous and shows me that FE devs have either not paid attention to the bloatedness that is Enterprise style development or have and walked away with all the bad habits.

Thats a little presumptuous. We're doing the best we can to build complex applications, on top of a platform that still has no proper module system, no UI toolkit except a wonky document model on top of which bloatedness was built, sandboxed to hell, with the crappiest "stylesheet language", on top of a wasteful protocol that wasn't able to do more than one request per connection, with 1s (if you are lucky) time to load, compile and run fresh code on the fly, in multiple different VMs, some of them years old with half of the features missing.

We have paid attention. We're doing the best we can. Until we get HTTP/2 everywhere, ES6 modules and we fix the tire fire that is global CSS... this is what we have to do to make it work.

Have you ever tried getting started on a pretty gui in native windows?

The web doesn’t look so bad now, does it?

Don't expect to learn React (or Angular) in an afternoon by reading a couple of tutorials.

Go to Udemy.com . Buy a couple of courses for $20 and spend a week following them.

After that week, you will be able to start programming in React.

The official React tutorial is excellent and I learned the basics of React from that and was up and programming in a day. It took me a couple of weeks to understand the library in more depth, but there just isn't a whole lot to React. For Angular I agree it takes far longer.

You cannot learn React in one day. No matter how clever you are. You can learn enough to start coding but, until you understand Redux, how to use selectors with Reselect, middlewares, async-actions and the component lifecycle, you will be writing awful code.

Some people, when they pick a new technology, they choose to spend an afternoon reading half tutorial and then start coding straight away. By the time they finally "get it" and start to write decent code, they already put 5000 lines of spaghetti in production that some other developer will have to cope with in the future.

Even Dan the creator of Redux says you don't always need Redux and I got along fine without it for a basic app. I was writing clean React code within a day. The component lifecycle took maybe two days to understand? It's so simple I wrote a popular answer about lifecycle on Stackoverflow within a couple weeks of learning it. Want to write a big app with complex state? Sure, you'll want to add Redux to the mix. But it's not a hard requirement and is overkill for small simple apps. You can learn React itself very quickly.

In order to be able to tell if you need Redux or not for a project, you need to know Redux; the pros and the cons.

IMHO, too many developers overestimate their intelligence and write awful code because they didn't take the time to learn well the tools.

Too late to edit my other response where I meant to point out that in React, Javascript is the templating language, which is one less thing to learn when compared with Angular and others if you already know JavaScript well.

> In order to be able to tell if you need Redux or not for a project, you need to know Redux

Not according to the creator of Redux. His advice is "Instead learn to think in React. Come back to Redux if you find a real need for it, or if you want to try something new. But approach it with caution, just like you do with any highly opinionated tool."

https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

> too many developers overestimate their intelligence and write awful code because they didn't take the time to learn well the tools

No argument there. You do have to go through the entire official tutorial, and I would also recommend the article "Thinking in React", that Dan Abramov referenced above. https://reactjs.org/docs/thinking-in-react.html

I'm not claiming your experience with awful code isn't real, I'm sure it is. But is it because React is difficult to learn? When I learned React I was already good at JavaScript. And I had already learned Angular. Angular took me over a month to start to feel comfortable, and I still felt like I was stumbling around in the dark. The Angular API is very big. With React I was writing code, and code that I still use, within days. And I felt comfortable that I mostly knew what I was doing. When my code got a little more complex, I took a few hours to read about and learn about Higher Order Components. And when I needed routing I taught myself React Router in one day, and began answering questions about it on StackOverflow shortly after. Did I take the time in each case to completely understand the API and is that different from what other devs are doing? Possibly. But the point is that the React API did not take me weeks to learn. It's a simple API and there just isn't much there to learn. The React lifecycle for example has less than a dozen methods. It's super simple. Maybe other devs do struggle with getting such a simple API internalized, or maybe they just didn't go through the entire tutorial carefully enough. With React Router I am constantly answering questions that have answers right in the documentation. So maybe what you are seeing is lazy programmers, not a difficult API. In any case, in the interest of not going around in circles here with a difference of opinion, my most important point was comparing the simplicity of learning a UI library (React) vs. a very complex framework like Angular. React was WAY more simple to learn in comparison. And it should be. It does far less. Fair?

This is an opinion, so don't take it as fact, but JS frameworks are a mistake. It's better to take the Unix philosophy and build things up from single components that do their one job well, and focus on standards. So an example would be to use Web Components rather than React. React is amazing but it has a limited lifespan (though that lifespan could be long), whereas Web Components, while not as feature rich, are a web standard. The gaps between React and Web Components can be filled in by various libraries, such as Lit HTML. For state management you could just use plain javascript or dip into a particular library like Redux or MobX if your needs get complex.

In any case, once something no longer fits your needs, you can change it out with something else, which is difficult if you use something like Angular or React or Vue.

I don't know... not all web standards worked well in the past: xhtml, appcache, etc. I wouldn't be surprised if web components never got success. Why should anyone use this standard when a library is 10 times better? Being the standard is not enough.

You're just assumming the library is 10x better.

One reason to use web components would be it allows for a much more lightweight abstraction over DOM.

(HTML) DOM is performant, snappy, and cross browser compatible as never before. One of the reasons why jQuery is becoming irrelevant is that DOM finally works.

But when you need to polyfill an entire browser’s worth of functionality, at some point you need to ask if it’s worth the trouble.

Sure, I ignore that, for the sake of an argument. Hopefully webcomponents will be ready soon in evergreen browsers.

You can still compare idea of React and idea of web components, ignoring everything else, and come to some conclusions.