We ramble about code, technology and life. Sometimes we actually code...


Get your mind blown

by Cornelius Weidmann on 1 May 20144 min read

What's the hype about all these new, fancy and sparkly front-end JavaScript frameworks? And this thing called Node.js and MongoDB? Can one really use these tools in a real life production environment?

Before I start scratching the bare surface of these questions I'll point you to three talks:

  1. Martin Kleppe: 1024+ Seconds of JS Wizardry—JSConf EU 2013
  2. Karolina Szczur: To hell with jQuery
  3. Emily Stark: Meteor - A Full Stack Framework For Building Pure JavaScript Apps - JSConf.Asia 2013

The first one shows the awesomeness that can be achieved by fully understanding JavaScript as a language. It is filled with hacks and very inspiring. Sure, you'll never need any of this in a production environment. Then again, there are a lot of things that seed ideas which you could potentially use in a production environment.

The second talk encourages rethinking the way we use libraries/tools and also encourages to RTFC (Read The Fucking Code) more than RTFM (Read The Fucking Manual).

The final talk is a demo on meteor.js and will literally (not really) blow your mind.

There is a lot of hype around new frameworks. Can we use them, should we use them?

In my opinion programming languages are just tools, just like frameworks.

If I need to do woodwork and screw a screw into the wood, I will do so with a screwdriver. If I need to hammer in a nail, I will do so with a hammer. Sure I can hammer in the nail with the screwdriver, but let's get real. Even though you can hammer in a nail with a screwdriver it's not really as efficient or practical than just doing it with a hammer (the tool that was built for that specific task).

Just like the example illustrated there are different languages that tackle different problems (possibly in a different way). Not every language is able to solve every problem and there is no single language that can do the job alone. There will always be some interaction between different coding languages.

In the web industry this is particularly applicable. However, the web is the one place everybody thinks there is only "one" language that is the best and we shouldn't be using any other.

JavaScript is awesome, so is PHP, so is Python so is [insert your favourite web language here]. The difference in the web industry is the fact that we need to deal with client side and server side. Most of the time there are always different languages and more than one developer involved and things just need to get done and work (if possible, they must work awesomely). This is where the frameworks come into play.

Sure, your company has awesome developers and they don't need any frameworks: "They can code anything from scratch!" Meanwhile, in the business opposite you they are using the latest frameworks. It's not surprising that frameworks are generating a lot of hype. They always will.

The key is to pick a tool, test it and then build with it. Only actual real environments will be the test of a framework. The website of your potential framework might show fancy examples of todo lists or voting systems etc., but is there an online shop that uses framework A or a high traffic news site that uses framework B?

How do I know if a framework is worth the hype?

Well, what are you building? Is it an app or a website? Are you a master of a programming language or are you currently only learning?

The simple answer is this: If you are a master of your tool (no matter the environment or the circumstance) you will fairly quickly find out if the framework in question works or won't work. If you are not a master, then just pick a framework and go for it! Chances are the framework can do whatever you want to do, and if not - you're a coder - go code it yourself!

Every project has a different scope and can potentially make us of a framework. Some projects will just never be suitable for a framework.

In the end, the code you write will be awesome no matter your choice (framework or not). The framework is just there to make you write that code faster.