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.
I am actually one the fence about whether that post (as part of that whole site) is supposed to be satirical. It seems like a very bloated or "blimpish" stack. So I assumed it was all tongue-in-cheek.
This is like pop-music. There's no way to tell what is exaggeration.
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.
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.
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 :-)
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.
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 :(
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.
14 comments
[ 0.19 ms ] story [ 33.5 ms ] threadDevelopers 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 :-)
Any advice on this?
"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.