Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Throne of JS: Eight JavaScript MV* Libraries Compared

blog.stevensanderson.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#61

Post by steve-sanderson »

geon wrote: post #26
dj_axl wrote: post #24

"The only stalwarts here appear to be Backbone (other than its default routing feature, it works on IE6) and Knockout (which for now at least insists on total IE6 support)." IE6 support is a must-have for me (corporate clients).

Is the ie6 support accidental or do the devs sacrifice maintainability, readability or performance to specifically support it? It seems to me that since it is so small, and doesn't really do much, they'd have to go out of their way not to support ie6.

> they'd have to go out of their way not to support ie6

Oh, how I wish! Try searching the Knockout source code for "IE" and see how many special-case rendering and event bugs it has to work around. For sure, getting 90% IE6/7 support might be quite easy, but that last 10% is a real pain and that's the value of using a mature framework where someone else has already debugged the heck out of it.

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#62

Post by steve-sanderson »

drgath wrote: post #49
easternmonk wrote: post #16

Incomplete without including YUI3 App framework.

Yup. Oddly enough, YUI had a core team member (Eric Ferraiuolo) at Throne of JS to talk about Y.App, but apparently didn't get a mention in the linked blog post. shrugs

Eric's talk was more about general web development principles than about any YUI technologies specifically.

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#63

Post by uulbiy »

nahname wrote: post #42
ilaksh wrote: post #40

Earlier quoted context omitted.

Widgets are very limited in their application? I think that there may be a few full-time professional Swing, WPF, ActiveX, Wicket, Flex, ASP.NET, Sencha, WordPress, etc. developers who would disagree with you.

ASP.NET is a nightmare. An absolute nightmare to work with. Sencha (assuming ExtJS) is one of the worst JS libraries you could pick. Not a great deal of experience with the others, so I cannot comment. That said, there are no doubt good examples using those technologies to do useful things. I am not arguing that widgets make it impossible to create useful things. I am arguing that widgets by their very nature limit w…

Actually in my experience ExtJs is one of the best libraries/frameworks* [1]. It has a steep learning curve* [2] but after that you can build awesome applications quite fast.

* [1] : library based on the author's definition and framework based on sencha's documentation.

* [2] : the learning curve is steep even for experienced javascript developers.

edit: I just had to fight the * * *

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#64

Post by andybak »

ebiester wrote: post #32

"Agreement: Progressive enhancement isn’t for building real apps. All the technologies follow from the view that serious JavaScript applications require proper data models and ability to do client-side rendering, not just server rendering plus some Ajax and jQuery code. Quote from Jeremy Ashkenas, the Backbone creator: “At this point, saying ‘single-page application’ is like saying ‘horseless carriage’” (i.e., it’s n…

Throwing away Progressive Enhancement makes sense for things way at the 'App' end of the spectrum but it's going to spread like a cancer right up to the 'Content' end of things and if we're not careful one day we're going to look back and realise we've broken the web.

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#65

Post by SchizoDuckie »

SchizoDuckie wrote: post #50

The one thing i'm missing most in all these frameworks is proper data access, offline I agree that it's an awesome time we live in with an mv* framework coming out every day, but where's the love for offline apps? None of the frameworks seem to support grabbing data from SQLite in a proper way without including hundreds of extra kb's of js. How about a real world scenario where you store products, and categories and…

[edit]whoops, wrong link: http://goo.gl/gz7zo [/edit]

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#66

Post by scotty79 »

rimantas wrote: post #60
scotty79 wrote: post #19

Knockout is awsome. Check it out. You can grasp it over the afternoon and examples of advanced ui-s are interesting and concise.

And then you try to use it for more complicated cases, run into limitations and switch to backbone.

I've done Backbone course in codechool.com It's very basic and targeted at beginners but in last lessons already I've seen how it becomes tangled and begins to fall apart.

I feel that Knockout provides you with much more structure that prevents you from making too much of a mess.

Custom bindings provide easy way to insane flexibility http://learn.knockoutjs.com/#/?tutorial=custombindings and the models don't look like hundredth attempt at just implementing CRUD. Also no re-rendering of html and no need for rebinding DOM events (vide http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt... ).

Thus my noob preference.

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#67

Post by nahname »

neeleshs wrote: post #46
nahname wrote: post #42

Earlier quoted context omitted.

ASP.NET is a nightmare. An absolute nightmare to work with. Sencha (assuming ExtJS) is one of the worst JS libraries you could pick. Not a great deal of experience with the others, so I cannot comment. That said, there are no doubt good examples using those technologies to do useful things. I am not arguing that widgets make it impossible to create useful things. I am arguing that widgets by their very nature limit w…

I am not a JS guy, but many in my org swear by ExtJS, especially because of widgets. Would be helpful to know whats bad about ExtJS.

If something is working for you, don't change it. ExtJS is a fairly large framework and replacing it with something 'better' would have a large cost for your organization.

That said, my experience is primarily with coolite and versions 2 and 3 of the framework. I was working closely with another team using 4, which sounded better.

ExtJS' main problem is that it does too much. It tries to replace jQuery, CSS, JavaScript OO frameworks and then adds it's widget/control and code structure on top of all that.

If it just did the last one (maybe two), it would be a decent framework. I still would not choose it because I don't like how it gets in the way of API calls nor the control of event handling in versions 2 and 3. This last point has probably been improved in 4 with the introduction of an actual MVC structure, but I don't know for certain.

In any case, using enormous object literals to configure and control everything from styles, events and actions made it both difficult to work with and test. Often times these blocks of code would exceed hundreds of lines. In short, ExtJS sets up developers to fail. Most of what it does can be written in jQuery using CSS classes far more concisely. It's strongest points were it's UI controls, especially the grids. I think these are the things where the framework adds value, the rest would be better served using more commonly adapted practices.

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#68

Post by nahname »

dsrguru wrote: post #56
nahname wrote: post #38

Earlier quoted context omitted.

Widgets are expensive to build into a framework and very limited in their application. They only fit the use-case of something that widgets are a core part of (iGoogle/widget pages) or something that is marketed at parttime programmers (Wordpress/blogging platforms). If you can create a website from scratch. Using widgets in place of custom code is a waste of everyone's time, including the person who is going to exte…

The thing is, the sites that benefit most from these client-side-centric approaches are single page applications [1]. I'd imagine the benefits of having prewritten reusable widgets are the same for SPAs as they are for desktop software. They provide computer illiterate end users with an interface consistent with other similar applications, and like any form of abstraction, they make development faster and maintenance…

Widgets have the same strengths and weakness when choosing software products to buy. If the product meets your needs exactly, it makes sense to buy. If you are going to have to customize the product to actually meet your needs, build the whole thing instead.

In my experience, widgets generally end up in the second category. This is also shared by people generally looking down on things like drag and drop development. Obviously nothing is going to be faster than dragging the complex control someone wants to use into an HTML page and clicking deploy. The problem is that it is almost never the case that the user or your needs are met by the default setup. Then you start configuring and customizing the control. Developers often spend more time configuring and hacking these widgets than it would take to write something that exactly met their needs.

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#69

Post by krosaen »

ilaksh wrote: post #21

http://tjholowaychuk.com/post/27984551477/components Those frameworks are great, but they all fail to take advantage of a key advance in software development: the widget. Reusable, composable GUI components that package front end and back end files together and can be distributed easily as plugins are the next step up in abstraction and superior from a software engineering perspective. The reason many web developers…

In knockoutjs, bindings (and the ability to create custom bindings) are akin to widgets in they define exactly how view model state maps to and from the dom. I've created a number of custom bindings to bind things like a number range to a jQueryUI slider widget.

Re: Throne of JS: Eight JavaScript MV* Libraries Compared

#70

Post by krosaen »

rimantas wrote: post #60
scotty79 wrote: post #19

Knockout is awsome. Check it out. You can grasp it over the afternoon and examples of advanced ui-s are interesting and concise.

And then you try to use it for more complicated cases, run into limitations and switch to backbone.

knockout and backbone serve different goals:

http://stackoverflow.com/a/6340870/231589

For me, the dependency tracking and automatic ui refresh provided by knockout hits the sweet spot, functionality that isn't in the scope of what backbone provides.

Post reply on HN