Yeah, it was only a few lines of code back then, but today entire web apps are built around it ((frontend and backend). Thats’ pretty insane for a language that hides your errors until it meets the user’s browser.
Coding without a compiler is super hard so I do my best to keep the code as simple as possible. This becomes challenging as the codebase grows and more developers are added to the team.
Here are some libs and tools my team and I already use today:
Backbone keeps everything in its place. It’s an MVC framework (sorta), but the important thing is it breaks your code into reusable modules.
I have much more to write about keeping backbone code ticking well, but I’ll keep that for a future post.
Requirejs breaks the code into modules and maps the dependencies between them.
I once hated requirejs. It just wasn’t working for real projects. Version 2 changed all that and now I have no idea how we maintained the project without it.
We use it to break the project into logical files. Each model, view, router, whatever gets its own file (Like a “real” programming language).
It also allows to easily port modules from one project to another without going insane.
Requirejs comes with the r.js optimizer that can concatenate your entire project into one file (and much more). This usually makes your code load faster.
A side effect of optimizing is the detection of typos and lowercase/uppercase issues while loading your files. Better now then on the user’s browser.
SourceMaps with UglifyJS
We use UglifyJS(2) to minify the code after the optimization with r.js. There’s a great feature that allows to generate source maps.
This maps the minified code to the original code. When faced with a bug in the real world, Chrome lets you debug it like it isn’t minified at all.
Think of all the bugs happening in the browsers of your users. You just have no idea about them. You’ll probably want to catch uncaught exception and report to your server.
We rolled out our own solution for that, but then decided errorception just does it better. Bugs will be collected with their stack traces and.
We love Sublime Text, but WebStorm is the winner for larger projects. Yes, it takes forever to load, but once it does, you get so much benefits out of it.
It understands your code, shows you warnings and errors and has great Git integration. History and blames are a click away and it has a wonderful merge tool.
Oh, we also use it to debug the node.js code and it’s surprisingly good.
It’s already baked into WebStorm, but for some reason it’s not on by default. Enable it from Preferences and you’re good to go.
Jasmine + Phantomjs
Unit testing isn’t always easy, but with Jasmine and phantomjs it becomes pretty simple.
We found out it’s more reasonable to test the models. It’s a good idea to keep the data-logic inside the models so it could be easily tested.
We have a lot more to learn about testing our code. The main thing I’d like to do is add it into the IDE and we’ll probably migrate over to using Karma in the future.
We configured Jenkins to “build” the project after each commit. Yes, “build” is a weird concept for a dynamic language, but we do transform it with the r.js optimizer, minifying with UglifyJS(2) and add some extra pulp.
The build process also runs the tests on each commit and fails the build if the tests are broken.
Once you break the build, Jenkins will email you and ask you to fix it.
Are we missing anything obvious?
I’m probably only touching the tip of the iceberg with these libs and tools.