Best frontend tools
over 8 years ago from Johnatan Matos, UI Designer
What do you think? Which one do you use and why?
over 8 years ago from Johnatan Matos, UI Designer
What do you think? Which one do you use and why?
Sass for a CSS preprocessor Bourbon for a Sass mixin library Neat for grids Jekyll for a static-site generator Grunt for automation and tying your development environment and workflow together LiveReload for browser auto-refresh when changes are made to files (Grunt has a plugin grunt-contrib-watch which allows you to tie LiveReload into Grunt)
Of these, Sass and Grunt are probably the most valuable to me. Sass makes writing CSS a breeze and being able to organize my code by breaking up my project into components/modules/pages is valuable, especially to be able to reuse components and modules on other projects.
Grunt is another tool I almost always try to integrate into my project. It speeds up and ties together all of my development tasks by handling many of them simultaneously or synchronously. For example, I type
grunt build and it builds my Sass, concatenates my JS, builds Jekyll whereas if I type
grunt deploy:production it builds my Sass, minifies the CSS, concates my JS, uglifies it, builds Jekyll, deploys my sites to my server with Capistrano. Grunt can be seemingly tough to get set up at first.
I wrote a blog post Get Started with Grunt that may help anyone interested in integrating Grunt into your workflow.
Bourbon is so unnecessary these days. If you're already running Grunt, you should look into Autoprefixer. Even LiveReload with its silly browser extension should be replaced by BrowserSync.
Unless you need it for Neat, Bourbon's usefulness is seriously reduced these days.
I partly agree and do find Autoprefixer valuable, but primarily those worried about covering vendor prefixes.
For me, there's a lot of Bourbon I use that aren't vendor-prefix specific that Autoprefixer doesn't offer. Adding another step of compile doesn't add value for me—it'll actually take away by tacking on more time to every compile, and with thousands of times I compile in a week, that's lost time.
Now BrowserSync, I have heard mentioned but haven't given it another thought. I'll definitely take a peek at it and may replace LiveReload! Thanks for the heads up on it.
I do still have Bourbon in the big project in my plate, but like you, I have it for the non-prefix things. I'm using it for the triangle and something else that I can't remember off the top of my head. I do plan to refactor these things at some point post-launch and then pull out Bourbon.
I've found that lately, some of the prefix stuff in Bourbon is more trouble than its worth. Autoprefixer is a huge help with Flexbox, but I've found that Bourbon has some pretty ugly bugs in its Flexbox support. I've had to manually write a few Flexbox styles to augment the prefixes because it doesn't give everything you need to cover all browsers. Just something to be aware of.
Is BrowserSync a drop in replacement for LiveReload? I currently use LR for everything and it's kind of a pain in the ass so I'm pretty curious about alternatives. I checkout out the BS website and their explanation of the product is a bit weak.
Edit: They have a much better explanation of the features here: https://github.com/shakyShane/browser-sync
The browser extension for LiveReload isn't required, you can inject the JS snippet yourself.
BrowserSync does look interesting. I'll have to try that in my next project.
I disagree. Bourbon has it's place, unlike Foundation or Bootstrap uses @mixins so regardless if there is a million lines of code that you can use, it's just that, you can use as it only pulls in what you are using. It's also especially good for people that use Hammer or Codekit
This to me is the perfect workflow. I use Bourbon along with Susy and my own selection of @mixins in my own framework which leads to a very speedy workflow.
Thanks for your explanation and your blog post. I've been clueless about the usefulness of Grunt and now it sounds like something I should be using!
Stop where you are and go with Gulp. Trust me. Way easier to learn. I spent way too much time configuring Grunt.
Or you can use roots, which includes all of these things plus deployment out of the box with very little configuration and no mess.
Caveats: It's still in beta although rather stable, doesn't support ruby so you have to use libsass or the equivalent stylus stack (this is the better option), which is axis, autoprefixer, jeet, and rupture.
If this interests you feel free to reach out to me. We use this for large production apps at my company and it works great. We just haven't quite got all the docs and marketing materials together and have to iron out some bugs on windows so we're calling it beta still.
This is also shameless self-promotion, but its all open source stuff that I'm not making any profits on and just want to share with people to make their lives better, so I feel like it's justifiable.
I prefer Gulp to Grunt (super fast, code vs config, etc...).
After integrating Autoprefixer, I've found the need for Bourbon less and less. Autoprefixer comes in Grunt and Gulp flavors and is super easy to integrate, especially if you're using a preprocessor anyways. It also integrates with Can I Use so you can set the level of browser compatibility in your code.
I only agree if one is solely worried about vendor prefixes. Bourbon offers more than vendor prefixing, and there's quite a bit of Bourbon that I use that Autoprefixer doesn't offer. It's also a requirement for Neat, which I use, so it's something that goes in tandem. If I'm using Bourbon, there's really no need to add Autoprefixer to the mix during development (maybe for testing), it only adds extra time to my compile.
True, and Bourbon has some great convenience mixins that I occasionally fork.
However, the issue with using Bourbon for vendor prefixing is you're on Bourbon's schedule for pushing updates/fixes for vendor prefixes and vendor support.
Say you need support for an older version of Safari which relies on a weird variant of a
-webkit-* prefix. Autoprefixer allows you to set what level of support you want (backed by Can I Use), while with Bourbon, you're stuck on if they want to keep support for the prefix, are forced to use a later version, or have to fork and add support yourself.
I'm not trying to bash Bourbon, I love it and still use it, but you're really at its mercy for legacy support.
Also, if you're having issues with compile time, I highly suggest you look into LibSass and possibly Gulp.
+1 Gulp is amazeballs.
+1 for your Gulp endorsement -1 for your use of amazeballs
CodeKit. Automates the whole process of combining, minifying, etc CSS/JS files and browser refreshing. With the built-in server, you can view the site you're working on on all your devices at once and they auto-update as you make changes. You can do the same with Grunt, but CodeKit makes it dead-simple and you don't need to mess around with the command line. Can't say enough good things about it.
Codekit is perfect if you're a lone wolf or if you're just throwing together a quick one-off. But once you need to be working with a team, its value decreases. The most obvious reason being that everyone needs a Mac. Secondly, assuming everyone has a Mac, they then need to purchase a Codekit license. Then, they need to actually start up and run Codekit.
It's not at all complicated to set up Grunt or Gulp to handle Sass and BrowserSync. The tools are free and cross-platform, and everything is automated. Front-end developers shouldn't be afraid of the command line in 2014.
How does a team handle dependencies? At one point I remember messing with Grunt/Gulp and came to the conclusion that it was a pain to use across teams but maybe I was mistaken. I liked the idea of Codekit because it manages all the frameworks & configuration for you, all shared in a config file.
Well Grunt and Gulp are both Node so your project should have a package.json (it'll keep itself up to date as you add dependencies). It gets checked into source control with the rest of the project.
npm install is all it takes to install them.
When you install a package be sure to use
--save-dev to have it automatically added to your
Lol, I wish Grunt was easy for me to install. I'm heavy on the right-brain side (design/UX). I've spent two months trying to install and use Grunt for my dev. Maybe there should be a "Install and Use Grunt for Designers" article.
What part are you having issues with? It's basically just installing node and then installing with npm install -g grunt in Terminal.
Lol, thats where I'm stuck at. I always get an error. I don't want to toot my own horn, but I'm like Lebron James in researching/learning. But damn, learning development outside of Presentation jQuery may be the hardest thing to grasp. Its like the 4th quarter of the NBA finals against the Spurs.
If there was a tutorial (site) on JS stuff, as similar to Photoshop tutorials, with pictures, lots of definitions on keywords, etc, that would be great.
Im the guy, where I'm talking to developers about how to learn certain things, and about 70% of stuff goes over my head. I spend more time going into logistics about the definition of a "non-blocking I/O model". The most I know in coding is about 13 years of HTML & CSS. Then about two years of presentation jQuery. I also know SLIM/Sass/Less, using Codekit though.
The hardest thing about Grunt is getting it installed for sure. In theory, it's as easy as npm install -g, but whenever I'm trying to walk other devs on the team through installation something always goes wrong. Then, we start the hour-long back and forth where it's like "Okay, try sudo. What does it say now?"
Ya, Grunt is easy once you get it all working.
Try Gulp instead. I find it's much easier to grasp and set up. Ignoring what's going on under the hood, the biggest difference between Gulp and Grunt (from your perspective) is that with Gulp you're writing code and with Grunt, you're writing configurations.
Try this article to get started.
Instead of starting with a monolithic gulpfile.js, try building a basic one and then adding additional tasks and steps to each task.
Try this: Create a basic gulpfile that just compiles Sass. Run it manually each time with the
gulp command. Then add a few steps to your Sass task (minify, report size, notify you that it completed, etc.). Then set up a watch task that runs the Sass task. Now it will keep running when you run
gulp and compile it whenever you make a change. Then, add a BrowserSync task and add it to the watch task.
Keep searching on gulps.com for more useful things that you want it to do. Just start simple and go from there.
Did someone say, "Grunt for People Who Think Things Like Grunt are Weird and Hard" by Chris Coyier?
It's not a matter of being afraid of the command line. I just prefer having a simple UI to handle everyday tasks.
$29 for CodeKit is actually a pretty great investment. Probably pays for it self in a few hours of work by streamlining setup and workflow.
Different strokes for different folks.
It's true that free, open-source and automated tools are terrific. But you're listing the $29 license as an obstacle to use? I find that hard to believe. And how is "start up and run CodeKit" any different than telling a folder to watch for file changes? It's just a few keystrokes in either case.
Front-end developers shouldn't be afraid to pay for great, cheap, professional tools in 2014. Especially those that are fast, easy, well-supported, and remove a lot of complexity so I can focus on solving the client's problem, not on tweaking my workflow.
PS. I'd list cross-platform as a con, not a pro. No really great software has ever been cross-platform (with, maybe, the exception of games and command line tools, which I'll concede -- I'm speaking of GUI applications).
I use Codekit and yes I am a 'lone wolf' if I worked in a team I would seriously swing towards using Gulp. I've looked into it and whilst I'm not a fool I just can't seem to get along with it and whilst I have a superb workflow using Codekit I just don't see the point and upheaval but yes, you are 100% right.
Any team should be working with the same resources and be in sync.
Plus one for Codekit, I absolutely love it. However, I do wish it could be integrated with Grunt as I use that quite a bit. It would be nice to, say, run a grunt task as a rule with certain file types (or in the 'Hooks' section of CodeKit). As far as I know this can't be done, and I tried and failed, but if anyone has done it let me know how and you'll make my day.
I'm using http://flexible.gs because flexible, powerful and easy.
You are unbiased, right?
Very. 4, perhaps even 5 lol
I am biased, but –
I've been using Respre, a tool I created a few weeks back to help me preview the design for my next project, before I code it.
I set Sketch up to export directly to my Respre preview folder by renaming the default responsive web artboards to the resolution I want to preview them at ('1024' for the big one, then '768', '414', and '1'). Then, I'm just a ⇧⌘+E , ⏎ , ⏎ away from checking my designs in the browser.
Wow, this is great!
I'm always exporting png's and dragging them to Chrome to see how they look like, so this will make my life much easier.
Thanks man! I'm glad it's making your life easier!
By the way, you should get it on the Sketch Toolbox repository so people can pull it from the client!
Did you submit this to DN? It's pretty awesome.
I did! But it didn't get too much traction.
If you're finding it useful, please spread the word! Thanks for the kind words.
Dude. this is awesome. I'm about to email you about something related to this :)
I am using Grunt or Gulp for development in frontend. In combination with Yeoman (yo cli tool) it's very nice and you are no longer needed to write those long Grunt- or Gulpfiles. You should definitely have a look at them.
EDIT: Also there are many advantages over tools like CodeKit or something.
many advantages over tools like CodeKit or something.
Yes! Any system that can run node can use Grunt unlike Codekit or Prepros. Also you can have your Grunt configuration and plugins in your version control. OTOH, it is much harder to use.
+1 for grunt
What Gulp packages are you using?
Not OP, but these are the plugins I typically install as a base:
No offence but if you use Bourbon just for prefixing CSS then you shouldn't use it at all. It's much more than that, instead you could use a @mixin for this if you wouldn't have the gulp plugin available.
Yes, Bourbon has some nice convenience mixins, which I sometimes fork, but a majority of its docs is just prefix support.
I like Yeoman a lot, but I find the present state of the generators to be sort of lacking.
I've had to write my own generator to accommodate my workflow (Sass via compass / Bower / Gulp).
It would be cool if someone wrote a quick Generator generator, aha. Like if you could choose which components you want to use, and then custom file/folder paths and it could output you a Generator to run.
Yeoman is the bees knees, I seriously cannot recommend it enough. Every project is a bit different and yeoman provides a painless starting point while including just the tools you need. +1
I'm having a lot of fun with Brackets right now.
<3 Brackets. I've been using it since Sprint 12 (the first public sprint), and have loved it the entire time. 10x better than Atom.
How does it compare to Sublime 3?
Sublime and atom are language agnostic.
Sublime especialy is so flexible you can use it for almost anything.
Brackets is starting to be pretty great, because it only focuses on frontend. It does also some tooling and that used to be messy if you use gulp/grunt. But it has some fancy features like livehtml basicaly live everything with developer tools embedded inside the editor. Its also good time to try because it accidentaly hit 1.0 like a week ago.
For me in the end sublime with its speed and all the great text editing tools wins. But not by much and since its development is basicaly stopped. I wouldnt be suprised something like Brackets will be superior editor soon (they are adding features at realy fast pace).
Hmm, having tried a bunch over the years, I think I'll go with:
Those I would consider specific tools, but if syntactic sugar is also considered tools then:
Stay sharp! :)
What gulp plugins do you use?
Oh, a bunch, some more than others depending on the project.
And a lot more, boring ones :P
I'm a designer rather than a full on front end specialist so I'm a little later to the party than those who specifically do front end dev but I have found getting into using Grunt extremely useful for my workflow.
Live JS / HTML & SCSS editing.
I constantly strive to optimise my workflow for reducing cycle time. It's a great indicator for UI & product design quality.
Nice mix. I've recently started learning Webpack, do you have any repos/links you've found helpful?
Bundles webpack in an easy to use way with React.
Thanks for sharing these. Takana is blowing my mind. Can't wait to check out React and the others.
Only one mention of Bower in this thread so far. I find it a super helpful tool for client-side dependency/package management in my apps. http://bower.io/
Just a few I use on almost every project
+1 for postman. That helped me a lot in the previous project.
I didn't know dploy.io, thanks for sharing.
This thread needs to know that it's "Sass" not "SASS" :)
I do most of my front-end work using Middleman (a static site generator) with SASS / HAML.
Also, the gem middleman-gh-pages helps you to easily deploy your website to Github Pages.
Have you ever used Jekyll? Would love to know how they compare — Middleman seems more powerful from the looks of it.
I've used both. Middleman is more flexible, Jekyll is great if you want to get a static blog running very quickly, but Middleman's blog plugin also handles that.
My typical Middleman setup includes:
All of which is natively supported or as simple as including additional gems and configuring the plugins.
Middleman also has the asset pipeline from Rails which makes it incredibly powerful, especially when paired with Rails-Assets.org so you don't need to copy-paste external libraries into your project.
You pretty much solved all my workflow issues.
Thanks a ton, will save this for later!
Pretty awesome list you posted here. Gonna try some of that stuff, for sure :)
I tired Jekyll once but at that time I was way more fluent in Middleman already, so felt no need to dive deeper into Jekyll.
Brunch is where it's at. If you are using Grunt/Gulp, this is way easier.
I use TextMate, Opera Developer, and Sass. On Windows, I use Notepad++ in place of TextMate.
Check out Brackets or Atom. Tons better than Notepad++.
I used Brackets when it was first released and didn't like it. I'll check it out again though, looks like good progress was made.
There has definitely been a lot of progress made in it. I hope you'll like it.
Gulp - Better than Grunt and has a large growing ecosystem of plugins and support.
Bower - Front-end package manager. Some prefer Component and others use Browserify + NPM. In my opinion, Bower is the best solution for front-end dependencies.
Stylus - CSS Preprocessor Stylus much like LESS and SASS, only it supports multiple forms of syntax and is incredibly powerful. On par with SASS, and allows you to mix different syntaxes of CSS (spaced/indented syntax, standard CSS)
Autoprefixer - Allows you to write CSS without cross-browser properties and it will scan your CSS and add them in for you, based on the settings you define. This is a must have.
Gulp Autoprefixer - The plugin for using Autoprefixer with Gulp, makes your workflow seamless.
Browsersync - Allows you to syncrhonise cross-browser testing (form values, clicks, scrolling, and everything) with impressive browser support (even IE7 and up). This is also an ideal replacement for the likes of LiveReload which has issues, BrowserSync allows you to update your browser(s) in realtime to reflect your code changes.
Yeoman - A scaffolding tool for generating skeleton applications using X language/framework. Handy if you want to get your feet wet with the likes of ReactJS or AngularJS and do not know how to go about setting up a project. Similar to that of Rails scaffolding/generation tools, Yeoman gets you setup quickly and removes a lot of the repeated junk you go through to setup code.
The only thing that's remained constant recently is SASS. Been using that for awhile now, and I couldn't live without it.
I used to do all my prototyping and initial FED in Middleman and Ruby, but recently hopped stacks over to Node and Gulp. It loses some of the power of Middleman, but after the prototyping is done, I can shave away the now unnecessary prototyping plugins and convert it into a production ready front-end.
The rest changes by type of project. Bootstrap for working on certain teams. Rolling my own frameworks when running solo.
And Vim. Did I mention Vim? I keep trying to break up with it but always come back to it, no matter which new shiny editor comes out (Sorry Sublime! It's not you! It's me!)
Yeoman, Sass, Gulp, Bootstrap and probably going to start integrating Fireshell
NPM Env. & Gulp
Jade Sass + Bourbon Gulp or Grunt Webstorm as IDE
Sass. Grunt. InuitCSS, a nice starting point and group of super lightweight reusable design-less components.
Write the rest myself.
Jade Sass Bourbon Grunt JPEGMini ImageOptim + ImageAlpha
Webstorm rocks on handling automations (Gulp / Grunt), code hints and inspection.
Sorry to just fire a list at you, but these are all the things I used in my most recent project:
These were all used to create a documentation site hosted on GitHub using Jekyll. Bower manages any JS or CSS libraries I used, and Gulp places them into the right directories within my project. Coda 2 is my personal choice of code editor, I use it as it has SFTP capabilities amongst other things.
I hope this is of interest!
Huge advocate of Docpad (like Jekyll and Middleman but nodeJS) and when not building in that I use Prepos for separate compilation of preprocessor languages.
I use [SUSY](susy.oddbird.net) for grids and for rest of the tasks (like minification, Sass compilation, Live Reload etc), I use [Prepros](alphapixels.com/prepros) which has built-in Compass support.
Use Flash ;)
NPM + Browserify + Myth (or if you're feeling dangerous: Sheetify) will get you 99% down the road.
a lot of frontend tools in here: http://fredsarmento.me/frontend-tools/
Anyone know of a simple CMS where I can hide a static site behind a login?
It's not a CMS, but I love bitballoon.com for hosting static sites. Makes it really easy to upload static content and there's an option to put the site behind a login as well.
Beautiful, I'll take a look. Thanks!
Where the design community meets.
Designer News is a large, global community of people working or interested in design and technology.
Login to Comment
You'll need to log in before you can leave a comment.Login
New accounts can leave comments immediately, and gain full permissions after one week.Register now