5 ms·

Re: This is just false. Standards compliant JS releases across the browsers have been extremely stable for years, there are no "JS gizmos" breaking because of b

by tabtab 8y ago

Re: This is just false. Standards compliant JS releases across the browsers have been extremely stable for years, there are no "JS gizmos" breaking because of browser releases. For one the standards have many fuzzy areas in them and/or vendor-specific enhancements. JS widgets may purposely or accidentally rely on such grey areas. Second, being standards-compliant doesn't mean it doesn't have bugs. As a thought experiment, if there were a decent standard multi-select-list widget (that doesn't require the Control key) in HTML or an equivalent, then it would likely be more stable than having to choose from 20 or so custom JS ones found on the web. This is because there would be roughly 20x more testing done on it because 20x more would be using it because we wouldn't need custom ones (or need them much less often).

root_axis 8y ago
"Vendor-specific enhancements" are not a part of the standard by definition. If the project is built upon vendor quicksand then technical leadership has failed (unless the product is meant to target only one browser). > if there were a decent standard multi-select-list widget I don't get the argument. You're right that there's no multi-select-list standard. What is the problem if there are 20x custom ones? Just use the one that meets all your needs. Who cares if there are 20 or 200?
- tabtab 8y ago
  I thought I explained that already. Let me try to say it a different way: if there is no decent standard multi-select widget (as an example), you get lots of small shops reinventing their own. They have too few users/testers to have a reliable product. A standard multi-select would probably have more users and more vetters, making it more reliable in the longer run. Custom JS widgets going kerplunk is a growing maintenance headache here.
  - tabtab 8y ago
    Clarification: I include vendors & suppliers of JS widgets in "small shops reinventing their own".
yesbabyyes 8y ago
As a thought experiment, if there were a decent standard multi-select-list widget (that doesn't require the Control key) in HTML or an equivalent Why "doesn't require the Control key"? AFAIK, <select multiple></select> Behaves just like a standard control from e.g. Delphi would (i.e., ctrl + mouse click or shift + arrow keys or shift + ctrl + space). No custom widgets needed.
- tabtab 8y ago
  Many find usage of the Control key unintuitive. Why not have a standard widget that displays check-boxes on the left side of the multi-list? Keep Control as a secondary way to toggle, that's fine.
  - yesbabyyes 8y ago
    > Many find [citation needed] Again, the standard, very simple control in html works analogously to the standard Delphi or corresponding control. The non-standard checkbox + multi-select widget you envision would be, IMHO, simpler to implement in js+html than in Delphi--but would be a custom widget in any implementation, as it's not a standard UI control.
    - tabtab 8y ago
      I guess I'm not understanding your point. I don't have a formal study about the (un)popularity of the Control key multi-select convention; it's merely my anecdotal observations. You are welcome to fund a formal study. (It's possible Delphi does it "wrong" also.)
      - yesbabyyes 8y ago
        My point is that the reason for web app development becoming cumbersome and time consuming is often unnecessary over-complication of simple, standard widgets using over-engineered and non-standard compliant JS "plugins", instead of built-in, standard elements. My point is also comparing apples to apples; when sticking to standard controls, web technologies are often simpler and quicker to implement than older frameworks, especially when taking into account the whole application lifecycle, including authentication, authorization, caching, and deployment of new updates. To paraphrase: The thing is, web technologies don't need frameworks; it is a framework. Use standard widgets and controls, style and enhance them if needed, stay away from kludgy plugins, and you'll be fine. Input validation, standard keyboard, mouse, touch navigation, etc built in, for free.
tracker1 8y ago
Your typical CRUD app is not going to be on the bleeding edge enough to worry about many fuzzy areas and vendor specific enhancements. As to multi-select and the like... this is why groups of developers are now leaning towards tooling around React, Angular, Vue and others. If you want something not in the box, you either make it, or pay for a custom control... of find an open-source one. Developing web apps isn't so significantly different from desktop apps from a UI perspective, it's just you get a lot more in the box. (like layouts that grow/shrink to fit with nearly 0 cost).
- tabtab 8y ago
  But browser changes for other reasons may break what previously worked in a CRUD app. And we don't need gazillion widget types for most CRUD. Oracle Forms has a limited widget set, yet has been used to build a good many apps here at our shop quick and easy. It's not esthetic, but got the job done. (It has a few clunky spots, but everything does.) I'm not an Oracle Forms dev myself; I just observed productivity. Oracle should have left the "gui browser" (client engine) as a dedicated product (compiled EXE) instead of convert it into Java, because Java had too many security bugs because it tried to be too much. The concept of Java Applets failed, not Oracle Forms itself.
  - tracker1 8y ago
    In over 20 years of web application development, the single biggest breaking change (other than bleeding edge bits) was when IE 5.0 came out and broke the legacy api for populating select elements via JS. They added the new DOM interfaces but broke the old one. It was a little painful but far from the end of the world. Classic VB, Delphi, Access, and Flex/Flash have all been good at delivering CRUD apps, if you exclude the security concerns in talking to the backend, and storing application configurations, dealing with updates etc. In the end, I don't feel it's any better overall either way. The difference is it's far easier to automate one server (or two) in a business environment than dozens or hundreds of systems.

by tabtab 8y ago

root_axis 8y ago

"Vendor-specific enhancements" are not a part of the standard by definition. If the project is built upon vendor quicksand then technical leadership has failed (unless the product is meant to target only one browser). > if there were a decent standard multi-select-list widget I don't get the argument. You're right that there's no multi-select-list standard. What is the problem if there are 20x custom ones? Just use the one that meets all your needs. Who cares if there are 20 or 200?

tabtab 8y ago
I thought I explained that already. Let me try to say it a different way: if there is no decent standard multi-select widget (as an example), you get lots of small shops reinventing their own. They have too few users/testers to have a reliable product. A standard multi-select would probably have more users and more vetters, making it more reliable in the longer run. Custom JS widgets going kerplunk is a growing maintenance headache here.
- tabtab 8y ago
  Clarification: I include vendors & suppliers of JS widgets in "small shops reinventing their own".

yesbabyyes 8y ago

As a thought experiment, if there were a decent standard multi-select-list widget (that doesn't require the Control key) in HTML or an equivalent Why "doesn't require the Control key"? AFAIK, <select multiple></select> Behaves just like a standard control from e.g. Delphi would (i.e., ctrl + mouse click or shift + arrow keys or shift + ctrl + space). No custom widgets needed.

tabtab 8y ago
Many find usage of the Control key unintuitive. Why not have a standard widget that displays check-boxes on the left side of the multi-list? Keep Control as a secondary way to toggle, that's fine.
- yesbabyyes 8y ago
  > Many find [citation needed] Again, the standard, very simple control in html works analogously to the standard Delphi or corresponding control. The non-standard checkbox + multi-select widget you envision would be, IMHO, simpler to implement in js+html than in Delphi--but would be a custom widget in any implementation, as it's not a standard UI control.
  - tabtab 8y ago
    I guess I'm not understanding your point. I don't have a formal study about the (un)popularity of the Control key multi-select convention; it's merely my anecdotal observations. You are welcome to fund a formal study. (It's possible Delphi does it "wrong" also.)
    - yesbabyyes 8y ago
      My point is that the reason for web app development becoming cumbersome and time consuming is often unnecessary over-complication of simple, standard widgets using over-engineered and non-standard compliant JS "plugins", instead of built-in, standard elements. My point is also comparing apples to apples; when sticking to standard controls, web technologies are often simpler and quicker to implement than older frameworks, especially when taking into account the whole application lifecycle, including authentication, authorization, caching, and deployment of new updates. To paraphrase: The thing is, web technologies don't need frameworks; it is a framework. Use standard widgets and controls, style and enhance them if needed, stay away from kludgy plugins, and you'll be fine. Input validation, standard keyboard, mouse, touch navigation, etc built in, for free.

tracker1 8y ago

Your typical CRUD app is not going to be on the bleeding edge enough to worry about many fuzzy areas and vendor specific enhancements. As to multi-select and the like... this is why groups of developers are now leaning towards tooling around React, Angular, Vue and others. If you want something not in the box, you either make it, or pay for a custom control... of find an open-source one. Developing web apps isn't so significantly different from desktop apps from a UI perspective, it's just you get a lot more in the box. (like layouts that grow/shrink to fit with nearly 0 cost).

tabtab 8y ago
But browser changes for other reasons may break what previously worked in a CRUD app. And we don't need gazillion widget types for most CRUD. Oracle Forms has a limited widget set, yet has been used to build a good many apps here at our shop quick and easy. It's not esthetic, but got the job done. (It has a few clunky spots, but everything does.) I'm not an Oracle Forms dev myself; I just observed productivity. Oracle should have left the "gui browser" (client engine) as a dedicated product (compiled EXE) instead of convert it into Java, because Java had too many security bugs because it tried to be too much. The concept of Java Applets failed, not Oracle Forms itself.
- tracker1 8y ago
  In over 20 years of web application development, the single biggest breaking change (other than bleeding edge bits) was when IE 5.0 came out and broke the legacy api for populating select elements via JS. They added the new DOM interfaces but broke the old one. It was a little painful but far from the end of the world. Classic VB, Delphi, Access, and Flex/Flash have all been good at delivering CRUD apps, if you exclude the security concerns in talking to the backend, and storing application configurations, dealing with updates etc. In the end, I don't feel it's any better overall either way. The difference is it's far easier to automate one server (or two) in a business environment than dozens or hundreds of systems.