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

51–60 of 73 posts

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

#51

Post by nl »

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…

Angular.JS has widgets, eg: http://blog.angularjs.org/2012/05/custom-components-part-1.h...

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

#52

Post by cutie »

tmbsundar wrote: post #48
cutie wrote: post #43

Earlier quoted context omitted.

How about the dojo widgets, do those qualify?

I was about to ask the same thing. How good is Dojo? This seems to be a complete framework with widgets support. How does this differ from the frameworks discussed above? When should I choose one over the other group?

I like it and prefer the coding style to jquery. Unfortunately dojo (and everything else) has been overshadowed by it.

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

#53

Post by nl »

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…

Google still depends on static content for indexing

Actually, no. Google now will run JS in some cases[1]. I don't believe they have made public statements about when they do this, but I would suspect it may to to verify that the ajax-crawlerable version of the site[2] matches the real one.

[1] http://swapped.tumblr.com/post/23133779276/google-bot-now-cr...

[2] https://developers.google.com/webmasters/ajax-crawling/

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

#54

Post by ilaksh »

tmbsundar wrote: post #48
cutie wrote: post #43

Earlier quoted context omitted.

How about the dojo widgets, do those qualify?

I was about to ask the same thing. How good is Dojo? This seems to be a complete framework with widgets support. How does this differ from the frameworks discussed above? When should I choose one over the other group?

Honestly, and this may sound like I am contradicting myself a bit, but I guess what I am talking about is not quite the same thing as Dojo Widgets etc. Its along the same lines, but if you are trying to choose between for example building on top of Dojo Wigets or Sencha and using something like Meteor, I would lean towards Meteor unless the UI you are building looks like a traditional desktop application and has a lot of classic desktopy widgets in it that you can map to the existing Dojo (or whatever) widgets.

If the choice is between Meteor and my system, I would choose my system, of course (although I may be biased and honestly my system has a month or two of work left before its really ready for release). Whereas Dojo Widgets (for example) are only for the front end and designed to look like a desktop application, my components include both front end and back end code, with automatic database wiring, and the widgets are set up so that it is easy to customize their appearance.

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

#55

Post by [deleted] »

ilaksh wrote: post #40
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…

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.

[deleted]

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

#56

Post by dsrguru »

nahname wrote: post #38
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…

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

[1] I know some JavaScript lovers are convinced that client-side rendering is better than server-side even for non-SPAs, but I'm of the rather strong opinion that they're wrong. For non-SPAs that are sufficiently complex, the sexp model of server-side rendering in Clojure, Common Lisp, and Racket produces applications that are so much more concise than their client-side DOM-manipulating equivalents. For the few sites small enough that the overhead of macro writing/bottom-up development outweighs productivity gain, rendering HTML in Rails or Django is probably better than an all-JS approach.

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

#57

Post by steve-sanderson »

vtry wrote: post #30
steve-sanderson wrote: post #14

Earlier quoted context omitted.

Unit testing your viewmodels/scopes is great, but it's a totally different kind of activity to end-to-end testing via browser automation, isn't it? Unit testing will help with design, but end-to-end tests will catch an entirely different (and bigger) set of bugs. So don't you need both?

Most frameworks it is not possible to do proper unit test. With Angular, you can actually do it. As the controller is totally separate from the view (html/dom).

OK. I was just taking it for granted that it was easy, because the same is true in Knockout (viewmodels are entirely independent of views, and so are trivial to unit test with QUnit or whatever else).

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

#58

Post by rimantas »

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…

> The reason many web developers aren't able to either > grasp or accept

The reason is simple: they have already been burnt and know better.

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

#59

Post by steve-sanderson »

netghost wrote: post #31

For what it's worth, I've been playing around with making a really tiny MV* library called Ivy ( http://adamsanderson.github.com/ivy/ ). It's similar to Knockout with data binding, dom templating, and some nice debugging tricks. The entire thing clocks in around 900 lines with comments, and has no dependencies so if you're curious, have a look.

Nice one! It's cool to see these ideas expressed in such minimal code.
Post reply on HN