Its fairly long, for an essential list. I was going to count them, but I decided I didn’t have the patience. So as estimations go, as far as a page search for “grunt-” gives you, there’s more than 70(!).
And this is assuming you even know what Grunt is or even use it. The short version is that its a task runner - something that helps you run or automate common tasks.
Now, do you need this for JavaScript development? No, but its not an uncommon tool. One of many not uncommon tools you see being used with modern JavaScript development.
Given that, how many of these tools or other frameworks do you need to be acquainted with to be on top of things for today’s JavaScript development? This list makes the answer of that question very intimidating.
What does everyone here use - if anything? Tools? Frameworks? And when do you decide on when to use what?
Yeoman
Grunt
AngularJS
Ionic (if I am building a hybrid app for iOS/Android/Windows)
Atom Code Editor
Yes, this is very complicated. No doubt about it. Sometimes, I might have to use either Bower or Gulp depending on what a particular project has been configured with.
The thing that most of these are CLI-based tools adds to the complexity…unless you like that sort of thing!
The wider web development community lacks consensus on the development workflows it wants to support. The more people you develop with, the more likely it is that you see that lack of consensus result in differing development workflows, leading to debates or disagreements. My opinion is that if your requirements are clear, and you’re working by yourself or with people with whom you work well, JavaScript development is pretty enjoyable and straightforward. You two have more experience working on larger projects+teams at your jobs than me, however, so you may be seeing different pain points.
I use TextMate and a terminal, plus Transmit if I’m working on a remote filesystem. I use plain JavaScript if I’m writing library-style or server-side code, and a mix of plain JavaScript and jQuery for browser code.
I’m with krilnon as far as most personal projects go:
Plain JavaScript
JQuery if working much with DOM
But they also don’t tend to have much depth to them. I also like using (which if I remember right krilnon does not):
CoffeeScript
But I’ve been considering jumping over to using more ES6 with things like 6to5/Babel, especially when it seems like ES6 replaces much of the need of CoffeeScript.
At work its a little different, and scattered. It depends on what you’re working with, the team, and who’s on the team, and who on the team thinks what works for what you’re doing… There I’ve worked or am working with:
JQuery (pretty exclusively)
Angular
Backbone
Lodash/Underscore (Backbone packages underscore)
Node/NPM
Express
Mustache
Mocha
Grunt
Sass
Browserfy
There’s more but those are the ones that you tend to kind of see first hand and affect how you develop.
I guess something that sticks out in my mind about this stuff is that for a lot of these to work well, you want to be using other things, like NPM or Grunt to keep them from being inconvenient, especially for things that don’t work natively in the browser like Sass, or any other kind of transpiling.
Yeah, you remember correctly. CoffeeScript has significant indentation, so it’s almost immediately ruled as a language I’d superficially like. I’d much rather use Ruby if I were after CoffeeScript’s conciseness.
(I spent a year or so using Python professionally and I’m still not content with significant indentation.)
And yeah, the depth comment you made is pretty on-point. They aren’t really big languages and you tend to quickly fall into a small subset that you like for a particular task.
This is my biggest sticking point for new client-side web languages. As much as they’re conceptually sound, I vehemently resist using transpilers in my own work. I used XSLT, but browsers supported it (even IE 5, I think), and it was great for a time. I use any ES6 features (or ECMAScript 2015 as some are now calling it) that engines natively support, like node --harmony or Chromium --enable-javascript-harmony, but I won’t use transpilers to get that support. It’s probably an ideal I’ll eventually have to cede, but not yet…
Randomly we got XML training at work (when our jobs did not require it) and it included XSLT. I didn’t even know about it then - or at least what it was if I had heard the term. I loved it. I thought it made sense and fell in line with what was trending on the web. In fact I’m surprised it didn’t catch on more. But I think support wasn’t great, and there were a number of browser bugs that just weren’t getting addressed. In fact the starcraft website was built with them but eventually they moved over to HTML (maybe they converted to rendering server side)
Honestly javascript hasn’t really changed much what has changed is what and how we use it to do much more than it was ever conceived to do in order to have more “efficient” workflow.
What has gotten harder is to learn all the different conventions libs like Angularjs, Knockoutjs, Reactjs, Ember, Node etc. bring to the language and having it work/co-exist with jQuery, vanilla js or any of the aforementioned libs.
Personally I still use jQuery and vanilla js since it does the job and does it well in most cases.
I’ve tried implementing Node, Sass and Gulp but the learning curve for others on my team who don’t really understand css well has prevented me from moving forward with it. When you have deadlines sometimes it’s better to stick to tried and proven than go out on a limb and experiment with shiny new libs and/or frameworks.
At the end of the day javascript is as complex as we make it for ourselves, none of these so called essentials are mandatory to do anything with js but they might help do things faster.
This. I would bet doing a small, intense training day (or two) to get the team up to date and on the same page with this stuff might be worth it and pay off in the long run (though I know this is a lot easier said than done). Deadlines always find a way to get in the way.
I think adoption (and maybe this is obvious) can be attributed largely (or at least partially… ) to the learning curve. A lot of the intent of these things is to improve speed and ease of development, but how much is there to learn to get to that speed? How big and invasive is the API? Is it too intimidating for new users to want to try to learn? You see things like google’s auto awesome for images. How auto awesome can some of these tools be in making them easier to use by people/teams that might otherwise cause pushback?
I wish a day or two will work, it really depends on the level of competency of your team there’s a lot of moving parts. Think about it just to get Sass compiled without Ruby you need to have Nodejs installed, know how and which NPM packages to install (gulp-sass/grunt-sass) then configure these to read/compile to the right directories.
This does not cover minifying/concatenating or sprite generation those are separate NPM packages, all this just to compile a Sass file which they need to also learn how to write if they don’t already know it.
It’s really hard to be on top of all the new libs and frameworks when they impede your team to work effectively, don’t get me wrong I love the way we have progressed but not everyone has the drive, passion or time to continue learning all these things while also staying productive and meeting deadlines.
I’ve had this discussion with my team many times and time is always a factor so if you want something quick that needs to meet a tight deadline then we stick to what we already know, if we have time to explore and do some POC’s (proof of concepts) then we can play around with some of the new stuff.
Sad thing most of the time deadlines are there and we never get to use all the cool new shiny tools and toys, I think every company who has a dev team should invest in having a day or 2 of training or run a meetup group to foster collaboration and discuss new stuff the team would like to learn in order to stay current.
After all your employees are an asset we need to look at this as an investment not as an expense, once companies realize this not only will they have better and more skilled employees but I’m sure they will retain a lot of them because they are fostering them to grow.
We have one guy which manages the packages of our projects and to get started it’s basically have node installed, pull down the git repo and run this command you copy and paste from the repo readme. Even if you don’t know what’s going on, if you can follow instructions, you can get everything installed and up and running. Then it’s just knowing how to write the code where it’s different (sass) and maybe a command or two at the right times, again which you can do if you can follow instructions.
I think the hardest part (aside from team ramp up) is getting this integrated into your work flow if you already have an existing process in a place. Depending on what you’re working with, and how far in you are, this can be complicated.
Yeah that’s one thing I like about this workflow with node you just do npm install and it will install all the packages from the package.json file which is great for a team setting since it assures everyone will have the same setup unless they do something stupid.
Another huge factor is what code editor you use, we use VS which is slowly adopting all these new “workflow” options but most of these really weren’t made with it in mind so that doesn’t help either.
Yeah I’ve been struggling with some of the editor stuff (though I guess I’m using “struggle” lightly). For instance I lint automatically as I write through the editor and keep the code error free… until someone else checks in and I get changes which are full of errors (not logic, but small things the linter doesn’t like) which is when my OC kicks in and have to fix them. Honestly, who leaves a trailing space at the end of a line! Are you MAD??
… but, miraculously, we have managed to keep indention consistent between everyone which, despite it being with spaces, is an accomplishment.
And though I don’t think I’ve said it yet, I think ES6 on the whole is too complicated. There’s a lot of nice, convenient features, but I think it complicates the language to a point where if someone new to the language (or programming) were to look at ES6 code, they’d be far more confused vs ES5. Destructuring, for example, I think adds a lot of confusing syntax. Arrow functions too - or there being 2 new function syntaxes for that matter (does that make 5 total now?).
function namedFunction(){}
let anonymousFunction = function(){}
let namedAnonymousFunction = function name(){} // arguably not a whole different syntax
let fatArrowFunction = _ => 0
let fatBodyArrowFunction = _ => {
// arguably not a whole different syntax
}
class Klass {
methodFunction(){}
}
let objectLiteralFunction = {
objectMethodFunction(){}
}
I was thinking named, anonymous, arrow, class/literal, and finally I was thinking of new Function('body') too, but that may be considered more API than syntax.
name-anonymous can probably be considered different in that behavior changes. In that case the named function is not defined by name in the parent scope though it is still accessible by name in the function body.
let namedAnonymousFunction = function name(){ name() // OK }
name() // FAIL
(edit: maybe this is a stretch)
Digging more into it, you could consider anonymous in object literals different (assigned via : vs = ). And there are those pesky getter setter methods too.
So as estimations go, as far as a page search for “grunt-” gives you, there’s more than 70(!).
) to the learning curve. A lot of the intent of these things is to improve speed and ease of development, but how much is there to learn to get to that speed? How big and invasive is the API? Is it too intimidating for new users to want to try to learn? You see things like google’s auto awesome for images. How auto awesome can some of these tools be in making them easier to use by people/teams that might otherwise cause pushback?
which is slowly adopting all these new “workflow” options but most of these really weren’t made with it in mind so that doesn’t help either.
). And there are those pesky getter setter methods too.