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

41–50 of 73 posts

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

#41

Post by ilaksh »

deafbybeheading wrote: post #39
ilaksh wrote: post #23

Earlier quoted context omitted.

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.

Is it? One could argue that divorcing widgets from backend infrastructure so thoroughly is an asset.

Almost everyone does argue that.. sort of.. only there usually is no argument. Its taken as a given in most cases.

That belief is more a result of where we have been than on a logical assessment of where we are now.

If your back end team is separate from your front end team, programming in a different language, building a codebase to support multiple departments or multiple third-party integrators with a single web API for a one-of-a-kind world changing application running primarily in HTML browsers, then it may not make a lot of sense to try to package together the back end and front end code the way I am suggesting.

However, if your goal is to create an easy to use desktop-like website/web application building/editing experience that maximizes code reuse across applications (built on the same framework) on a Node.js/WebSocket/MongoDB/HTML5 stack, however, then my approach with packaging the back end code along with the front end code makes more sense. Yes, you may need to add a REST API on top of the back end if you need that.

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

#42

Post by nahname »

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.

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 what the developer can do. At best you get indirect access to things you need (Application state, Database, etc...) and often times you have no access.

They are the worst form of abstraction. Extremely easy to do one thing. Hard to customize and nearly impossible to do something unintended.

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

#43

Post by cutie »

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…

How about the dojo widgets, do those qualify?

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

#45

Post by ilaksh »

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…

To say that ASP.NET is a nightmare.. I just don't think that's accurate. None of the ASP.NET models are my ideal, and there are plenty of things that can become problematic with the different types of ASP.NET development, but that doesn't have to be the case.

I think that it isn't that hard to have a difficult experience with widgets, but that doesn't invalidate the model, and not all component frameworks are alike in regards to things like ease of extension/modification etc.

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

#46

Post by neeleshs »

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…

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.

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

#47

Post by trung_pham »

Why are people so quick to dismiss Yahoo Mojito? All these frameworks only run inside the browser. A little ehh to me, nothing revolutionizing. Yahoo's Mojito is a game changer. It can run in the browser and on the server. And it's SEO friendly!

Really wish Yahoo does a better job at marketing their own framework.

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

#48

Post by tmbsundar »

cutie wrote: post #43
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…

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?

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

#50

Post by SchizoDuckie »

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 prices in an sqlite database, and want to access and filter those, especially offline? There's no use in using a REST service, and you'd have to implement Sqlite Support yourself in all of them. (and no, compiling from coffeescript or depending on Nodejs doesnt count)

Building a (properly performing!) CRUD system for a tablet that works offline is still a hassle. That's why i'm currently working on CreateReadUpdateDelete.js, a project that aims to solve this by bringing my tiny ORM to JS.

Check it out if you're interested in a WIP, there will be a post here soon.

http://goo.gl/avnzk

Post reply on HN