Echo JS 0.11.0

It's sad that a post like this is needed... I wouldn't consider doing a modern spa/webapp of even medium complexity without a state machine similar to redux or redux itself. In a team setting it allows you to establish workflows that are consistent and easier to understand.

Also, your reducers and action creators don't need to live together, I tend to import from the base directory into feature based structure/directories. A given directory/feature does not need to contain all of actions(creators), reducers, dumb/smart/pf components and sub-components. But by organizing data/handlers into features and components into features, sometimes in the same directory, it makes it easier to find/discover, though it may seem chaotic at first. Imho, it's better than having to traverse through a deep tree to go from a component to a reducer, etc.

I really like redux, and I'm personally inclined to lean on it, even if it makes the code slightly more complex, that complexity is consistent and easier to follow than just about everything else I've seen.

That said, if you have state that doesn't need to be persisted, then go ahead and keep that at a component level. You can have a higher level component with your actions and setstate, then pass them down to more simple components, or pure view functions.

-- crossposted my comment from HN on the same article.

Nice multi-level router... one nit, don't see redux integration, or event handling in the linked page, will have to look into it.  Although redux isn't the only backing solution for react, at this point it's the defacto default.

Oh, I've known quite a few who resisted change... hell, converting ASP.Net apps to use node tools as part of build scripts over the hacky VS plugins was a fight a few years ago... (around node 0.10 release).  There are a lot of old timers that resist change, but I've seen relatively young devs (mid 20's) resistant to change as well.  I don't think it's really a product of age so much as hitting a point where learning new stuff isn't as appealing.

One issue, you don't want your git credentials, or even an auth token... inside your code repo.  raised an issue.

As a relative old-timer, I'm pretty offended by a lot of what you're saying... there are plenty of us who've kept up with the language and techniques (following node from the start, using it actively sine 0.8/0.10), and understand the newer ESnext bits... Been using babel since the beginning, though I was a little late to webpack, wasn't sold on its' value over Browserify.  Fighting for 3+ months in my team to get the tooling updated wasn't fun to say the least.

Beyond that, I was more functionally minded all along, even with C# I was more inclined to have simple POCO with static utility libraries.

Not all of us old timers are out of touch with the times.  That said, web dev is a completely different way of having to think than desktop apps... not to mention cookies vs local/sessionStorage vs indexdb vs websql and where/how it works... Though it's all *FAR* more easy to work with today vs. the turn of the millenium when v4 browsers were kings, and the next-get half baked was just coming out.  I don't think the author of the question would have handled that time at all.

It's clickbait, plain and simple (what do you want from dzone, king of interaction spam for devs). also, most of the functionality of AJAX came from the browser DOM, not the language.

I know I'm beating a dead horse... that said, I never cared for ng1's DI, as it is the opposite of discoverable... ng2 is better, but still kind of broken in terms of controls in templates vs. variables and file names... vs. React where the control matches the variable name, and the import/require references the file... you can discover where things are and/or come from.

Definitely interested in playing with PouchDB, there's also a server implementation that exposes the Couch api interfaces.  I am a bit curious about security... I'm interested in implementing some syncing of user settings to a private db server-side, and authentication is the only thing I'm not nearly familiar enough with.

Will need to find time to look into the PouchDB server implementation to see how security is, or can be implemented.

dupe

I happen to like JS, more so with the extra ES6+ niceties, but I can see the appeal of a more purely functional language without some of the extras.

And no, imho no solution is perfect.. tbh, if it's public facing I'd just prepopulate the store server-side with the essential portion of data and let the rest populate client-side... that would take care of the non logged in user case, and account for search engines... the rest can run client side.  In the end, it's up to the author.

I also happen to really like react in general, and if full server rendering were desired, I'd go the redux-universal route.  I usually use the thunk methods with async functions anyhow, so that allows promise resolution to work in that way.

To each their own though.