I hope you didn’t think I was dead 😀
One of my long term applications I’m working on is Financial.
I started it with a composition of:
- DB: MySQL
- Backend: PHP with Laravel
- UI: Desktop interface with ExtJS
Now I feel it was not the right choice to bring PHP in this game as it involves too much of a ceremony and complexity to do development with it.
I believed that doing NodeJS was premature at that time and didn’t offer enough tools to develop an application like this easily, but things have changed in the meantime.
Here are the architectural changes I had to do during this migration:
- Routing with Express (before: Laravel Routing)
- Database interaction with Sequelize (before: Laravel Eloquent)
- Session with connect-session-sequelize and express-session (before: Laravel Session)
- Authentication with passport and passport-local (before: Laravel Authentication)
- Password hashing with bcrypt-nodejs (before: PHP password_hash)
- CSRF Token with csurf (before: Laravel CSRF)
- Config management with config (before: Laravel Config)
- md5 hashing with md5 (before: PHP md5)
- XML parsing with xml2js (before: PHP simplexml_load_file)
- Input validation with validator (before: Laravel Validation)
- Platform detection with UAParser.js (before: MobileDetect)
- Shell view generation with Handlebars.js (before: Laravel Blade)
Pull Request for reference: GitHub
I’ve been using Underscore.js for quite some time. It’s a very fast, lightweight library that provides a lot of utility functions.
We all know that the latest ECMA spec is not implemented in all the browsers, but that’s why we have Babel. However, I’m optimistic that some day browsers will increase their update cycles so much that we’ll get the latest features in no time.
To get back where we were, I’ve decided to clean up the Underscore.js bloat because there were too many occurrences of _.each, _.map, _.filter, etc. which are really a useless complexity added from my point of view.
There were two big questions I’ve asked myself:
- It’s obvious that _.each/_.map/_.filter should and will be replaced by Array.prototype methods. But why not look for other replacements as well?
As a lazy (efficient) man, I’ve browsed to see if someone already did a list for these and what do you know! This article has a really nice list of replacements that I’ve used to refactor the code by replacing with native solutions.
To sum up: I don’t want to remove Underscore.js, but I also don’t want any other people to use again _.each, so what do I do?
I’ve decided to write some linting code that would fail a pull request containing code I don’t want to allow anymore.
As I already have ESLint at hand, I’ll just have a new rule that lints this.
I browsed several repos for plugins and I found nothing related to Underscore.js. But I discovered a similar ESLint plugin for jQuery.
That was my inspiration and I came up with this:
I really think that ESLint is definitely a big player in a strategy of controlling your project code’s evolution.
Hope this helps anybody out there! 🙂