Hacker News Reader

> 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), 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".)

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.

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?

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.

You might want to mention that you are an anvil cofounder. Doesn't invalidate your point, but it looks a little disingenuous.

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).

"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?

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.

Clarification: I include vendors & suppliers of JS widgets in "small shops reinventing their own".

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.

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.

> 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.

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.)

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.

I agree with native & YAGNI to a point. Multi-select that uses just the control key is confusing and clunky to users (in my experience). It just "sucks" too much. I'd prefer to see something like check-boxes on the left so one can select/un-select using the mouse. We'll just have to agree to disagree on this one.

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).

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.

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.

> 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.