> Webpack: The most popular bundler for standard JavaScript look for simple starter kit/boilerplate config examples to get things running fast<p>Unless you're already familiar with a tool, I'd suggest starting with the very <i>Hello, world</i> basics.<p>For Webpack, that's creating an empty project and incrementally adding config, starting with just an entry point (use a simple script importing some modules) and an output filename. Add one loader/plugin at a time. Move into boilerplates once you're familiar with the basic concepts.<p>(I wish more projects had a Concepts page like Webpack now has: <a href="https://webpack.js.org/concepts/" rel="nofollow">https://webpack.js.org/concepts/</a>)<p>A boilerplate is another person's code, and while it's good to avoid NIH, unless it's superbly documented, it contains tricks and workarounds that only cloud real understanding.<p>---<p>Eric wisely started the article with
JavaScript & DOM Fundamentals. For people like me, who were familiar with pre-ES6 JS but weren't actively writing JS lately, the basics themselves have changed a bit.
Learn programming, not just frameworks. Frameworks will come and go, but the core programming concepts (good design, algorithms, cleanliness, simplicity, data structures, architecture) will tend to stay relevant longer. Learn the principles of Reactive Programming, not just RXJs, learn the philosophy of Redux, not just its syntax. You won't be able to keep up with it otherwise. Source: a guy who was an actionscript guru 15 years ago.
> Learn [Vue.js] after you have learned React or Angular.<p>Hugely disagree with this. I really like Vue - but in my (very limited) experience, its appeal is that even though it's not as powerful or flexible as React or Angular it's <i>way</i> easier to learn and get moving with. Fewer new concepts, less new tooling, no ecosystem of related stuff to consider, etc.<p>I'd have suggested learning Vue first, and sticking with it until you outgrow it. If you start with Ng/Rx, and get to where you're comfortable and have a tooling/workflow around them that works for you, then sure you could still learn Vue afterwards but I'm not sure what it gets you.
Yeesh. In fairness it's a fine list, but you can be an excellent JavaScript developer and know less than one third of what's on that list. Ambitious JS lifers maybe can get to most of that, but for people who value some breadth of knowledge across tech, I'm not sure even pursuing such a list is a good idea.
> Node lets you use JavaScript on the server, meaning your users can store data in the cloud and access it anywhere.<p>I don't see how using Node server-side has anything at all to do with user's capability to store data in the cloud.
My 2 cents. I would consider myself a JS expert as I have writen AngularJS and RequireJS clones. Personally, I don't agree with the path that OS JS dev has gone in recent years. The reliance on build systems and transpilers are fundamentally anathema to the spirit of simplicity and low barrier to entry that attracted me to the language and ecosystem inn the first place.<p>I understand that as we have moved from web pages to web apps the increase in complexity was inevitable, but I question a lot of the tools being used now. For one thing, once we moved to creating full applications using JS, one of the concerns that tooling moved to address was maintainability. This is why MV* caught on and destroyed JQuery as a viable option for many projects. That being said, Angular pretty quickly swapped one kind of maintainability problem (refactorability) for another (over-abstraction and cyclomatic complexity).<p>As for the dev tooling (webpack and company), one of the reason I avoid a lot of them is in my experience they can get in the way of maintainability. For example, I recently tried to pick up a 3 month old project in Android Studio and it took me around 3 hours just to get it to compile again because of updates and other tooling complexity. This NEVER happened using Eclipse. The same thing is happening and will happen when the apps being built today get dumped on some poor sod 3-5 years from now.<p>Lastly, an example from my job. I was recently asked to update the verbiage on a sign in form built ~13 years ago. The devs decided to use some java framework that had buzz at the time named JATO. Jato literally doesn't exist anymore and building it is basically impossible. This is to say nothing of modifying it as all documentation has literally disappeared from the web. The devs picked JATO b/c they thought it would be easier to modify and maintain. Exactly the opposite has happened. They could easily have written the form (literally two input boxes and a submit) using plain JSP. If they had, that code would still be useful today.
I want a javascript framework that allows me to update a page incrementally, but also <i>always works correctly and contains full content</i> from the first server-side page load.<p>Are there any options for this? Are there even keywords I can search for that discuss this?<p>Sure, this files under "anything is possible", but honestly, I'd like a javascript framework that doesn't <i>actively fight me</i> also having static content. Any of these libraries that put their document derivation logic front and center are ipso facto refusing to compose well with a simple static first page load that renders fast and then gains progressive enhancement from the JS.
Great list! But I was perplexed by the text editors mentioned. Author claims to be looking at trend data, but seems to have a bias against Subljme Text editor. I don't know if there is some connection to Atom or VSCode, but it seems easily verifiable that Sublime and vim are vastly more popular than other editors mentioned, yet Sublime is inexplicably absent and vim is mentioned last and sort of offhand as more of just a tool you have to know for ssh sessions.
The only issue with the blog post is that most of those tools will be obsolete before you finish reading.<p>JavaScript as an ecosystem needs mature robust solutions rather than a new way to do things every other week.
I must be honest, my experience with node was very short but this article suggests me that working with js may be really more complicated than working with java. Too many frameworks (which often lives too shortly), too many things to learn, it's overwhelming...sometimes it seems to me that working with js has become so difficult that working with java and jquery is still easier and better (i know lot of people will throw me hate for this comment!)
Or wait another year and pick the winner of the JavaScript framework war. It's unlikely that we will see new and relevant(!) JS frameworks over the next few years as we have seen in the past. 20 - 25 years ago dozens of Windows frameworks appeared on the market. Eventually VB won. History is repeating itself.
You should check out cycle.js <a href="https://cycle.js.org" rel="nofollow">https://cycle.js.org</a>. I'm always surprised it's not THE js framework du jour.
TypeScript is definitely by far the most important thing mentioned in the article. And no I didn't even read the article. I just searched it for the word TypeScript to see what it said. However, the author apparently is pretty clueless because he implied TypeScript has something to do with Angular. It doesn't. TypeScript is needed ANY time the runtime is JavaScript. Namely, in the browser. The only other technology TypeScript has ANYTHING do to with is JavaScript itself.
Highly recommend spending at least a few hours on <a href="https://javascript30.com" rel="nofollow">https://javascript30.com</a> if you get a chance.
I'm curious what people think about type checkers in JS. I've been doing full stack development for the last few years and BE development before that. Type safety has always been worth it to me, we adopted Flow and haven't looked back, although some FE developers aren't big fans of it.
Half of the items on this list - basically, anything not under "JavaScript & DOM Fundamentals" - will probably be invalid by April 2017. :P
I'm looking for a React Admin/Dashboard template. There's various themes at <a href="https://wrapbootstrap.com/" rel="nofollow">https://wrapbootstrap.com/</a> but haven't been totally satisfied with the React offerings.
The article recommends learning both pure functions AND closure? So is the point of learning to use closure is just so that you know why you should never use it?