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…
Take a look around. Notice anything different? Yes, the theme has changed! That’s the obvious thing, and it’s actually going to change again, hopefully some time in the next few months. There’s a lot of work being done behind the scenes for this site, so let’s take a look.
JSCharting is a capable JavaScript charting library with some advanced features and great rendering output. It utilizes SVG, though as an end user developer, you don’t need to be familiar with or code SVG. There is also some fallback in VML for backward compatibility with older versions of IE browsers. A free trial is available from their site if you wish to run the samples or follow along locally. Online samples using codepen will also be embedded below.
For a while now, people all around the JavaScript community have been declaring that it is now possible to use ES6 to produce JavaScript applications. Aside from the fact that browsers are implementing more and more of the spec, there are several great transpilers that will convert you ES6 code into ES5 code, such as Traceur and Babel (aka 6to5 which recently changed its name). Beyond that, there are more and more tools coming out to make the workflow simpler and more robust. Today is a great day for ES6!
The JavaScript development community has been welcoming new and powerful tools by the dozens each year, almost too fast for mortals to keep up with. Many of these tools come with npm packages that you can install globally so you can use the command line tool from anywhere on your computer. This can be very convenient, but is it the right way to do it? Is there a better alternative?