4 ms·

Scratch all that. Go for as long as possible without reaching for a framework like React or Vue. You don't learn JS learning those tools, you are just learning

by tomc1985 9y ago

Scratch all that. Go for as long as possible without reaching for a framework like React or Vue. You don't learn JS learning those tools, you are just learning the tool. 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 :)

sametmax 9y ago
Learning just the js language takes one day if you are an experienced programmer. It's a very small language.
- mzzter 9y ago
  How is JavaScript a small language at all? It’s comparable to Java in the number of language features. Java Reference https://docs.oracle.com/javase/specs/jls/se7/html/index.html https://docs.oracle.com/javase/specs/jls/se7/html/index.html JS Reference https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf https://www.ecma-international.org/publications/files/ECMA-S...
  - sametmax 9y ago
    It's not even on the same planet. 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.
    - tomc1985 9y ago
      There is a lot of meta-knowledge buried in using those few features that he is probably referring to. Knowledge of language features is one thing, knowledge of when to use them is another
      - sametmax 9y ago
        That's true for every language. 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.
alibarber 9y ago
This is something that I'm not sure how I feel about in general. I'm not really interested in learning any particular framework (because there seem to be about a billion and the landscape changes every day), but then again re-inventing the wheel over and over is never fun, even if learning something new. I'm hoping that something like React might be quite instructive to use and study in looking at its design choices and API structure - and also to learn _why_ someone might want to use it and what the problems are in JS/Front end development that it's there to solve...
- tomc1985 9y ago
  The thing is, you aren't reinventing the wheel. There is a certain amount of repetition in programming... you will always need to sort a list, or iterate a for loop, or assign a couple of variables. 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)
  - sametmax 9y ago
    > In the long run neither frameworks nor languages matter. 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.
dalai 9y ago
Could you expand a bit on your recommendation? Do you mean just ES6? Do you have specific resources to suggest? What do you think about all the associated tooling for writing, compiling, testing and debugging, when starting? Is a browser and a text editor good enough, or is a minimal setup vital, in particular when one is building something that is more than a toy project?
- l_t 9y ago
  I would try to think of it from a first-principles approach. You can begin with a blank slate, for instance, a single HTML file with a <script> tag. Only when "doing it yourself" becomes tedious do you start to look for libraries to solve your problem. 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 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.
- tomc1985 9y ago
  l_t's response was very good, I would recommend what he has to say. 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.

sametmax 9y ago

Learning just the js language takes one day if you are an experienced programmer. It's a very small language.

mzzter 9y ago
How is JavaScript a small language at all? It’s comparable to Java in the number of language features. Java Reference https://docs.oracle.com/javase/specs/jls/se7/html/index.html https://docs.oracle.com/javase/specs/jls/se7/html/index.html JS Reference https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf https://www.ecma-international.org/publications/files/ECMA-S...
- sametmax 9y ago
  It's not even on the same planet. 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.
  - tomc1985 9y ago
    There is a lot of meta-knowledge buried in using those few features that he is probably referring to. Knowledge of language features is one thing, knowledge of when to use them is another
    - sametmax 9y ago
      That's true for every language. 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.

alibarber 9y ago

This is something that I'm not sure how I feel about in general. I'm not really interested in learning any particular framework (because there seem to be about a billion and the landscape changes every day), but then again re-inventing the wheel over and over is never fun, even if learning something new. I'm hoping that something like React might be quite instructive to use and study in looking at its design choices and API structure - and also to learn _why_ someone might want to use it and what the problems are in JS/Front end development that it's there to solve...

tomc1985 9y ago
The thing is, you aren't reinventing the wheel. There is a certain amount of repetition in programming... you will always need to sort a list, or iterate a for loop, or assign a couple of variables. 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)
- sametmax 9y ago
  > In the long run neither frameworks nor languages matter. 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.

dalai 9y ago

Could you expand a bit on your recommendation? Do you mean just ES6? Do you have specific resources to suggest? What do you think about all the associated tooling for writing, compiling, testing and debugging, when starting? Is a browser and a text editor good enough, or is a minimal setup vital, in particular when one is building something that is more than a toy project?

l_t 9y ago
I would try to think of it from a first-principles approach. You can begin with a blank slate, for instance, a single HTML file with a <script> tag. Only when "doing it yourself" becomes tedious do you start to look for libraries to solve your problem. 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 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.
tomc1985 9y ago
l_t's response was very good, I would recommend what he has to say. 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.