3 ms·

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 (

by nahname 14y ago

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 extending and maintaining that application.

ilaksh 14y ago
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.
- nahname 14y ago
  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.
  - ilaksh 14y ago
    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.
  - neeleshs 14y ago
    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.
    - nahname 14y ago
      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.
  - uulbiy 14y ago
    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 * * *
- deleted 14y ago
  [deleted]
dsrguru 14y ago
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.
- nahname 14y ago
  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.

by nahname 14y ago

ilaksh 14y ago

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.

nahname 14y ago
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.
- ilaksh 14y ago
  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.
- neeleshs 14y ago
  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.
  - nahname 14y ago
    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.
- uulbiy 14y ago
  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 * * *
deleted 14y ago
[deleted]

dsrguru 14y ago

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.

nahname 14y ago
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.