How it feels to learn JavaScript in 2016

Maybe it's because I work everyday in a React codebase that is sitting at 150k+ lines of similarly structured code, but I don't find that to be complicated at all. Structure almost always adds overhead, but with the benefit of adding consistency and familiarity. The # of files does not indicated to me how complicated something is.

When I think complicated, I think of code that's hard to understand, hard to modify, or hard to find things you're looking for in. In that example, everything is exactly where you'd expect it to be:

1) Where do I render / present my data? In the presentation components.

2) Where do I take data from the store and pass it to my presentation components? In the container components.

3) Where do I modify data in my stores? In the reducers.

4) Where are my reducers exposed to my container components? In the actions.

Maybe this kind of structure is overkill for a Todo list, but for a complex SPA, this kind of structure is useful and almost makes it _easier_, not harder, to find the things you're looking for. The app I work in is constantly growing and getting more complicated, esp. in regards to the quantity of features, yet I don't find it to be getting harder to go back and find or change things. I think this is due to the functional nature and design of React combined with the architecture we chose that makes this possible.

And in terms of LoC, that example doesn't seem to be much different from the Angular / Backbone implementations of TodoMVC.

* almost always

I have no patience for this kind of article.

Here is the fundamental essence of the article that drives me nuts: the assertion that the reason someone would move to one of these new technologies is because "it's trendy" or "everyone is doing it", "or angular is so 2015", "it's for hipsters". This is the standard mantra of old people everywhere who are too old to learn new stuff.

If the guy would have taken the time to learn the purpose of these tools, their pros and cons, and why one would choose to use them or not use them, that would be interesting. But that would take a bit more time. And actually learning something new.

While I emphasize with old people who feel the world is moving too fast (I am one of them), I have no tolerance for the basic anti-logic of the article: the assumption that new technology only exists because of trendy hipsters who just like change for the sake of change. This logic only exists to soothe the mind of old people who don't want to learn new things.

Some parts of the article go too far (developers finding their own ways to make things, continuously), but common idea of using Babel and writing in modern JS is prevalent - because you have to use a bundler to concatenate source code and import dependencies. But using a bundler feels like a compile step - and it's so easy and desirable to add another step and enable modern JavaScript ES2016+ in your web app. And this part is now a standard de-facto, but some people use make, others gulp, I happy with npm run or just bash scripts. But common idea of bundling and JS compiling holds true for all developers.

Actually, not yet completely solved problems in terms of consensus how to do things stay here: delay loading (login form/admin panel/main app code or features separation), component assets dependencies, modular CSS, and, of course, frontend and server side architectures with CycleJS, Elm, SAM, Redux, Angular 2 as candidates but those yet have unsolved problems: either work slow (and making simple app's size more than 1 MB zipped) or you have to write some boilerplate of source code lines. And comparing side there, of course, ability to componentise infinitely and hierarchically. And for accessing data GraphQL emerges as hot modern technology. And a lot of other cool things to keep tracking every day... It never stops, growing larger and allowing to reuse all third-party dependencies (beside of components - every team mostly prefers writing their own, because those play better with their chosen software architecture) and constantly rewriting your own source code.