Comparing Client Side MVC Frameworks; Moving beyond shift-reload and HTML templates
Paul Hammant is a legend of a developer that I have followed back to my Enterprise Java days. We have often had a similar penchant for wacky front end development frameworks.
His rating criteria were different to mine. One that really sticks out is that I like the logic not forcing the template HTML to migrate to <script> tags. Depending on the sophistication of the app, I like to be able to see the app in a browser or DreamWeaver when the framework is not running. It gives me a way of gauging the composition of the app. It appeals to a WYSIWYG leaning that I have. I like my UI frameworks to be built for designability if you like.
I remember thinking this way back in the day. One reason that I liked Tapestry was its use of bolting onto HTML instead of some zany XML nonsense, or some inline JSP-monstrosity.
The game has changed though. I love the power of “Shift-Reload” for Web development. No compile step FTW and all that jazz. However, we are finally at a point where I think that we can get that power without leaving everything else.
I favor stylus over CSS. I understand why people want to use CoffeeScript vs. just JS (I use both depending on the situation). There are enough tools out there that I have a deploy step. However, this doesn’t mean that shift-reload is lost… and in fact, we can have things even better.
I make changes to my code, and when I save the file it goes through the build steps and updates the browser with any changes that it needs. No need to reload the app. Awesome.
Paul Irish showed of some new Chrome Dev Tools that I hadn’t seen yet. Chrome Canary has them to play with now… including being able to make changes to the computed CSS and have those changes sent back to the original files. Now I just dream of the tools grokking stylus and I am happy as larry. Oh, and then mapping any DOM changes back to my handlebars templates ;)
Dreamweaver? Come on Paul….. time for us to move on!