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

21–30 of 73 posts

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

#21

Post by ilaksh »

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 aren't able to either grasp or accept that is because A) understanding and building those types of components that are truly generic enough to be applicable to a wide variety of applications as well as reusable, has a significant learning curve and is time consuming and B) the better you are at it, the less likely you are to get credit for your programming skills, because unfortunately if you can build an application without typing colorful ASCII text, then you didn't do any programming and aren't a programmer.

To get past B) we just need to redefine what programming is, and also grow up a little. Also realize that even if you are programming with GUI components, you still have to create new components sometimes, so you are still programming and still a programmer.

I have a very early rough draft system that I am throwing together on my own, mostly because very few people seem to be able to appreciate these concepts. Or the ones that do are happy to use existing systems like ASP.NET or WordPress.

https://github.com/ithkuil/cureblog

https://vimeo.com/43784316 Note that I have modernized the interface somewhat since I made that video.

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

#22

Post by jmesserly »

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…

Agree on widgets. Have you seen the Web Components effort? http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i...

It's an attempt to standardize widgets at the browser level. Really cool stuff.

It's based on ShadowDOM, which is an encapsulation notion: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado...

There are a few polyfills for playing with web components, such as Mozilla's http://x-tags.org/ and http://html5engineers.com/projects/playing-with-web-componen...

Also some of the frameworks do have a "widget" or "component" notion. For example, see "Create Components" at http://angularjs.org.

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

#23

Post by ilaksh »

jmesserly wrote: post #22
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…

Agree on widgets. Have you seen the Web Components effort? http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i... It's an attempt to standardize widgets at the browser level. Really cool stuff. It's based on ShadowDOM, which is an encapsulation notion: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado... There are a few polyfills for playing with web components, such as Mozilla's http://x-tags.org…

Right, web components and angular js components are an improvement, but they still emphasize manual ASCII coding, which defeats one of the main advantages of GUI components.

Also the strong separation and lack of cohesion between the front and back end systems is a severe limitation.

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

#25

Post by lmm »

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…

Coming from Wicket, the thing I'm really looking for to make reusable components more possible is a very weak templating system. I want inert, textual templates where literally the only thing they can do is define an anchor point at which the code inserts text, or another component. Maybe I have to write it myself.

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

#26

Post by geon »

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.

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

#27

Post by ianstormtaylor »

"In my view, the strongest argument here came from the Angular guys who stated that in the near future, they expect DOM-based templating will be native in browsers, so we’ll best prepare ourselves for the future by adopting it now. "

Would love to know where this was discussed in more detail.

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

#28

Post by vtry »

jmesserly wrote: post #22
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…

Agree on widgets. Have you seen the Web Components effort? http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/i... It's an attempt to standardize widgets at the browser level. Really cool stuff. It's based on ShadowDOM, which is an encapsulation notion: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado... There are a few polyfills for playing with web components, such as Mozilla's http://x-tags.org…

Angular directive is pure genius. Much more reusable than traditional "widgets"

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

#29

Post by vtry »

ianstormtaylor wrote: post #27

"In my view, the strongest argument here came from the Angular guys who stated that in the near future, they expect DOM-based templating will be native in browsers, so we’ll best prepare ourselves for the future by adopting it now. " Would love to know where this was discussed in more detail.

Angular meetup.

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

#30

Post by vtry »

steve-sanderson wrote: post #14
jarito wrote: post #8

I wish he'd touched on testability. I chose Angular for my project because it is dependency injected by default and includes mocks for common tasks. This makes is possible to do the majority of my UI testing in unit testing which is much faster and easier than using something like Selenium.

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).
Post reply on HN