But the rest is a bit "all or nothing" isn't it ?

React is a huge bite for a start, espacially since you need webpack. How about something lighter first, like Vue.js ? Once you get how it works, you can up your game and go to React (+ webpack + Mobx, don't try redux at first it's too much) or Angular 2.

As for the backend, you can stay in Python first and do a rest API. Then once you get the front right, write a backend using node AND a framework. Do not attempt to pure JS first, it's like doing web Python without django or flask. Possible, but not worth it. ExpressJS is close to flask in philosophy, except for the asynchronous part.

If you really want to have fun though, checkout crossbar.io.

It's a Python router than allow very easy PUB/SUB and RPC between clients. Clients can be written in JS, Python, Java, C#, etc.

You can even write JS clients in the browser, making push notifications and other real time feature a breeze. It's a good way to give you motivation to try on JS: mix it with what you know, and try a new exciting technology. Plus a good way to see the difference between async in JS and in Python.

React et al gives language newbies good shoulders to stand on, but a lot of React's so-called concepts map fairly simply to lesser-known language primitives. (And for the record, writing a simple, one-way databinding library in JS takes all of about 20 lines of code)

Don't be a tool, learn more than the tools :)

There is a re-occurring thread of inventors (especially on here) building things that are more complex than necessary, and certainly more complicated than the problem they are working on. React, Angular, Electron, and a lot of other tools all use 1000 words where 100 would do. If you go through programming thinking that that is normal, or acceptable, you are doing more harm to the ecosystem and your own knowledge than if you had "reinvented the wheel" a couple of times on smaller tasks.

In the long run neither frameworks nor languages matter. If programming to you is reaching for the latest framework du-jour then you will find yourself left in the dust unless you keep with technology's futile and arbitrarily-hastened pace. (And no, I do not consider it OK that this is considered necessary) But if you master the concepts of what the tools do... then you start seeing just how badly and inefficiently they are written. Then you find yourself bypassing them, and simultaneously completing projects faster than ever while writing bespoke code that fits your requirements perfectly, and is also much easier to maintain (because hey you wrote it)

While I agree with this statement, a real life project include several people, some new to the projects, some good, some not, some with experience and some young. It requires communication and sharing things.

And tooling helps a lot with that.

Personally, I find a bare minimum of tooling to be valuable. I have built SPAs using 100% vanilla JS, and it can be quite repetitive and error-prone. I'd recommend using highly simple build tooling (maybe Brunch) and an extremely simple view layer like https://github.com/Matt-Esch/virtual-dom. Pretty much everything else you can build yourself with surprisingly few lines of code -- state management, routing, event handling, data bindings, etc. I think of it as "building your own framework", and although you might not want to do it for every project, the learning experience is great.

To follow-up... essentially, yes. A text editor and a <script> tag is one way to approach it, though I would advise that you stick with making something small. One-off, toy SPA's are a great way to get to know JS. (Here's a challenge: TodoMVC sans frameworks ==evil grin==) With big ideas it is a lot harder to do this with big ideas until you have a firm layout of the code in your head.

In fact, this may go against a lot of recommendations but I'd recommend getting comfortable with ES5 before moving to ES6. A lot of existing code is written to ES5 standard and, while ES5 is certainly missing LOTS of important goodies, there is more than enough language to do most kinds of data-processing. (Though don't feel bad if you find yourself building a util.js with a bunch of string manipulation functions, for example, or find yourself importing jquery... I consider JQ to be an exception to the 'no tooling' rule, because classic JS DOM manip really, really sucks). Things like callback hell are important to understand, even if you never intend to write in that style.

Java Reference https://docs.oracle.com/javase/specs/jls/se7/html/index.html

JS Reference https://www.ecma-international.org/publications/files/ECMA-S...

In JS you have a very small number of types, keywords and a ridiculously small stdlib.

I'm not sure what to make of your comment.

The only hard part with JS is the accumulation of bad design decision that means you gotta avoid or hack around part of the language.

The rest is just a basic dynamic language with some async semantics. Nothing crazy.

- Re: React. I actually disagree with this given that OP is an experienced programmer. The react API is very, very simple to learn but difficult to master. The forced conventions are good for productivity. If you use create-react-app, I don't see any reason to put off learning it until later, but of course you should start with the JS basics before installing react. I'm not sure vue would be better; in fact it might be worse as a first experience, just because there is far less documentation / community / ecosystem around it.

- Re: python backend. That's fine, but if the goal is to learn JS, you're not learning much by writing the backend in Python are you?

Nice tip on the crossbar.io, I'm going to check that out.

It's true that backend JS has the most modern dialect, and without any need for a transpiler. And OP did mention "modern".

I spent 10 years doing embedded Javascript(not web) and wanted to see what modern webdev was like.

Vue came highly recommended but I do not feel like I am writing pure Javascript when writing Vue. Vue might be a better choice for someone who does not want to write JS.

The hip people told me to avoid React (FB, too massive etc).

Surprisingly React feels great for writing Javascript. Just learn ES6 features(arrow functions for one) and go to town.

And, 100% avoid the "class" keyword.

When I was learning node.js I used "learnyounode", a terminal-based game/learning program. It was great. It had lessons which appropriately increased in difficulty, code examples, and guidance on which documentation to peruse in order to complete the coding assignments (each of which was a tiny application). There's one for Javascript too. They are both here:

https://github.com/workshopper

Learning to understand closures and the "this" context (including prototypical inheritance) can take a bit, but is extremely useful and important.

Related to the above, learn the Javascript "module pattern" design pattern.

When you get to the appropriate point, the source code of Redux is fairly simple and clearly written: https://github.com/reactjs/redux/tree/master/src

"Secrets of the Javascript Ninja" is an older book but a good one. So is "Javascript: The Good Parts."

TBH, the only reason that seems to make sense is some kind of weird “I knew JavaScript before it had classes!” kind of sentiment that wouldn’t actually teach him anything of value.

It doesn't need to be extreme. I just recommended writing one or two "classes" using the old style, in the beginning, because that's a great way to solidify understanding of how the inheritance actually works. Whereas when you're using ES6 classes, you're using hidden abstractions that can make debugging very confusing if you don't know what the "class" keyword is doing.

https://i.imgur.com/p9Kw815.png

If you've used Python classes and inheritance all this time and never felt confused, then people can also use JavaScript's classes and inheritance and never feel confused.

Debugging I can see as being a reasonable argument - as you step through code you should understand what “proto” means. That’s the most compelling reason I’ve seen thus far...

It might be a good idea to learn about this before using ES6 classes; remember that ES6 classes are syntactic sugar on top of prototypal inheritance anyway. They wouldn't learn legacy patterns, but the actual pattern that JavaScript uses.

  function getUser() {} 

  // `Function` being a class 
  function getUser extends Function {}

You say that there's no reason to learn prototypal inheritance, well, the only and valid reason is that to write at least decent JavaScript you have to understand how it works behind the scenes.

* [1] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

* [2] - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Edit: add links

Idk how he could be more clear about why.

Actually if you're willing to use https://github.com/scopsy/await-to-js as a transpiler, and await/async on the back end in node, then you actually CAN just call a function in a loop like you would in Python, modulo a tiny amount of decoration that is pretty similar to how you'd do it with Twisted.

That said, yeah, if you are using React.js you should definitely learn and use redux.

It's worth noting that Redux is not tied to React, and can be used with any UI layer (Angular, Ember, Vue, vanilla JS, etc).

However, my approach was to start with an more-or-less small project with react / redux / typescript. In the beginning it was a pain, but now it works.. mostly.