

The Blimp Tech Stack: Frontend - jpadilla_
http://blog.getblimp.com/2013/01/the-blimp-tech-stack-frontend/

======
alex_c
None of that makes a good argument for why you need to reconsider your
frontend, it's just a list of cool libraries.

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.

~~~
lifeisstillgood
I _did_ think the same way, but started drinking the Backbone / MD /
Marionette / Mustache kool-aid back in December.

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.

~~~
alex_c
I wasn't necessarily thinking any certain way - I haven't done much front-end
development in a few years, so I don't know much about any of the frameworks
mentioned. I was just trying to politely point out that the post is fairly
content-free.

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.

~~~
lifeisstillgood
There is a lot of "cool new thing" in the, for want of a better term, "new-
style javascript world", but javascript is _the_ ubiquitous platform, and it
is not a classical OO language - so taking advantage of its small functional
foundations to allow more expressive work is a Good Thing.

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 :-)

~~~
alex_c
Thanks! Saved for future reference for when I have a bit of time to play with
this :)

------
patja
Why do you change the title when you post it here to be so provocative and
arrogant? Linkbait?

"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.

------
brianbreslin
slightly off topic. I REALLY wish GetBlimp showed pricing on the site before
signup. only thing i see is "start with our free plan, then prices start at
$12" on the homepage, then signup page etc i have no idea what prices will
rise to.

~~~
flexterra
Plans and pricing here: <http://bit.ly/VLzg3v>

~~~
j_s
Aka
[https://s3.amazonaws.com/uploads.hipchat.com/12763/40986/n5j...](https://s3.amazonaws.com/uploads.hipchat.com/12763/40986/n5j6xi7odyvm8yp/Screen%20Shot%202013-01-28%20at%201.08.10%20PM.png)

------
figurify
REST API bound simplistic and stateless frontends are easier said than done.
Does anyone know a DRY way of achieving this. I like the AngularJS approach of
keeping state(of DOM - a.k.a what the user sees) and let it flow. But still,
as a Javascript noob, every library seems messy and unworkable :(

Any advice on this?

------
swah
"You should try Angular"

