3 ms·

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 menti

by alex_c 14y ago

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 14y ago
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 14y ago
  Thanks! Saved for future reference for when I have a bit of time to play with this :)

by alex_c 14y ago

lifeisstillgood 14y ago

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 14y ago
Thanks! Saved for future reference for when I have a bit of time to play with this :)