The popularity of Vue.js has been climbing pretty fast. It hasn’t reached the levels of Angular or React yet, but in the year that the current VueJS repo has existed on Github, it has garnered approximately 2,700 watchers (more than Angular), 47,000 stars (more than twice as many as Angular and more than 3/4 of React’s). They also have more closed issues than React and only a tiny 58 open issues (compared to over 500 for React and over 1,000 for Angular).
I’m back! Did you miss me? I missed you guys. Sadly, though I’ve gotten back into writing about JavaScript, I haven’t been doing it on this blog. But I have written three posts for other blogs and they’ve all gone live this month. I’ve also got an announcement to make at the end.
Practically all programming languages have an in-built array data type. JavaScript is no different. They store the data you need to run scripts for an application, which, from a developer’s perspective, means you’ll be writing less code, making you more productive. That’s why it’s worth knowing your way around them.
The JavaScript community is becoming flooded with articles pushing to move toward functional programming or at least more toward composition over inheritance. For a long time we’ve tried to standardize inheritance without the huge mess that comes with the verbosity of the prototype syntax, and now that we have a standard class keyword in ES2015, people are trying harder than ever to tell us we don’t need it. Those people are, for the most part, correct.
Gulp 4 has been in the works for far too long, but it’s practically inevitable that it’ll be released… some day. I’m here to help you out for when that fateful day arrives by showing you the differences between Gulp 3.x and Gulp 4 and how you can make the migration to the new version relatively painless.
We come to the final episode in this series where we take everything we’ve learned so far and apply it in a useful way by creating build systems that are specific to your projects! This allows you to hide build systems you only need for certain projects, and allows you to easily share the build systems by saving them in your project’s repository.
In the previous episode you learned how to customize build systems so they can do pretty much whatever you want, but now we’ll help you become more efficient with using your build systems by organizing them and making it possible to easily switch between different build systems with a few key presses.
Now that you’ve had your introduction to Sublime’s build systems, let’s go a step further and introduce you to some of the more useful other options available and variables to help customize your build systems on toward a life a true usefulness.
Sublime Text is a lightweight, but capable code editor that is greatly loved by many developers, but if you’re anything like me, you’re saddened a bit by the fact that Sublime doesn’t have an integrated system console. For many tasks that you use in the console, Sublime Text actually has a decent alternative: build systems. They allow you to run any console commands straight from Sublime. In this series I’ll be giving you the low-down on how to use Sublime’s build systems to their greatest potential.
In a previous article that I wrote earlier this year, I talked about eliminating project dependencies that needed to be installed globally, such as Grunt, Gulp, Browserify, WebPack, etc. Of course, I didn’t argue for eliminating these packages, just replacing the -g flag with a --save or --save-dev flag when installing them with npm install and then using npm scripts to execute the binaries. Well, there’s more…
