4 ms·

> tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x longer a I've seen no evidence to support the suggestion that building CRUD apps

> tools like PowerBuilder, Delphi, Oracle Forms, etc. Now it takes roughly 5x longer a I've seen no evidence to support the suggestion that building CRUD apps for the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc. The web is very simple but extremely flexible and you can get as much or as little out of it as you like. If it takes 5x as long it means the technical management is inept. I also have personal experience with some huge internal VB and Delphi projects during the 90s that were utter nightmares, and I know anyone else working in that era can attest to similar experiences. > JavaScript gizmos are always "breaking" when new browser versions come out. It makes DLL-Hell of the 90's look good in comparison. 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. The DLL-Hell comparison is ridiculous, there is simply nothing even remotely comparable to that on the web today. > Maybe we need one standard for "eye-candy" and games, and another for git-er-done GUI's. This is an arbitrary distinction and not a technical one. The solution is to understand which problems need solving and then to select the appropriate tool (that you understand how to use) for the job.

meredydd 8y ago
> I've seen no evidence to support the suggestion that building CRUD apps for the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc Well, I have! We actually did the test, with Anvil (https://anvil.works https://anvil.works), which is explicitly a VB/Delphi-like platform for the web. We took a straightforward CRUD-y consulting project as a spec, and built it with traditional tools and with Anvil. We did our best to keep it fair: We raced an expert against an expert, and we kept the web tech simple: simple templating, minimal JS, etc. And it was still about 7 times faster with the Delphi-like tool. (It was actually 10x faster if you just count dev time, but we counted overhead meetings too - again, in an effort to be fair. It was still "one week" vs "one afternoon".)
- tabtab 8y ago
  Similarly, many report that Dot-Net Web Forms development is usually quicker than MVC for in-house software (that doesn't need eye-candy) under normal circumstances[1], but developers don't want to use it because they are told it's "outdated" and it will rot their skill-set. [1] As suggested earlier, if the MVC stack is well-managed this may not be the case, but the average company has average management, by definition.
- root_axis 8y ago
  Huh? You don't see the irony in using a web toolkit as an example of how you can be more productive NOT using the web? Anvil is a VB/Delphi-like platform for the web, it even transpiles python down to JS in order to run in the browser. You're proving my own point for me. The web is so versatile that it gives you the power to do whatever you want, including clone a Delphi form builder in the browser. How is that an argument against the web?
  - tabtab 8y ago
    I'm skeptical such a tool can stand the test of time per browser changes. A code base may work this year, but not in 5. A dedicated CRUD-friendly GUI standard would likely be well-tested on CRUD because that's its main job, not cat videos nor Amazon product lists.
- erpellan 8y ago
  You might want to mention that you are an anvil cofounder. Doesn't invalidate your point, but it looks a little disingenuous.
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".
- 8y ago
wwweston 8y ago
> Standards compliant JS releases across the browsers have been extremely stable for years, there are no "JS gizmos" breaking because of browser releases. It isn't true to say there's no such thing as a regression bug with browser releases. Example: With the release of iOS 7, for a webapp I was working on (big, household name client) we had a damn mysterious bug pop up in Mobile Safari regarding a specific event handler simply not firing on an app I was working on. After about 2 weeks, I figured out it was a newly introduced browser bug. It took another 2 weeks for the rest of the team that didn't believe me (fair enough, I probably make mistakes more often than browser teams do) to come to the same conclusion. We kludged our way around it. The bug went away an update or two later, but not w/o burning more than a solid man-month on it. That and some of my experience with Android layout bugs (as far as I could tell, there was no such thing as reproducability on that front circa 2013/2014, and nobody really cared) started the realization that, sure, we'd sortof gotten mostly past the era of IE standards lag and into a place where there'd been stable capable cross browser web standards for years... but that wasn't going to keep regressions from happening, and it was obvious that when it came to mobile, vendors were more than happy to push their own not-identically-behaving solutions to problems for things as simple as a scrolling container. And that's before we get into framework issues and dependency scenarios. I also find the web remarkably powerful and flexible as well, and calls for some other platform with platonic superiority seem odd to me... but I can see why people get frustrated. Myself, I've been moving towards backend development again (where I started), dipping my toe in occasionally to see if any of the hyped new solutions are more than rearranging the deck chairs.

meredydd 8y ago

> I've seen no evidence to support the suggestion that building CRUD apps for the web takes 5x as long as with something like PowerBuilder, Delphi, VB etc Well, I have! We actually did the test, with Anvil (https://anvil.works https://anvil.works), which is explicitly a VB/Delphi-like platform for the web. We took a straightforward CRUD-y consulting project as a spec, and built it with traditional tools and with Anvil. We did our best to keep it fair: We raced an expert against an expert, and we kept the web tech simple: simple templating, minimal JS, etc. And it was still about 7 times faster with the Delphi-like tool. (It was actually 10x faster if you just count dev time, but we counted overhead meetings too - again, in an effort to be fair. It was still "one week" vs "one afternoon".)

tabtab 8y ago
Similarly, many report that Dot-Net Web Forms development is usually quicker than MVC for in-house software (that doesn't need eye-candy) under normal circumstances[1], but developers don't want to use it because they are told it's "outdated" and it will rot their skill-set. [1] As suggested earlier, if the MVC stack is well-managed this may not be the case, but the average company has average management, by definition.
root_axis 8y ago
Huh? You don't see the irony in using a web toolkit as an example of how you can be more productive NOT using the web? Anvil is a VB/Delphi-like platform for the web, it even transpiles python down to JS in order to run in the browser. You're proving my own point for me. The web is so versatile that it gives you the power to do whatever you want, including clone a Delphi form builder in the browser. How is that an argument against the web?
- tabtab 8y ago
  I'm skeptical such a tool can stand the test of time per browser changes. A code base may work this year, but not in 5. A dedicated CRUD-friendly GUI standard would likely be well-tested on CRUD because that's its main job, not cat videos nor Amazon product lists.
erpellan 8y ago
You might want to mention that you are an anvil cofounder. Doesn't invalidate your point, but it looks a little disingenuous.

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".
8y ago

wwweston 8y ago

> Standards compliant JS releases across the browsers have been extremely stable for years, there are no "JS gizmos" breaking because of browser releases. It isn't true to say there's no such thing as a regression bug with browser releases. Example: With the release of iOS 7, for a webapp I was working on (big, household name client) we had a damn mysterious bug pop up in Mobile Safari regarding a specific event handler simply not firing on an app I was working on. After about 2 weeks, I figured out it was a newly introduced browser bug. It took another 2 weeks for the rest of the team that didn't believe me (fair enough, I probably make mistakes more often than browser teams do) to come to the same conclusion. We kludged our way around it. The bug went away an update or two later, but not w/o burning more than a solid man-month on it. That and some of my experience with Android layout bugs (as far as I could tell, there was no such thing as reproducability on that front circa 2013/2014, and nobody really cared) started the realization that, sure, we'd sortof gotten mostly past the era of IE standards lag and into a place where there'd been stable capable cross browser web standards for years... but that wasn't going to keep regressions from happening, and it was obvious that when it came to mobile, vendors were more than happy to push their own not-identically-behaving solutions to problems for things as simple as a scrolling container. And that's before we get into framework issues and dependency scenarios. I also find the web remarkably powerful and flexible as well, and calls for some other platform with platonic superiority seem odd to me... but I can see why people get frustrated. Myself, I've been moving towards backend development again (where I started), dipping my toe in occasionally to see if any of the hyped new solutions are more than rearranging the deck chairs.