JavaScript: The Right Way

I left my web agency role over a year ago to work on my start up with a friend so I've been in relative developmental isolation (lots of python and js, not so much keeping up with the latest trends). I came back to help out on a project recently and had to spend a day researching all the new tools. Particularly around package management, bower, grunt, yeoman, node, npm etc. A year ago a js lib was generally delivered as a js or min.js file. Now there's the whole system to sit around it; every project on github now seems to include the config for each of the different package managers. Even a vagrant file so you can get it all up and running on a brand new vm.

Something as simple as adding bootstrap to a project. It's not totally obvious when you first look at it. Where does the code go? How do you compile it in such a way that you don't touch the vendor src itself but you can customise it etc. I have a method that works for me, but I had to play around a little to figure out how to fit it to my needs.

Once I got through that stage I was really happy with where things were at. JS libs are nice and easy to install and version control now, dependency management with bower has worked really well for me so far. Grunt makes the automation side of development nice, contained and easily shared. All in all it's a really good transition.

I'm lucky in that I've been developing for the web since people were changing files in ultraedit and ftping to the live server to see the changes. When each new thing comes along I only have one new thing to learn. Step away for a year and suddenly there's a lot to figure out to get back in to it.

I can only imagine how daunting it could be for a complete newbie trying to find their way.

As ever these tools can be great, but you ultimately you really want to understand what goes on underneath so they don't limit you too much. Amazing talk on this subject posted by another HNer in a comment the other day - https://www.youtube.com/watch?v=ShEez0JkOFw

While there have been attempts to compile a language like Python down to native code, they are still very limited and not useful in a practical sense. Hence, Python is a de facto interpreted language, since its usable implementations are implemented as interpreters.

The same goes for JavaScript today. Given that all of the usable implementations are interpreters, JavaScript can currently be considered an interpreted language.

Not sure the cause, perhaps the influx of engineering "computer science disciplined" brains into the frontend world. Or a panicked competitive race to achieve a nirvana dev environment. Or a tendency to think that workflows for large websites with countless modules is the best workflow for a one-page web app.

Overkill for the intended task, or cluttering your project with too much technology, is the thing to watch out for in the frontend aspect.

Layers of tools and libraries and plugins can easily get out of control and beyond a joke. Don't forget you've got a web app to build while you mess around with the "right way" to build it.

You do not need a cup-holder on your scaffolding.

Just using plain JS with Jquery, and perhaps some additional smaller specific plugins/libraires, is enough to do a lot of cool stuff if we're talking "javascript" projects. Then just get a good editor and off you go.