Over the past three weeks I’ve had the opportunity to investigate modern web development tools and I feel a little bit like a kid in a sweet shop. Firstly, I’m excited to be here. Secondly, there’s so much to choose from. In the past you may have been able to pick up a selection box containing a few pre-defined dev tool options. Now, there are so many technologies and tools available it’s like being in the pic ‘n’ mix section.

pic-n-mix source

There are so many tools to choose from when undertaking a web development project that it’s difficult to know where to get started. How do you approach choosing what’s right for your project? How can you really know without trying them all out?

Let’s be honest; very few of us have time to really try out everything.

So, you probably choose techniques, technologies and tools that have similarities to the ones you are familiar with, the ones used and talked about by those you ‘follow’ and from selective reading and testing.

“Node.js is trending; we should probably try that out”

“We can now loosely couple our web front-ends from our backends thanks to modern browsers and by building APIs”

“I’m seeing Yeoman mentioned a lot and those guys from Google are involved in it; that must be the way to go”

“I’ve seen people migrating from TextMate to Sublime; we should be using Sublime”.

From runtime to editor; it’s a minefield that has to be navigated quite frequently as technology naturally progresses at an amazing rate.

A lot of us (developers) like to have the choice. We like picking the pieces of technology that suit us. Our development workflow really is created from a pic ‘n’ mix of tools; from runtimes, to productivity apps, to editors, to build tools, and beyond!

IDEs (Integrated Development Environments) were commonplace in the not too distant past. But now, and for quite some time – in the scripted-language circles I’ve been in, anyway – there has been little use of IDEs and the choice has been to pic ‘n’ mix web development tooling. There are obvious benefits in being able to select small tools that do one (or a few things) very well.

Editors: Sublime, TextMate or Vim combined with editor customisations and hooks into the terminal/console represent a common web development setup. The terminal is then used to kick off tasks from running tests to full builds and deployments. Certainly no pointing and clicking.

The real need for effort comes when those tools – executed from the terminal – have to integrate with each other. Scripts have to be written, tested, debugged and managed in the very same way as the code for the product that’s being built. It feels like we’re spending more and more time playing with tooling and less time creating products. Others seem to agree.

Also see Matt’s post, The web: less engine, more gas

Some developers – and businesses – simply want a set of web development tools, and a runtime stack, that just works and helps productivity as close to “out of the box” as possible. This may be through buying-in to a technology stack such as the ones provided by Microsoft (whether you like it or not, Visual Studio is a solid IDE and developers can be very productive using it) or by using a web toolkit which consists of a collection of small tools pre-configured in a way that has been agreed by the toolkit’s contributors to be a productive default.

When it comes to front-end web development, the latter can be seen in the likes of Yeoman, Brunch, lineman and Mimosa.

These don’t provide editors, but do provide things like:

  • default application structure (skeletons) from templates
  • scaffolding functionality to help generate common files for common functionality (e.g. models, views, controllers and tests)
  • development runtime tools (e.g server and logging)
  • a common build process

They also generally provide some sort of plugin or extension support. Exactly what can be customised by these really depends on the toolkit; Yeoman appears to be massively flexible while Mimosa is a little more restrictive.

You could still look upon these toolkits as being too flexible, or as requiring too much additional configuration, but the defaults are consistently being reviewed – Yeoman only at 1.0 release candidate 1.

So, is there still a place for the full blown IDE? Maybe that depends on the technology that an application is being built on; Visual Studio for .NET and IntelliJ, NetBeans or Eclipse for Java versus text editors (TextMate, Sublime and Vim) plus customised tooling for Node.js, Ruby and front-end technologies like JavaScript, CSS, Sass, Less etc.

I’m particularly interested in Yeoman. It’s already had great take-up by a community that live on the cutting edge and has had a large number of contributions. It consists of Grunt and Bower which both have a high level of adoption on their own. What interests me is that I can see a number of light weight wrappers being created around these tools to provide more defined (rigid/opinionated) developer workflows that fit certain work environments or where some development processes need to be adhered to; maybe the types of environment that IDEs presently inhabit? This may require an acceptance of Node.js in larger institutions, but I think that’s coming and is certainly being helped by Microsoft’s adoption of it and incorporation in Windows Azure.

selection-box source

Would the wider, more cutting edge community, adopt a more defined workflow if it were proven to help productivity and could demonstrate that using it resulted in quality scalable web applications?

Pic ‘n’ mix web development tooling is popular right now, but maybe the day will come when a number of proven quality selection box developer toolkits – consisting of the very best of the pic ‘n’ mix – will return to popularity?

Tagged with →  
Share →
Buffer
  • dkb

    Mimosa (http://www.mimosajs.com) is very flexible, it just starts with some opinions to keep you from needing to spend time configuring all that flexibility. And it has Bower integration on the way.

    Yeoman definitely has more developer mindshare though, more folks behind it, and it really just wraps grunt, so takes advantage of that. But it is hard to beat Mimosa for getting off the ground running, jumping right into code and building apps built with requirejs.

    • http://www.leggetter.co.uk/ Phil Leggetter

      As the author of Mimosa, you would say that :)

      I did just say “a little more restrictive”.

      What I meant by that is that I noticed that although you can write code in CommonJS you can only do so with an extension that eventually wraps the code to be in RequireJS format. The lack of a package manager was also something that lead to this comment.

      One thing I’m particularly interested in is seeing assets split by functionality, rather than asset type. I can see how I could do that with Yeoman (by creating my own generators) and I see Lumbar’s modules (http://walmartlabs.github.io/lumbar/#modules) fit this well. Is it possible to do this with Mimosa? I think this is important as we move to creating reusable web components within our applications.

      • dkb

        First, I’ll double back and thank you for considering Mimosa in the first place. It’s definitely the little guy in your review (I’m not Google) and any pub is good pub. =)

        You are bang on with the two critiques.

        The CommonJS thing I’m fine with for now. Mimosa is opinionated towards the use of RequireJS and my focus has been to pimp out that use case before attempting to handle another, hence the commonjs support via RequireJS rather than via some other mechanism (browserify or somesuch). Mimosa sprang from a need for real AMD/RequireJS support on the job, and that need hasn’t subsided. And when I started, Yeoman didn’t exist, Grunt was a bit messy (it still is, hence Yeoman), and Brunch didn’t have real AMD support.

        So if you are using RequireJS but want to write CommonJS rather than AMD, then Mimosa is a solution, but if you aren’t using RequireJS at all, then Mimosa, at least for now, isn’t for you. Someday. =)

        The asset organization problem is a clear problem that needs addressing. I’m running into it with the Bower integration I’m hacking away at. The simple fact is there is a configuration for where your “javascriptDir” is and that needs to go away, or be expressed with something other than a string. But its awesome you bring it up, that sort of feedback helps organize priorities.

        Again, thanks for the inclusion! I know you are probably going down the Yeoman path, but should you or anyone tinker with Mimosa and have suggestions/problems/critiques, definitely hit me up via github issues!

        • http://www.leggetter.co.uk/ Phil Leggetter

          I’ve got a task on the cards to build the same app in two frameworks to do a comparison. I’ll try to extend that to three and include Mimosa.

          Keep up the good work!

  • Grant Richmond

    With all these tools I think it’s almost impossible to balance flexibility with ease of use. I mean I can’t ever imagine there being a GUI way to create a complex yeoman setup.

    But the beauty of it is that after a couple of days messing with your setup it’s then easy to reuse it shaving valuable time off of future projects.

  • John Stevenson

    When working with JavaScript frameworks like AngularJS I tend to have a pick and mix approach too, as its generally more productive. I have stabilised on a few key tools though.

    I agree that Yoman is a great tool, especially when coupled with Bower and Grunt. I also make a lot of use of the Google Chrome(ium) dev tools to help me see what it going on.

    For editors I have gone back to one of the all time classics, Emacs. For a dev who is a keyboard jockey (i.e. can touch type) Emacs quickly becomes the editor of choice for everything. Using the Emacs Live configuration on Github I get all the useful parts of an IDE (syntax highlighting, auto-completion, code formatting, REPL’s, etc) without the fuss or weight of an IDE itself.

    I plan to stick with this combination of tools for a while and only change when I have time to evaluate something new. However, I will try and make time between projects.

    • http://www.leggetter.co.uk/ Phil Leggetter

      Your point about touch typing is really interesting. I touch type when writing code and I hadn’t considered that there may be a setup which would make me more productive.

      Would you consider Emacs similar to VIM solutions? Do you use tmux? http://tmux.sourceforge.net/

      • John Stevenson

        Vim and Emacs are the same in that they are both extensible tools that are predominantly used for editing text. For me though, Emacs has the edge on typing productivity, but then I have used it as my sole editor for the last year.

        The biggest advantage of Vim is it is everywhere. Every OS worth using has Vim installed by default. Emacs needs to be installed (or a newer version installed in the case of MacOSX).

        However, I prefer Emacs as it has a great community around it that help me make use of all its wonderful features and add-ons. I have seen a lot more features and extensions shown off with Emacs than I have with Vim, so that gives me a bias of seeing Emacs as being able to do more. For example, check out Emacs Rocks youtube videos.

        I started using Emacs (again) when I started to learn Clojure and also found it great for JavaScript development, as well as writing most of my documentation (usually in markdown).

        I also love Org-mode. Its a great way to capture notes, manage to-do lists and manage your schedule. You can also use it for presentations without having to worry about file formats (its just plain text files in the end).

        I have used tmux for sharing a sessions at code dojo’s before and it works well. I tent to just use the standard Ubuntu terminal and have tabs.

        I use to use Byobu when I still needed to manage servers (vm’s). I still find Byobu useful for demos where I am not mirroring my desktop, as I can type in one terminal on my laptop screen and it also appears in a terminal on the projected screen.

        Thanks

Realtime Web Apps: With HTML5 WebSocket, PHP, and jQuery

Buy the book I co-write with Jason Lengstorf via Amazon.com or Amazon.co.uk

BladeRunnerJS - Divide & Conquer your Web Apps
BladeRunnerJS: Divide & Conquer your Web Apps

BladeRunnerJS is a development toolkit and lightweight framework for building web applications consisting of one or more components called Blades. It comes complete with some seriously useful tools which make it easy to develop, test and deploy your app.

Find out more