The Blimp Tech Stack: Frontend
blog.getblimp.com
blog.getblimp.com
Developers like to try new technologies, and like to improve things and make their life easier (which often involves some form of re-write). This is natural. But does the new stack justify the time that was spent moving over?
I'm assuming it was worth it, but it would be nice to see something actually backing that up.
This is like pop-music. There's no way to tell what is exaggeration.
Really this is a revolution in how Javscript is used in the standard web stack. Huge chunks of the work of a web stack is moving into the client, and the old-skool approach to javascript really does not cut it. (I used to be a javascript maven back in the day - it has taken weeks to get partly productive)
There is a knock on effect at the server end - basically slimming the whole server end down to little more than RestFul JSON servers. This is a good thing, and is pushing a move to smaller frameworks and more composable servers and the whole asynchronous thing.
There is a huge amount wrong with this new eco-system, its messy and there are few clear winners - not surprising as it is still in the process of being built - but it certainly is innovative means to solve existing real problems.
Drink the kool-aid - but a good guide is necessary.
However, reading about a project switching technologies every few months does make me raise an eyebrow. Nothing wrong with doing it for a personal project, but does it fundamentally move the business forward and let it do things it couldn't before? Or is it just developers playing with shiny new toys?
Edit: I will be reading more about it to wrap my head around how it all works. I'm probably a bit less receptive to "the cool new thing" than usual because I've spent the last few days trying to revive and migrate an "ancient" Rails 2 project and dealing with a lot of no-longer-supported stuff.
We are moving towards a situation where composability is the watchword on the client side - which is a nice place to be.
Honestly I would not try reading to "get it" - it does not work. but I suggest you read and then implement in this order
* What is AMD v CJS
* CoffeeScript (Yes, I know)
* CoffeeScript annoyances
* Backbone.js - build a model, a collection and view, that makes a AJAX call
* Marionette - replace the view with marionette views (much easier to control)
* back to backbone for sync and watching model changes
Then start to think about better ways to arrange your app - and better ways to define areas on screen. I am toying with some thoughts but clearly poeople want to take this exprerssiveness on next - and the most OO-classical-config-heavy area is how to change the DOM. Lots of config and magic in there. THat will need cleaning out. probably with another package :-)
"Why you need..." just sets you up for a negative reaction such as "who are you to tell me what I need to do?" and "what makes you think this is at all relevant to me?" and "what arrogance to think you have all of the answers for everyone"
The actual post you are linking to has none of the presumptive arrogance implied by the "why you need" titling and reads like quite a reasonable discussion of choices the author made that made sense for their particular requirements and environment. None of it applies to me and my situation, but I can read it with a much more open mind that I was initially inclined to based on the "why you need" language.
Any advice on this?