
Ask HN: Fatigued by the complexity of ES6 tooling. What to do? - bufflehs
After taking a React and Redux course for a while, I decided to rewrite an old app in it for learning purposes. Started with create-react app and everything was working fine. Ran yarn add react-router to try and add routing to the nonexistent app, and there began my five hour struggle to get this working (which is, not even done yet.)<p>After looking for docs for a long while to even get the page to render (because the react-router documentation isn&#x27;t working well either), I ultimately wanted to scream. And I ask myself, why did we overcomplicate front end so much and how did we get to this point?<p>Now to you: how do you deal with JS fatigue? Please share tips, and learning plans, etc. Is it just me, or is this too complicated for something that should be simple? And are there any alternatives or hope?
======
johnfn
A lot of posts on this thread about js library fatigue are advocating for...
more libraries. Go figure. :) I advocate the opppsite: use as few tools as
possible, until you realize why a tool is necessary.

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.

~~~
whytaka
>I was like "ah, that's why React is necessary over Backbone"

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

~~~
johnfn
Absolutely!

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!

------
zmmmmm
I'm in a similar position, trying to update myself from jQuery/Backbone land
to React etc. It truly is a nightmare - so many similar yet slightly different
tools and conventions. So many web sites with code that almost works but not
quite. So much "magic" which works when it works and when it doesn't you
simply have no idea where to even start debugging it. Which is all the worse
in languages like Javascript where everything is typeless and dynamic and the
only way trace things is to debug live, usually landing you into minified code
you have no hope of decoding.

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!

~~~
brandoncordell
Check out VueJS. It's simple to get started with, especially coming from the
land of jQuery.

~~~
cholantesh
Learning Vue right now; it really feels like a much more reasonable version of
Angular 1.

------
laktek
My recommendation is to start with just ES6 and Web APIs. Use DOM manipulation
APIs to render page. You can use History PushState [0] and CustomEvents [1] to
handle routing.

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](https://developer.mozilla.org/en/docs/Web/API/CustomEvent)

[1] [https://developer.mozilla.org/en-
US/docs/Web/API/History_API...](https://developer.mozilla.org/en-
US/docs/Web/API/History_API#The_pushState\(\)_method)

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

~~~
slmyers
> You can use History PushState [0] and CustomEvents [1] to handle routing.

Can you please expand on this?

~~~
laktek
Sorry in a bit of rush as it's Sunday here, I will try to write a blog post
with more detailed example later tonight.

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);
      });
    
    

And then in your app code (for example, when a user clicks a button), trigger
a state change:

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

~~~
Siilwyn
Hey just wanted to say thanks! Never heard of the `CustomEvent` API I [used
it]([https://github.com/AyriaPublic/desktop/commit/3e3b0ad76e7624...](https://github.com/AyriaPublic/desktop/commit/3e3b0ad76e7624717e4576873f1732d70e310b30#diff-15ee858ae5d5aa9b3e2846cfd1c4c466R17))
in a small work in progress Electron app. ^^

------
hoorayimhelping
> _And I ask myself, why did we overcomplicate front end so much and how did
> we get to this point?_

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.

~~~
kumarharsh
This comment is perfect! Exact my thoughts, and actually I've fell into the
same trap as the OP sometimes, even after becoming proficient in React
/Webpack

------
akamaozu
This isn't JavaScript fatigue; this is CoolScript fatigue.

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.

~~~
aprdm
As an anecdote, I have been using react and react router with no jsx or
transpiling for 6 months now and it works just fine. Dependencies are in
index.html order ( crazy I know ), things follow a conventional folder
structure and the project is about 100k LoC.

~~~
cwsx
Do you really find it easier writing React without JSX, compared to just
adding the JSX transpiler?

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

~~~
aprdm
For ... Reasons I can't use npm or node in the platform I develop this
project.

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.

------
apo
> Now to you: how do you deal with JS fatigue?

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](https://www.npmjs.com/package/reify)

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

[http://rollupjs.org/](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/](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](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.

~~~
cdata
I propose getting rid of tools altogether. On a new project, start with the
following: a single browser (for bonus, choose the mobile version) and vanilla
everything (JS, CSS and HTML). If you need a build step to run your tests or
your code, you have gone too far.

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.

------
malikNF
1\. If you are a new developer, please don't think you HAVE to make perfect
decisions about your program. We all started somewhere and made mistakes and
kept moving forward. Just don't worry, you will get better with time, and I
bet this is how programmers we all look up to also work they learn and move
forward and give up on trying to create the perfect.

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](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.

~~~
searchfaster
As an absolute JS newbie, I tried Angular, Angular 2, React and Vue 2.0. I
found Vue most easy to approach. Vue is well designed, documented, super light
and easiest to get external packages working.

------
ysavir
I still code in ES5 with Backbone or Angular, depending on need. I've never
felt nor seen a need to learn ES6 or React.

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.

~~~
traviscj
This was kinda my philosophy until other devs started working on my project. I
couldn't bring myself to tell them "no ES6" in PRs, but wasn't actually a
review without knowing it.

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.

------
megous
I just don't use any tooling and/or needless abstraction. It's not necessary
at all, just like it was not 6 years ago. I write ES5-only code if I need to
target IE9+.

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.

~~~
ykler
Virtual DOM is entirely about performance. It is an abstraction that doesn't
leak because it doesn't really have different semantics from the real DOM in
the first place. In my experience, it is not crippled, doesn't cause usually
trouble, and doesn't increase cognitive load. But I am curious to hear more
about your bad experiences with it.

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

~~~
megous
How to put it? I know where the state really lives in the real DOM. I have
HTMLInputElement and if user edits it, I can always access
HTMLInputElement.value and have the current value. I can associate my data
directly with the DOM nodes as simply as node.myData = {something}; and it
stays there no matter where the DOM node moves in the meantime.

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?

~~~
ykler
You seem to be saying that VDOM gives no benefits, but in my experience the
idea that your view is a function of your state that you can just completely
recalculate whenever your state changes is a hugely useful abstraction that
makes code much less bug-prone. And it is not available without VDOM because
the performance would be terrible if you generated actual DOM this way and you
would also lose state like scroll state that might not be reflected in your
store. No doubt there are some tricky cases for VDOM. Maybe some of them even
warrant using it only selectively although my experience has been that when I
started compromising on the purity of the React/Redux model it caused
problems. (And I will grant you that this in itself is a weakness of the model
because sometimes you can't control where state lives.)

------
tifa2up
The best thing to do from my experience is to use boilerplates.

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](https://github.com/react-boilerplate/react-boilerplate)

~~~
malikNF
Boilerplates are fine as long as things are working. Suddenly you come across
a library you want to add to your project, and the boilerplate is not working,
you go in there to figure what's going on, you are now even more frustrated,
there you were trying to get something done, but now you are trying to
understand something you didn't even want to understand at all.

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.

------
carsongross
If you are willing to try Yet Another Javascript Library, I have been working
on something that will make things a lot simpler:

[http://intercoolerjs.org](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...](http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html)

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

~~~
cyberferret
+1 - I wish I had heard of Intercooler much earlier. I've just incorporated it
into a couple of existing projects, and it really is the antz pantz when it
comes to doing simple partial screen refreshes or background processes when
buttons are clicked.

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/](https://vuejs.org/) [1] -
[https://hackernoon.com/tophn-a-fun-side-project-built-
with-v...](https://hackernoon.com/tophn-a-fun-side-project-built-with-vue-js-
and-rethinkdb-f22159641c1b#.70e5lfrjk)

~~~
Raed667
I might be a bit green but your setup doesn't seem "simple" at all for me!

------
meagher
It might seem like a JS problem, but it's inherent to making software. When it
works, you feel amazing. And when it doesn't, you feel terrible.

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/](http://meagher.co/blog/2017/03/07/set-up-is-hard/)

~~~
veidr
I'd say _part_ of this problem is specific to JS (in its current state). I
don't think there is, or ever has been, a major swath of the software
development world with:

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

~~~
lokedhs
I think you nailed it. This is something that is pretty unique to the JS
world.

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.

------
ufmace
Honestly, I'm not too impressed by the React/ES6 ecosystem either. I've built
a little toy app in it, but I'm not seeing the awesomeness that people claim
is there. As for what to do now, it depends on what your goal 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.

------
spankalee
It seems you're frustrated with frameworks and the web platform in addition to
ES6.

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.

------
abecedarius
I code straight ES6 with no extra libraries and no compilation step, loaded
straight into a modern browser. I don't have to care about older ones.
Nobody's paying for this, and therefore nobody's paying me enough to deal with
the tooling people complain about. The web is a pretty nice platform now, when
you can approach it this way.

~~~
BallCramp
Yeah, I just do everything in ES5. Although grunt-concat is beautiful... I no
longer have to work with 1,000+ lines of JS in one file (or deal with the
overhead of importing a laundry list of .js files). I just have it 'watch' a
folder for file changes, and it re-generates the concatenated file
automatically... so I can pretty much go hog-wild with chopping up my JS into
files. I was very resistant to NPM/grunt/etc., but it's such a quality-of-life
improvement, I can't go back.

------
pan69
I have personally noticed a similar thing as well. The solution that worked
for me is to use less. In my case, I have settled for multipage applications
(I find that SPA's increase the complexity of a UI exponentially) and I
primary use jQuery for any UI related things with RequireJS to make it modular
and Grunt to build/compile everything and obviously NPM for dependency
management. I have used Backbone in the past but I don't find it very good.
Other than that I using plain Javascript, the kind that runs in the browser. I
don't really mind if I have to write function() or () =>.

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.

------
bluepnume
After burning a lot of time to get all the tooling I wanted working, for the
umpteenth open source front-end javascript library I wanted to publish, I
threw together this:

[https://github.com/krakenjs/grumbler](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.

~~~
rublev
_sigh_

[https://xkcd.com/927/](https://xkcd.com/927/)

~~~
bluepnume
It's not supposed to be a standard, in any way imaginable. It's just
boilerplate that you can clone, and modify later if/when you feel like messing
with javascript config files.

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

~~~
rublev
I was laughing because the following sentiment is what got us here in the
first place:

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

------
marcell
I had the same experience when starting with React. One thing I would
recommend is to _not_ use Redux. It is an advanced framework that's
appropriate for large applications and teams, but will give you a headache
when you're just starting out. Add it in pieces as you make your first React
app.

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.

------
doomsdaychicken
I've had a similar experience. After struggling with react and ember for a
while, I ended up switching to using Vue, which IMHO, has a much simpler setup
with Vue loader.

------
tedmiston
As a perspective from someone doing React + ES6 work while coming from a
background in Python ecosystem, the modern JavaScript ecosystem is kind of a
mess.

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.

------
kennu
My solution to this was to choose a higher level framework (Phenomic) and
treat all the included tooling as opaque. I was able to start writing and
deploying React/Redux apps right away and only get deeper into all the tool
details later.

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.

------
andreliem
I moved to vuejs... 2.x is great. Had the same experience with reactjs as you.

------
nickbauman
I don't use ES6. Since everyone compiles everything (including even
JavaScript) down to a not-very-human-readable version of JavaScript anyway,
you're free to implement in any language of your choosing that compiles down
to that too. I would use a language that doesn't rely on the
Node/NPM/Bower/Grunt garbage heap. Clojurescript is my choice.

------
liminal
I agree that JS tooling is out of control. I've been playing with Vue, and TBH
have no idea how Webpack is munging all the files in the project into
something workable. At this point I've given up on understanding. Likely in
the future things will break and I'll need to figure it out, but for now I
prefer to ignore it and get on with my work.

~~~
Svenskunganka
You're not forced into using Webpack with Vue though. You can go with the good
ol' setup that looks like this: [https://github.com/vuejs-
templates/simple/blob/master/templa...](https://github.com/vuejs-
templates/simple/blob/master/template/index.html)

~~~
liminal
That's interesting, but it seems like it's intended for exploration rather
than production.

~~~
Svenskunganka
Definitely not, that approach is as production-ready as the webpack version,
but it places application structure in your hands.

------
smdz
I had the same issue. The first time I used React for a quick POC without
react-redux/flux, I ended up using react-states a lot - ignoring all the
wisdom out there. It worked well only for the POC and ended up refactoring a
lot later.

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.

------
phyller
While we all wish there was a standard few polished tools that did everything
we needed and had good documentation and testing tools, I think the reality is
that what we want to do and are capable of doing using javascript is evolving
so fast that the perceived chaos is inevitable. So you have to choose, what
are you trying to do and why?

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.

------
HorizonXP
I struggled for a while between create-react-app, and other boilerplates. Last
month, prior to a GraphQL rewrite, I dove in and stripped out our build stack,
and rewrote it to use Webpack 2.

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.

------
_jezell_
Fight the fatigue by realizing that tools like React and Redux aren't really
designed to make your first 5 hours more productive, they are designed to help
you manage your project as it grows by making it testable, debuggable,
performant, composable, etc. Yeah your first 5 minutes on a vanilla JS or
jquery project might be super productive... but write code like that for a
year and you might not find the same to be true. The bottom line is that
building software is actually rather hard, but it's not hard because of the
first 5 hours. It's hard because of the next 10,000.

------
JDiculous
It is indeed a pain in the ass. Personally I worked off of boilerplates
(uploaded my own as well, though haven't updated it in 7 months
[https://github.com/JeremyBernier/redux-react-isomorphic-
mini...](https://github.com/JeremyBernier/redux-react-isomorphic-minimal)).
Luckily once it's set up, you don't have to update it - unless of course you
want the latest and greatest.

------
krisAU
The ecosystem has exploded over the last 18 or so months, while the language
has had some dramatic additions. There are so many great tutorials and
libraries with examples, but no clear 'best-practice' or agreed-upon adoptions
to the additions to the language. I see this as a teething-stage to a very
interesting period for programming languages and software development, as
frustrating as it can be at times.

------
crystalPalace
I'm still using jQuery and Bootstrap although I often use Web Sockets in place
of AJAX. I wanted to like React but found it to be quite fiddly in practical
use. Vue.js looks very promising and functional reactive programming in JS
could lead to greater awareness of functional programming and its benefits.

------
slurppurple
React, redux, babel, these thing can be cool tools to use, but if you're
feeling fatigued just don't use any of them, vanilla ES5 + CSS + HTML are
complicated enough by themselves. But I think it's easier than going all out
on coolscript (that's a good way to describe it akamaozu)

------
tboyd47
Yes, it is truly awful. It's not just you. There are many of us, but we are
powerless. There is no hope.

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

~~~
carsongross
Please, check out intercooler.js. I built it for use w/ Rails, and it works
really well w/ it. You can develop web apps like you always have, but add AJAX
in an intuitive and painless manner when you want to.

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

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.

------
hansede
imho, try Vue

------
hackerboos
Which version of react-router are you using? V4 is very straightforward I
thought.

------
ww520
It took me days to finally get a frontend dev tooling pipeline set up.

------
meesterdude
checkout [http://intercoolerjs.org](http://intercoolerjs.org) \- i found it
brought some sanity to my JS

------
cellis
Use react-universally and rejoice. [https://github.com/ctrlplusb/react-
universally](https://github.com/ctrlplusb/react-universally)

------
alphanumeric0
Purescript.

