With my current project, I started off with just Backbone and Typscript. Eventually, after hitting a few walls, I was like "ah, that's why React is necessary over Backbone". Then I realized why Redux was necessary. Then immutable. Then webpack. Each of these little revelations coming a month or two apart.

The problem with instantly installing every dev requirement you think you might need is that you may not actually need as many as you think, and then you're burdened with unnecessary complexity. Along with, of course, the pain of learning and dealing with the intricacies of getting dependency each set up. Depending on the size of your project, Redux may not be necessary. Nor immutable, etc. But you won't know if they are necessary until you understand them, and that only comes after using them or feeling the pain of not using them.

The only tool I believe is truly necessary for any web project is TypeScript. I could write a small novel on why, but the crucial reason here is that it enables you to do all the above refactoring with ease. Refactoring vanilla js is a nightmare.

Interesting. I think if ES6 is properly used, thats good enough. At least with the sizes of projects I have worked on.

And I think the webpack is the single most awesome thing to happen for front end development. With webpack 2, things are just better than ever. With an overhauled doc site and good examples, its all of the good stuff.

I worry about the React/Flux patterns at this point in that they are creating codebases where modularity is specific to their pattern which could be tomorrow's anti-pattern (Prototypejs anyone?). I suspect we'll be cursing refactoring these codebases soon.

>Then I realized why Redux was necessary.

>Then immutable.

>Then webpack.

I'm eager to learn. What were those revelations exactly? If you could provide an example, it'd be really helpful.

React:

React is necessary because when you're using a non-React library, you have a ton of code all over the place that updates the view. Example. Say you have up and down buttons for adjusting brightness. In both of those buttons you'd have to do $('brightness-div').adjustBrightness(newValue). Not so bad. Oh wait, you also have a button which automatically sets the brightness somewhere else, so you need more for that guy too: $('brightness-div').adjustBrightness(getAutomaticValue()).

This is OK, but now what if you want to not only adjust the brightness-div, but also the brightness-span whenever the brightness changes? You now have to hunt through your code in n different places to update the code. That sucks. Much better is the React way, which would replace all the direct div access with an update of a shared model. Now you'd just go this.model.brightness = newValue in each of the 3 places. Then in the render() function, which gets called when the model changes, you'd set the brightness of your div appropriately. And when the DOM changes and you need to update more elements, all you have to do is update the render() method to set the brightness of the span as well.

Redux:

Redux solves the problem of deeply nested dependencies. Say you have a bunch of nested objects in your project - your App has a Menu Bar, which has a Menu Item, which has a Label. Now, the App has the filename, but the Label needs it, because it's a Save "Filename" label. The traditional way would be to pass down the file name from App to Menu Bar to Menu Item to Label, which works, but it's kinda crappy. You have to update 4 classes just to pass some data around. And if you want to refactor your Menu Bar, or move the Label somewhere else, you have to remember to pass the data a different way now.

The best way to understand Redux is that it gives you a giant global variable of all the state in your app. ALL OF IT. Then you can slice it up and each component can take only the pieces it need. Now Label can simply tap into the global variable, grab the file name, and be done. (It also gives you some regimented ways of updating the global variable in such a way that everything doesn't descend into insanity, like stuff sometimes does with global variables.)

This is why a lot of people don't get Redux - they don't have deeply nested dependencies, so it doesn't really change their code in any way, except to add boilerplate. But if you have reached the size where you do, it's a life changer. Seriously.

Immutable.js:

This one's easy - and yet curiously I've never seen my explanation for why immutability is necessary anywhere. People always start talking about data races and concurrency, which never make any sense to me because if you have a sequencing problem with mutable data, you're gonna have the same sequencing problem with immutable data. Immutable data is not a panacea! But I digress. Let me get to the explanation.

Say you have a HashSet of Points. You put point1, point2, and point3 into the HashSet. Now, you say var p = Set.getFirstPoint() and then do p.x += 5. Does your HashSet contain p now? It's a trick question! Sets do comparisons by comparing hashes, and they do the hashing when you insert the point into the HashSet. The HashSet can't possibly know that the hash value of your point has changed, because you haven't touched the HashSet at all, just the point inside it. Even if it could, expecting a harmless line of code like "p.x += 5" to go off and update a bunch of HashSets intuitively feels insane!

What does this have to do with immutability? Well, look what happens if Point is immutable. Now you can't just go and mutate your point directly to change it's position in the Set - you'd have to remove it from the HashSet, and add a new one. Now the HashSet knows that you changed its contents, because you removed and added a point. So the hashes are always consistent.

Obviously immutability isn't just necessary for keeping hashmaps consistent, but hopefully this allows you to see how immutable data allows you to write data structures that don't get out of sync with each other. It eliminates some ways for that "out-of-sync"-ness to happen.

Webpack:

This one's the easiest of all. Eventually, you're going to need modules. So, you install Webpack. THE END. :D I avoided Webpack for a long time because the webpage makes it look hard to use, but it's actually very straightforward once you click through about 6 pages of why Webpack is the best thing ever. (Sigh.)

---

I hope that all is helpful in some way!

Redux: Though it is complicated to grasp the tenants of redux, and it sometimes does involve writing a lot of boilerplate, it adds value by containing the entire state of a web app in a single object. To achieve a change in state, you dispatch an action that should describe the change being made. When an action is dispatched, a reducer is called on the existing state object, which returns a NEW object representing the new state for the web app. You do not modify the existing object.

By representing all state in a single object, dispatching actions (that should describe the change occurring), and using reducers to return a new object to represent the state, the state of complicated web apps should be much easier to understand and reason about. By using tools like the redux dev tools, it is even theoretically possible to 'time travel' through a users journey on your site (if, say, they hit a bug you are having trouble reproducing). You can see every action they dispatch and how it modified state.

Immutable: In my experience, Immutable.js is often used in combination with redux to insure that you are not inadvertently modifying the state object. Inadvertent in place modifications happen very easily, and it can be difficult to write good tests with basic redux to catch all these unwanted behaviours. Using immutable extensively prevents these unintended modifications, and confirms you are returning a new state object rather than modifying the existing one.

If anyone has any issues with what I've written, please let me know. I'm newer to JS/React/Redux.

Technology does seem to move in cycles and this has all the signs of a peak of complexity. I feel like it will almost certainly collapse under its own weight - the last time I saw complexity this out of control was the early days of J2EE. The question is whether the solution will be built on elements of what currently exists or whether someone will make a clean sweep like Ruby on Rails did to J2EE.

Sorry, I don't have anything else to offer other than a sympathetic rant!

Only part you might have to spend some time to figure out would be compiling and module bundling. I suggest picking Webpack2 [2] and going through its guides to get up to speed with it.

Avoid frameworks and UI libraries like React and Vue until you really have a good grasp of the eco-system and problem you are trying to solve.

[0] https://developer.mozilla.org/en/docs/Web/API/CustomEvent

[1] https://developer.mozilla.org/en-US/docs/Web/API/History_API...

[2] https://webpack.js.org/guides/

Can you please expand on this?

For now, I will share this snippet:

  document.addEventListener('state-change', (ev) => {
    const { key, action } = ev.detail;
    const state = { key, action };
    window.history.pushState(state, null, `/${action}/${key}`);
    console.log(`triggered state change. action: ${action} key: ${key}`);
    return handleState(state);
  });

  const event = new CustomEvent('state-change', {
   detail : {
    state: state,
    key: key
   }
  });
  document.dispatchEvent(event);

I would ask you this. You spent 5 hours fighting with React Router in an app that doesn't exist. What problem are you trying to solve that React Router is absolutely necessary? Are you trying to build an application that does something? Or are you trying to wire up a bunch of code that doesn't do anything but has all the most popular libraries of the day?

>Is it just me, or is this too complicated for something that should be simple

Both. It's not just you - a lot of people have this issue and there is some complexity here. But there is often a good reason for the complexity, and the need for complexity often comes after the simple problems have been solved. It really sounds like you're getting too far ahead of yourself chasing something that you don't need because it's what you feel you're supposed to do.

I'll go back to it: what problem are you trying to solve that you need ES6 more than ES5? Or ES3? It's been my experience that people feel the fatigue when they don't have a compelling reason to use the tools they're fighting with. I don't think "there's a ton of hype around it" is very compelling personally.

So my advice to fight the fatigue is solve your problems as they crop up and really take YAGNI to heart. Don't use a tool for advanced routing until you need advanced routing. You can build a React site using ES3 and script tags if you need to. You don't need a huge redux architecture when you're first starting out. Work on getting a webpage rendering "Hello, World" as soon as possible. Then, start adding the cool libraries that do all the neat stuff for you.

I'd also add that in this specific case, you're dealing with a library (React Router) that just recently went from alpha and beta to stable in the new (and latest in a stream of breaking changes) version which complicates things.

Major Key: Avoid compile steps as long as possible.

No Babel, no Webpack, no browserify, no JSX. You can use React without any of them. You'll get to them when you really need them eventually. Maybe. Only one of the above I use is browserify.

Why?

As a developer, your key job is keeping complexity down. Doesn't matter if everyone else implicitly gets it. If it's complex to you, don't feel forced to use it. If you can get by without it, do so. When you eventually get it, it wouldn't be that much of a struggle.

You'll still need to look up apis, function args and options, but that's just forgetting how to tell the computer what you want. Very different from not understanding why you need each piece or how to put them together.

I completely understand the overwhelming-ness of the JS ecosystem, but JSX is the one part I don't think I could live without.

After been using it without jsx for so long I kind of got used to it/ enjoy it more.

I am also ditching jsx in my side projects.

It's all just JavaScript and react API. Pretty straight forward. If you indent the render functions correctly I feel it's all good.

Any boilerplates on GH you can point out / something you could publish?

Do you write about doing this in vanilla js? Would like to keep a collection of "Just React please" docs that I can point people to.

Would have been nice to have something tangible to point others to ...

If possible, ignore Internet Explorer completely. All the other current browser versions support ES6 (sans modules). A wonderful little utility called Reify allows you to load ES6 modules in node without transpilation:

https://www.npmjs.com/package/reify

For packaging those modules to use in a browser, there's Rollup:

http://rollupjs.org/

Both are fast, even for largish JS projects. Reify allows me to write clean code and tests in Node using bone stock Mocha and Chai configurations. When I need to deploy to the browser, I reach for Rollup.

This method allows me to eliminate a good chunk of the complexity swirling around Babel and its dependents.

As far as React - I found the learning curve quite steep. Once I was comfortable enough with its core concepts, though, I found Riot to be more suitable (and quite a bit simpler) for the medium-sided applications I'm building:

http://riotjs.com/

Keeping with the attempt to promote clean code and avoid transpilation, I don't write Riot "tag files" (Riot's version of JSX) but instead use built-in ES6 template strings:

https://muut.com/i/riot-js/using:the-case-for-not-using-riot

In other words, I strive to base my projects on pure ES6 only. No fancy inline markup. No bleeding-edge ES7 features. Just plain old ES6. When native import/export finally arrives for Node and browsers, there will be almost nothing needed to switch.

Every thing you will ultimately need a build pipeline for is an optimization (bundling, subjectively cleaner code etc). I have found that if you get too hung up on optimizations before you have built something interesting, you have let the tools run away with your project. This is an easy way to lose motivation and become distracted from what you set out to do in the first place.

2. Try to always ask yourself the question, "SHOULD I NPM INSTALL THIS LIBRARY ?" Asking this questions helps you question if you really like the way they do something, you get to ask yourself if you only want tiny a subset of the features it provides so instead you can do it yourself.

3. If you are up to it, and have some time, give Vuejs a try, Vue 2.0 with Vuex has been a delight to work on. Just take a look at https://github.com/vuejs look at the projects in there, the router, the store the boilerplate, everything is done by the same people responsible for the main library. It makes making things work together a whole lot more fun.

4. Use IRC channels dedicated to what you are learning some really great people hangout at IRC channels. Oh and reddit subs for your topic.

I think it's mostly a matter of accepting that you are not on the cutting edge of programming, and the confidence of handling a less dramatic codebase built with stable tools.

At some point I took the plunge. It is actually pretty nice for my uses, and I don't feel like I spent a crazy amount of time/energy learning. Mostly just a lot more productive.

I still don't get the appeal of virtual dom. Browsers already have DOM, why use another crippled parallel one? It can only cause trouble and increase cognitive load when trying to do anything fancier.

I understand the value of having state in one place and being able to call some function to update the UI to match the state. But that is a separate concept from virtual DOM.

You can do a lot of useful stuff with real DOM, actually leveraging the power of prototypical nature of Javascript. Store your own data in it, add your own methods, etc.

I don't get much JS fatigue. Perhaps because I'm working in a bubble and don't feel the pressure to adopt the latest tech quickly.

Recently I had to extend fairly complex HTML-only web app that I wrote 11 years ago for a client, and it was quite fun. It's sort of nice to see that, while it's fun to write SPAs and everything, there are still ways to write web apps without a single line of JS.

"the value of having state in one place and being able to call some function to update the UI to match the state." Why do you have to explicitly call a function to update the UI to match the state? With react-redux, components should update automatically when the redux state changes. Of course this is a separate concept from virtual DOM.

Virtual DOM is easy to reason about in this simple case:

Events -> State -> VDOM -> DOM

But this is an illusion. DOM nodes can change state as a result of user interaction and you need to account for that (in your head and by updating the State to match).

Anything to do with DnD and animation at once seems like pain to think about in the VDOM world. Or any visual manipulation of dom nodes, reordering, nesting, grouping, etc. DOM has useful preexisting interface for moving nodes around the tree. Easy to use and directly related to what you see on the screen.

There are many cases where abstracting the state away from real DOM and pushing it down in the one way manner of VDOM just doesn't bring any benefits.

In the real DOM world you can glue the state/data to the visual elements on the page, write code that creates UI for re-arranging the visual DOM nodes and then at any time collect the data back from the DOM nodes in the visual or any appropriate order with powerful DOM traversal methods. This direct two way association of DOM and my JS objects helps in so many cases.

Sometimes it is easier to solve the problem in the visual space (DOM nodes) and sometimes it is easier to go from my custom JS objects representing a complex component or something. With VDOM this flexibility is lost and as a result some problems seem like requiring me to stuff the square peg into a round hole. I guess it is somehow possible, but what's the benefit?

Everything is architected, most libraries are pre-installed, you don't have to deal with webpack (OMG, tell me about configuring webpack), they also have a lot of documentation and most importantly sample code.

If you're using react, I found this boilerplate to be inferior to none: https://github.com/react-boilerplate/react-boilerplate

The best solution I have come up with is, to use boilerplate, but to understand what's going on before I use it in my project. By understand, I mean at-least run through the code at-least once, understand what makes up your boilerplate. Doing this has saved me tons of time in situations where I might have got stuck for hours.

http://intercoolerjs.org

Basically you annotate your HTML using plain old attributes, no javascript required, and your AJAX requests return HTML rather than JSON. It tries keep things very similar to more traditional web development, but leverages some of the HTTP features that normal HTML makes hard to get to (e.g. custom headers, non-GET/POST requests).

One really nice advantage of this is you can use REST/HATEOAS as originally intended:

http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

If you are really sick of the javascript tool chains, it might be worth a look.

Other than that, I've always had trouble getting my head around React. I recently discovered Vue.js [0] and built a small HN specific project in it [1], and to my (old) brain, it just seems more natural and intuitive for dynamic page templating.

[0] - https://vuejs.org/ [1] - https://hackernoon.com/tophn-a-fun-side-project-built-with-v...

People get hung up thinking I'm advocating adopting HTML for their public data API. I'm not. I'm advocating building your own web application in a restful manner against a separate set of HTTP end points and letting your data API satisfy the needs of your integration partners.

I've had a couple of interesting projects developed much in that manner, where a single API served both a website (browser default Accept is HTML) and mobile requested with JSON Accept. A simple middleware layer that varies the response (which is just some plain old xxx object) and returns the preferred media.

I'm not sure that I agree that with your analysis of JSON. Semantically you're correct about it not being hypertext, but I don't think that precludes it as an effective media for a REST/HATEOS application.

Read the blog linked above and the other articles linked from it, I explain the HATEOAS problem in more detail. JSON APIs are moving away from REST and towards a more RPC-style model, e.g. GraphQL. The industry is finally getting sick of shoe-horning JSON into a conceptual model that makes no sense for it.

Anyway, intercooler is a different, simpler way to build web apps. If you are willing to split your data API out from your web app API, you can save a lot of complexity in your stack. We built a reasonably modern web app with it with no front end engineers, just a couple of gronky full stack guys with some rails experience, and not much more code than a normal rails app would require. We built our data API using Grape, rather than rails. Turned out very clean, decoupling the two.

Yes, I am aware that I am telling you almost exactly the opposite of what almost everyone else does and that I appear insane.

Not sure about a specific plan, but I would go for a walk, take a hot shower, or call it a night.

http://meagher.co/blog/2017/03/07/set-up-is-hard/

- so many tools

- such a high rate of change and therefore obsolescence and tool breakage

- such a huge number of shitty half-baked solutions (a function of the first two)

Maybe this is just because there's never been a programming language relevant to so many people. But anyway, if you compare JS development to traditional native app development, or the more popular paradigms for back and development over the past years and presently, there are usually fewer and more dominant tools that maintain mind share and therefore get people to work on them and stay relevant over longer periods.

I work with JS part of the time, and my own solution to this is just cargo-cult it. That is to say copy what my advanced JS colleagues who tinker do.

The drawback is that I never have the latest state-of-the-art tooling (e.g. my project still uses npm even though I think I want to be using yarn). The obvious advantage is that I don't spend time dealing with this kind of stuff very much.

The JavaScript world is kind of a painful place to be an early adopter right now.

I think the reason for this is that the entire infrastructure is built on foundations that are constantly changing. It's impossible to spend even a year refining your infra when the foundation has been replaced at least once in the meantime.

Imagine what would happen if the POSIX API's were to change every year instead of every decade or so. We'd have the same mess in the Unix world.

In fact, there is one place where this happens, although not as bad as the JS world: mobile development. Coming back to Android after being away for a year forces you to learn a whole new set of API's and most of the things you used to do have now become obsolete.

The main difference between JS and mobile is that for JS everybody builds their own frameworks and no one knows what the correct way is.

If you just want to get a webapp working, I suggest going with Angular 1.x. It isn't super cool and trendy, but it's well-documented and battle-tested. It's very popular with enterprise shops, which you could say are the ones who don't care about how trendy the framework is and just want to get stuff done. Compared to the React ecosystem, it's pretty all-in-one - most of the core functionality you could want is in the main libraries, and setting up add-ons is easy. You don't need 50 different accessories and half-baked languages just to get hello world working. Javascript ES2015 isn't perfect, but its warts are well-known and well-documented, and it's supported everywhere.

If you're really determined to learn React and build something in it, you need to back off of what you're working on now and try another route. Maybe do something non-programming for a day or two and come back to it. Try something simpler with fewer helper accessories, or try a different starter kit. Maybe try using Webpack to build it instead of whatever else you're using? It isn't the simplest, but once you learn the basics, you should have a better handle on how your code comes together into the final js that the browser actually runs.

I think the web platform has gotten a lot more accessible to developers and actually simpler in many ways very recently.

* Custom Elements offer a built-in component model that works with vanilla JavaScript and is in harmony with the DOM, rather than trying to replace it. No tooling is needed, and you can try it out right in your browser's dev console.

* ES6 classes standardize and simplify syntax for classical inheritance where before ES5 inheritance was either ad-hoc, or you had to buy in to a frameworks inheritance helpers (variations of createClass() or extend()).

* CSS's flexbox and now grids let you express layout much closer to your intent, instead of floats, auto-margins, large grid systems, etc.

* Shadow DOM solves CSS scoping and overly complex selectors. You can write very simple and straightforward styles when they're scoped to a shadow root.

* CSS variables bring a platform-native way to do variables, rather than having to do SASS/LESS/SCSS.

* JavaScript modules will finally solve and standardize the import and loading problem, which has spawned countless tools and entire tools ecosystems.

And, if you judiciously choose some non-standard tools, TypeScript brings a great experience for reading, navigating and type checking code, with a language that's as close to plain JS as we've seen recently. It's been much easier for my team to jump between projects with TypeScript's clearer type annotations.

Personally, I think the future of the web is _very_ bright, it's just not evenly distributed yet.

One thing I'm very conscious of though is not to use jQuery to manipulate the DOM. I.e. I have a data object that I pass into a render method in which I "empty" a parent node and use jQuery .append to render the entire thing based on that data model. Basically, my template is a JavaScript function. Crude, but it works well. In an event handler such as a click I will update the data object and then re-render. I.e. a typical MVC style of flow.

Doing this allows me to actually build solutions rather than spending the majority of my time dicking around with a gazillion libraries, frameworks, transpilers and what's not. I find all of it interesting but I'm a one man band I have to produce working projects on time and on budget that do what they are supposed to do.

For my projects, my users simply couldn't care if the UI was built with jQuery or React. For your project that might be different though.

https://github.com/krakenjs/grumbler

Pretty opinionated on the tooling it uses, but good if you just want to say "Fuck it, I want to clone some boilerplate, write some code, and build/distribute it", then worry about the finer details later.

https://xkcd.com/927/

But hey, thanks for the largely irrelevant, but hilarious xkcd!

>"Fuck it, I want to clone some boilerplate, write some code, and build/distribute it", then worry about the finer details later.

Also, I would avoid using a boilerplate/starter project. Create-react-app should be enough. Many other boiler plate projects are filled with things you don't need when you're starting out.

Fragmentation across virtually every tool imaginable from language choice to build systems. Dependencies on dependencies on dependencies. Apps breaking regularly from using the bleeding edge of everything. The total number of downstream dependencies that just using create-react-app installs is kind of insane. And don't get me started about the anti-separation of concerns of embedding "inline" CSS in React components... That said, some things are simpler too. I hope the JS community starts investing more in quality and longterm unification, and it might happen but I'm not sure.

Many libraries and frameworks today are designed to support huge apps for huge audiences, but people use them even to build small apps for small audiences, when there might be a better (simpler) choice. Incentives are misaligned for the companies supporting the most popular frameworks to care about small apps though.

I think we are starting to get there, but the JS ecosystem today vs 3–5 years ago has exploded in every direction.

Many people seem to advocate an opposite philosophy of using as little tools as possible, i.e. keeping at a lower level, closer to the browser. I can see the reasoning for that when you want to be a knowledgeable engineer who understands the details of how every tool works.

An alternative philosophy is just to understand the higher level framework, so that you can write React and it "magically" becomes a website. This could be compared to developing Ruby on Rails apps on Heroku without learning any details of the underlying deployment and server software components. By using a high level framework and ignoring most of the details, you can focus on the productive aspects of the work first.

In the end you're always working at some level of abstraction, and you can choose what is the right level for you and the project.

While react and redux are simple individually, react-redux is incredibly frustrating to start with. React-router isn't complex, but feels a bit confusing at first. After a 3 days trying to make sense of "why all the complexity", I was just hours away from dropping the react ecosystem. I was primarily evaluating it against Angular2. Having said that, investing time in React ecosystem has paid off very well

1. Once your app grows, redux will make it simpler

2. Avoid react component states as much as you can. But that doesn't mean that every event dispatches a redux action. I divide my components into connected(smart) and presentational(dumb) components. These inherit from parent base components. That ensures that only connected components can dispatch redux actions and others are just connected with handlers.

3. While this is a ES6 question, I prefer TypeScript (and VS Code). I know many prefer Flow, I've found TS to be better. It might take a few hours to integrate TS in your React code - its only. Strong typing props and states with TS interfaces tends to keep your code bug-free. I also use TS-decorators a lot

4. To keep things simple, I pass the entire redux state to all connected components. Having custom base-components helps avoid being too verbose. And type-defining accessed store-states makes sure I don't break things. And then the intellisense in the editor keeps me fast.

5. Learn webpack in detail. This is very important. If you don't you might find yourself being frustrated quite often.

For simpler Apps ... use VueJS. Using React-Redux and react-router to build a todolist is just over-engineering.

I think if you are a professional, you should specialize. Make a choice and stick with whatever you choose, at least for a little while. You don't need to know everything. Maybe you don't need to know the front end at all. The whole "full stack engineer" idea is nice, but I'd rather have someone who specialized in the front end working on my site than someone who has tacked it on to a bevy of other skills and is just trying to hang on. If you are a professional web developer, then learn the tools you need, keep everything as updated as possible, and try to learn one other thing that is up and coming. Don't wait to let the updates and releases pile up before you upgrade, stay on top of it, read the blogs, update your code. But don't worry about knowing all the frameworks. If you are going to be working in React for a few years, it'll be worth the struggle with the current project you're working on. You don't need to know Angular, React, and Ember, just pick one. Learn another one when your job requires it, or mess around with it on the side.

If you are a professional web developer and have not kept up, and need to know the new hotness, I recommend Ember. They are always absorbing the best features of other frameworks (they now render the DOM like React does), have developed a pretty good update process that helps you transition, and have middling good documentation. They try to keep things simple. It seems a lot less fragmented than React.

If you need to build websites, but it isn't your only job, you don't need to know a javascript framework. JS frameworks are awesome and I love them, but for 90% of stuff you are almost just as good without them and for the other 10% you still don't need them. Learn Ruby on Rails. It's been around forever, has great documentation, has everything you need from start to finish, and if you want to dip your toes in a JS framework, you can put that on top of your Rails project no problem.

If you don't need to know this stuff for work and are just trying to keep up with the field, just keep in mind that everything you learn will be obsolete in 3 years. Hopefully you are enjoying the process, because you'll do it again soon.

Webpack is not easy, and it definitely took some reading and some work. But the documentation has become a lot better, and I was able to get it working extremely well. Now, I have the following features working:

- react-router integration

- redux

- server-side rendering

- vendor bundle to help with caching

- automated CI builds

- Docker to Kubernetes deployments

I would really suggest learning Webpack 2 and starting with a very simple toy project. Start adding features to it, and then you'll start to understand how everything fits together. Then you can take those learnings and apply them to your other projects. Once you get it, it's very powerful.

I was once a happy, gainfully employed Rails dev. No more. I am hoping to one day learn .NET core and escape.

Your problem is that what you're trying to do shouldn't be simple. For better or worse the ES6 toolchain (Babel, Webpack, npm, etc) is very enterprise. It's intended for production-grade stuff where you need a lot of control. I do frontend for a living and these tools make my life so much easier. If you're just trying to build a simple web app you're better off just starting small.