- Libraries
- Frameworks
- Tools
- Books
- Videos
- PostsI started with systems programming with C++ etc.. At some point some 5 years ago I made the unfortunate decision to go for Javascript. After 5 years I can now confidently say that programming in Javascript is not about what you are creating, it is about what ESxxx version you use, what framework you use, whether you're using Promises or whatever idea people come up with tomorrow, and all this in an ever accellerating and continuing hype. I am sick of it already. Almost everything I learn is already, or will be soon, deprecated.
I would recommend people to go for C++/Qt or any language/framework where what you learn will not be wasted soon so you can use your valuable time to create things rather than learn the next framework or language idea all the time.
C++ is the exact same way with a regular release schedule. You using old C++, C++ 11, C++14, C++ 17, you ready for 20? But if you know what you are doing that modern subset of the language is super nice....like JS.
I set out on the same quest and expected great pain but instead have found enormous satisfaction and success in the JavaScript ecosystem.
Along with massive pain associated with build tools.
That said, I disagree that everything you learn is getting deprecated quickly. Sure, some things change 'on the cutting edge'. But, there are tons of existing applications--and even new development--not using that stuff.
The knowledge and concepts you learn will help you keep going.
I dumped node.js on the server site like a hot potato. At the time (2014), it didn't scale well and was quite porous dealing with stuff you'd get free in a framework like django (like db-backed form validation).
But, I can't say I regret learning JS. You won't be able to do the job developing websites if you can't wrangle it. It's so ubiquitous, despite my efforts to keep a node-free codebase, I still had to cave in. Even if it's just getting your foot in the door using SCSS. Or wiring in that jQuery plugin.
Whether it's situational awareness or dealing with webpack configurations, getting that last 10% cinched is going to require understanding what's going on.
What I think people need to know about JS is that they shouldn't just drink the Kool Aid because everyone else seems to.
It's like [Obama's suits][1]. JS gives you all these little decisions you _can_ make, which wear you down. As soon as you stop caring and decide to "just pick one", you'll generally be fine.
[1]: https://www.fastcompany.com/3026265/always-wear-the-same-sui...
A C++ job would be interesting for me to take on (I have used C++ in projects mostly from the mid-late 2000s) but I need to brush up on current standards even there. Would I be at a huge disadvantage right now in most jobs if I cannot yet code C++11 compliant code?
Understand the language and how it works on a deep level. If there's ever a question of "should this work?", read the spec for that feature - it's generally not that hard to understand.
Understand the runtime. What is an event loop? What's a macro task? A micro task? How does each work? How does all of this integrate with the DOM as far as what might cause a dropped frame, block rendering, etc..?
Understand the ideas behind the framework you're using. I'm not going to recommend an individual one to avoid framework wars, but most of them embrace virtual dom these days, so you should have a basic concept of what that is. Does it make applications faster? Does it make it developing easier?. Another common framework point is unidirectional data flow; why is unidirectional data flow considered a good thing these days? What were the downfalls of bidirectional data flow?
Understand API design and state boundaries. Using the example of a shopping cart, who owns what? Where is the state of the cart stored? An individual item price? Name? How do I add an item to the cart? You can design a cart that functions fantastically, but is completely un-testable if the API is designed wrong or there is not well defined boundaries on what components own what state.
That's a few things off the top of my head.
Also, I can recommend spending some time playing with native DOM interface -- so you will understand what is event loop, how listeners are attached/detached, what is event delegation, how to traverse DOM (and what does it cost), and all that jazz.
Nowadays parts of functional programming are on the rise, so you might want to familiarize yourself with it a little bit -- https://github.com/MostlyAdequate/mostly-adequate-guide this is a good book, and fist 5-7 chapters are good enough to change your look at the programming.
This is a foundation, and without it it will be hard to write decent code in a fast and reliable manner. After that you can pick any library (whatever is needed for the jobs around you) or any framework, and try to solve your problem in it. There is not that much a benefit from just learning libraries, frameworks and tools per se, so I recommend to move gradually, and you will understand during your path what do you need better.
For example, I can tell you that Phaser is a very good library for game development (or similiarly, others that X is for Y), but that is pretty much useless if you are completely disinterested in that given area.
I might or might not be interested in game development now, but I am interested in seeing recommendations of good resources from experienced programmers.
Don't let anyone tell you Javascript is a mistake learning, because while it has its flaws so do many other languages. Learn the bad parts and then avoid them like you would any other language.
My front-end stack at the moment is:
- Webpack
- Aurelia Javascript framework
- VueJS
- Sass + Autoprefixer
As for posts, books and whatnot: those are constantly changing and being outdated, so I have no recommendations.
The problem is not the language or even the ecosystem, but the jobs. Most JS gigs are not interesting and not technically challenging. For all the noise the community makes about us being 'engineers', the overwhelming bulk of JS jobs today are just the CSS/HTML tweaking roles of five years ago implemented in 2017 technology.
Occasionally you will get to write some Node server code. These apps will usually be thin proxies over 'real' API web services and the tickets will generally be about marshalling data, waiting for asynchronous responses and handling authentication.
I have been lucky enough to do better: first an adtech R&D role (mixed bag - I hate adtech as an industry, and I loathed our rapacious attitude to people's personal data, but I had lots of autonomy and got to manage my own feasibility studies); the second was a soujourn into web VR (not as technically deep as it sounds - you might get to write a shader or two; that's it).
JavaScript development is good if you want to make decent money doing something easy, and never worry about unemployment. It is not good if you want anything else. It is not a promising field if you want programmatic challenges; if you want to build in a niche of domain-specific knowledge; if you don't like relearning basic tools because the basics keep being reinvented; if you want to be respected as more than a pixel wrangler (you get a LOT of direct requests from senior managers to swap things around etc.); or if you want to keep your options open.
That last point is important. It is quite hard to move out of front end development. The field still has a poor repuation, and because the work is generally basic employers tend to be a little sceptical of your skills. Not insuperable but definitely a strike against JS as a specialism.
I really regret not getting out of JS when I could.
Once you've built a couple of reasonably sized applications, then learn Redux.
But I recommend skipping all frameworks and do a lot with native JS and learn the prototype chain.. this will make you understand a lot more about how JavaScript works and also how JS is attached to the DOM.
Frameworks change so often in JS world!
Depending if one is good with other languages and some patterns like MVC, I really like to give someone that has 'figured out' the DOM and jquery etc pa.k. frontend in general, a push to Backbone as a JS learning framework. It's very clean and has a relative hard line between data -> View compared to Angular 4 etc. Also I think Backbone is so simple, It makes learning build flows with Gulp, Webpack etc easier. Thats not something to forget in modern JS world..
If all coding is new to a person, use Jquery only to show 'how simple it can be' and than make very clear most code written in Jquery should be considered a 'quick cheat' and does not hold any true JS revelation. Just to let them keep there eyes open and keep setting targets for themself like faster,scalable etc coding skills in Vanilla JS
I'll start with the disclaimer, as lately HN comments have tendency of becoming toxic - everything I write is my personal opinion.
With that behind us I can start. I'll try to write this for someone who knows very little about JS, but knows her/his way around basic programming/cs.
Firstly I love JavaScript, I have been writing it for 10 years now, but there are bad parts of it as well.
Let's start with good stuff
* It is evolving in the right direction
* You can do a lot of things with it (web apps, games, mobile apps, server...)
* Materials for learning are everywhere
* It will be easy to find a job
Bad stuff
* It is moving at crazy to follow pace
* There are a lot of different ways of doing same things
* As it is very hip thing to do, there is a lot of bu___hit (beware of the hype train)
Learn plain javascript before moving to frameworks. Focus on ES6 and new stuff as it will make your life way easier.
* Someone already mentioned Dr. Axel Rauschmayer, pick any of his books - http://exploringjs.com/
* Another good one is You Dont Know JS - https://github.com/getify/You-Dont-Know-JS
Try to make small app on your own. You'll get into all sort of problems, but that's the fun part I guess. That will help you to understand what frameworks are trying to solve.
Then you can start learning one of the frameworks. React, Vue, Angular are all solid choices. My pick is React, as I know it best. Apply the same mindset as with learning plain JS. Try to write your own stuff on a small scale before importing huge libraries.
Good example is redux, everybody on the internet are screaming that you should always use it, but even Dan Abramov (author of redux) has great read - You might not need redux https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Try handling state yourself, then if you see that you need big guns, try redux. Same goes for any big library or technology.
So, buckle up, do it thoroughly and try to find fun in doing javascript. And the most important generic advice - do a real pet project instead of just blindly following tutorials.
This will take some time, and if you just want enough knowledge to lend a job, pick a framework, throw yourself into the deep end and swim your way out. This is something I wouldn't recommend but it works for some people.
Hope this helps, cheers! S
P.S.
Random JS talks I like
* Wat - Gary Bernhardt, 2012 https://www.destroyallsoftware.com/talks/wat It never fails to crack me up
* Live React: Hot Reloading with Time Travel - Dan Abramov, 2015 https://www.youtube.com/watch?v=xsSnOQynTHs Classic nowadays, it is a delight to watch Dan Abramov presenting, only thing missing is a mic drop at the end
* What the heck is the event loop anyway? - Philip Roberts, 2014 https://www.youtube.com/watch?v=8aGhZQkoFbQ This is a must watch for every js developer
EDIT: Sorry for the formatting, HN doesn't support markdown
- Javascript Patterns https://shichuan.github.io/javascript-patterns/: Good for wrapping your brain around scoping and how things flow in JS. It's a very nimble language. While you won't use every single one, internalizing their concepts are central to be efficient in wrangling JS and reading other's.
- Patterns For Large-Scale JavaScript Application Architecture https://addyosmani.com/largescalejavascript/
Docs / Articles:
- Callback functions: https://developer.mozilla.org/en-US/docs/Glossary/Callback_f... Absolutely mandatory.
- Currying: https://www.sitepoint.com/currying-in-functional-javascript/
- 'return this' for method chaining: https://schier.co/blog/2013/11/14/method-chaining-in-javascr...
Annotated Source:
(soak these in 10-20 minutes every day over a month or two)
- http://backbonejs.org/docs/backbone.html
- http://underscorejs.org/docs/underscore.html
Frameworks:
- None. Webpack 3 + jQuery + babel + pjax
Tips:
- The longer you hold off on a framework, the better. Focus on getting your stuff out the door, test coverage + CI feedback loop, core business data schemas, and trimming off technical debt. After a couple of iterations and months of stability, consider a/b testing a framework.
- Most libraries are still in ES5. Wrap your brain around ES5 is a sure thing. Not everyone is using newer JS features.
- In many programming languages in your webstack, you're likely going to be dealing with node for build utilities and compilation.
- Webpack, while it seems unintuitive at first, can be pretty nice once you get over the hump. It's like a miss of the old r.js configs and the declartive-ness of grunt.
- As a parting note, don't feel a necessity to buy into single page application and frameworks. They're a tremendous time sink and the ROI just isn't there.