101–110 of 163 posts
Hmm, i don't see much difference in configuration between grunt and gulp. Both do the job. And Performance? Which Performance? They call tasks that do something, and the task need performance.
The one thing that keeps me from using browserify or webpack or the likes, is dev time debugging. It's not very useful to find that line 13729 of script.js threw an exception. Source maps may help, but many browsers don't support them, and I want to be able to debug everywhere. Plus, when the browserified js actually came from Coffeescript or TypeScript or the likes, I already have source maps in place. Can browserif…
Unable to find the link/name at the moment but there is a method (it isn't vanilla source-map) for this which basically wraps the modules into self-executing functions and it shows up in Firefox and Chrome as distinct files. It was related to source-map but not However, I have found Chrome and Firefox's support to be buggy.
function hello() {
console.log("hello world");
//# sourceURL=hello.js
}
I've been using a different strategy lately: no explicit build process at all, just use middleware (like browserify) to automatically compile/compress/concatenate, and an HTTP cache in production to store the results (either middleware, or external such as nginx/Varnish/CloudFlare/whatever). This helps with the principle of minimizing divergence between development and production environments. It's worked well for me…
This worked fine for us for a year or so. Now, I sometimes need to change stuff when there are a couple thousand online visitors on one of our sites. Their requests gang up on middlewares and causes duplicate compilations. We already have reverse proxy servers to keep duplicate requests waiting for the first one but that still leaks due to different browser capabilities and stuff. Having everything prebuilt makes mor…
Also, there is already an effort going on towards finding a generic API for node task runners at https://github.com/node-task/spec/wiki
This is a tangential question, but how do front-end people feel about the constant change in the field? I worked in the front-end and followed the trends for years and have found the changes difficult to follow. In 1997, the rage was VB and lots of cottage companies set up and advertising custom ActiveX widgets, on the web one had to learn ColdFusion and HTML/CSS. In early 2000's, VB6 was retired in favor of .net and…
For this OP, the move from grunt to gulp for instance is a simplification of the build process. It requires some refactoring of the build process, but shouldn't impact the application code, the two libraries can coexist (not cooperate I guess, but at least you can set up both and use one or the other as you want), and can be tested with simple use cases first and expanded to the whole app afterwards.
The barrier to entry is low, it doesn't require much commitment and can be done on the side. I'd try to keep up as much as possible with new available tools, as long as they match the above criteria.
For libraries and frameworks closer to the UI and application structure, I have the feeling they generally need more time to pickup, learn the strengths weaknesses, deal with the quirks and bugs. Even with reasonable documentation, most of them seem to need at least a few dives into the source code to really get how they work and what they expect to be doing.
Trying Ember or Angular on a somewhat realish project takes enough time to make it a chore to try a few alternatives, I'd guess most devs would want to wait months or years to see which libraries die in infancy. I think for this space, trying more than one or two picks here and there a few months apart is just insanity, except if you really enjoy it or it's part of your job. As time goes by I feel the timespan I wait for something to see if t sticks goes longer. I remember a Jeff Atwood post [1], about how ruby is now mature enough to be taken seriously.
I think the same thought process can be applied to big enough frameworks.
Personally I'd tend to go for the libraries that are simpler or with the least 'magic' to avoid getting in situation where I invested weeks doing something and there's bug I don't know where it comes from and need to spend days on it because of the amount of abstraction going on. That's a way to mitigate risks when trying out random libraries.
This is a tangential question, but how do front-end people feel about the constant change in the field? I worked in the front-end and followed the trends for years and have found the changes difficult to follow. In 1997, the rage was VB and lots of cottage companies set up and advertising custom ActiveX widgets, on the web one had to learn ColdFusion and HTML/CSS. In early 2000's, VB6 was retired in favor of .net and…
Full-stack dev that came up through the front-end ranks here - I'm in my early 30s and have been doing this in some form or another for 17 years. I started with Perl and C CGI scripts, worked with Java Swing (on the desktop) for a while, had a brief foray into MFC, did a whole bunch of PHP in college, switched to Django/JQuery while working on my startup, and now use a whole bunch of Google-proprietary techniques alo…
Earlier quoted context omitted.
Full-stack dev that came up through the front-end ranks here - I'm in my early 30s and have been doing this in some form or another for 17 years. I started with Perl and C CGI scripts, worked with Java Swing (on the desktop) for a while, had a brief foray into MFC, did a whole bunch of PHP in college, switched to Django/JQuery while working on my startup, and now use a whole bunch of Google-proprietary techniques alo…
I agree with all but will point out that a benefit to a framework or any extensible tool is community contributions and opting out to native means that you don't get that benefit. That being said, when javascript ES6 modules land it'll be much easier to reuse code and dependency on big libraries would be unnecessary, meanwhile you can use Browserify or Component that have a lot of community contributions with minimum…
No. The goal is to find the right abstractions - the right libraries/frameworks/patterns etc. If your tools end up costing you time then the tools are flawed - not the concept of using tools.
Earlier quoted context omitted.
There's a few things going on here that combine to cause this mess. First, task runners, like templating systems and module bundlers, are easy to write so there are lots of them. Grunt in particular doesn't bring anything to the table that bash scripts don't. Second, most open-source projects don't make their value prop clear (I learned this the hard way first-hand and I'm still dealing with it) and most people don't…
> Grunt in particular doesn't bring anything to the table that bash scripts don't One thing that comes to mind is cross-platform builds, which in some scenarios is very useful.
Grunt is the "JavaScript Task Runner" and Gulp is "The streaming build system"
There is not much point in using grunt for building or gulp for running tasks, IMHO.
My team is moving towards using gulp for js/css builds and make for tasks. We used grunt before. We probaby should use npm for tasks, though (cross-platform).
Is anyone else thoroughly unexcited about all this playing in the sand? We're building products; why do we spend so much time and money on build tool churn?
I avoid build tools whenever possible (using built-in build commands and things like compass), but when I do need a build, I just use Rake. My toolchain stays the same so I can get shit done.