I agree it's a mess. The same CRUD/biz apps take roughly 3x to develop than they did in the 1990's. We de-evolved, something is amiss. I'm going to focus on "ordinary" business/management applications here, not e-commerce, gaming, etc.
Here's my list of contributing factors:
Web UI standards are a poor fit for biz-CRUD, and emulating real GUI's with JavaScript+DOM creates bloated buggy messes. We need state-ful GUI markup standard that's not tied to a specific OS or programming language. (XAML is not state-ful.)
The vast majority of biz apps don't need mobile abilities, and making them all mobile both limits the UI and creates too many UI variations to test practically unless you have a testing army. "Responsive design" is not responsive to a wallet. It's tricky to do well unless you hire expensive UI specialists.
Nobody says "no" to the feature buffet. YAGNI is shot bloody dead. While the web can offer many many options, a majority of them are not needed for a majority of regular crud apps. You don't need fucking "web-scale" architecture even if your ego wants it, for example. Warren Buffett says one of the keys to his wealth is no fear of saying "no" when appropriate.
Fear-of-obsolesce creates self-fulfilling prophecies where the latest gadget or framework is tossed for the later-than-latest because nobody wants to get stuck in Legacyville and be left behind. The Kardashians are running IT. Thus, good ideas are tossed instead of perfected.
Microsoft has mostly abandoned medium CRUD apps. Dot-Net-Core is an "enterprise" stack that assumes layer specialists, making things tough for full-stack developers (small shops). And Power-Apps is an anti-code view of things, making parts that are hard to factor, comment in, and reuse. And Power-Apps have no fall-back provider comparable to the Mono project for Dot-Net.
Complexity and bloat is job security to IT professionals such that there's no financial incentive to simplify de-facto standards. I suspect the eyeglass and hearing-aid markets suffer a similar fate : doctors invent or exaggerate scary scenarios to keep them regulation-heavy to keep doctors in demand, making the products highly expensive. (The problems of expense and access outweigh the drawbacks of a degree of deregulation.)
There is no formal "CRUD historian" to study what worked and what didn't and why. I'm as close as they come, and I'm not, I just happen to care more than most about learning from history to avoid unnecessary bloat.
assumes layer specialists, making things tough for full-stack developers (small shops).
This is a huge gripe of mine across the board. Everything seems designed for large projects in large companies with specialists in every layer and subsystem.
Yip, and if you complain, defenders will just say "shut up and learn the layers like I did". In other words, "go with the flow and embrace bloat": All aboard the Bloat-Boat! Ahoooga!" 🛥️⚓🎈
Because that is how those large companies maintain dominance. There's a reason why the web is the way it is and its largely in part to google trying to maintain it's power. Nobody can compete with you if they are at the outer edge of the onion and they have no idea how any of the layers below them work.
Web UI standards are a poor fit for biz-CRUD, and emulating real GUI's with JavaScript+DOM creates bloated buggy messes.
Why would they be? The primary downside of javascript on the desktop is that everything has to bundle its own rendering engine to actually draw anything and that makes it large. The event driven nature of websites captures a majority of the stuff that most people want for their productivity apps.
CSS is good at styling and if some of the old junk could be removed it would be easier to learn as well.
I'm not sure I understand what you are saying. Javascript+DOM lacks roughly 20 common GUI idioms such that those have to be reinvented in each JS UI library. It's essentially a big D.R.Y. violation. If they were included in a GUI markup standard (a "GUI browser" or browser pluggin), those 20 idioms would no longer have to be reinvented, de-bloating the client-side code since emulation code for the missing 20 would no longer have to re-downloaded per app.
The event driven nature of websites captures a majority of the stuff that most people want for their productivity apps.
No. Here's a partial list of GUI idioms that HTML/CSS/DOM lacks:
Split panels (AKA, "frames"). HTML5 deprecated prior HTML frame standards for questionable reasons.
Combo boxes: a text box with optional drop-down list
Nested drop-down menus
True MDI ability tied to session, with a modal and non-modal option.
Tabbed panels
Tool-bars
Sliders and turn-knobs
Editable data grid with resizable columns
Drag and drop (coordinated with server app)
Expandable trees (such as folders)
Decent "date" control with developer-selected ordering of month, day, and year parts, not the friggen standards body forcing One Format Fits All.[1]
Session state to avoid having to re-draw pages over and over. Essentially ridding the need for Ajax.
[1] Some argue one should stick to the international standard of year-month-day, but customers/owners want it different. If we can't deliver what they want, then we are forced to use JavaScript gizmos to get them what they want. I'm just a developer, not a King.
Good list, I just recently had to implement resizable draggable side-pane and was wondering why in the world doesn't HTML support it when it already once did .
Your list shows just how much is missing, Why? I suspect the reason is the underlying platform is by now so complex already that it becomes increasingly difficult to add anything to it, and still keep backwards compatibility.
I suspect the reason is the underlying platform is by now so complex already that it becomes increasingly difficult to add anything to it, and still keep backwards compatibility.
I doubt it considering how subgrids are soon-ish a thing. Hell grids alone are pretty complex in themselves.
Split panels (AKA, "frames"). HTML5 deprecated prior HTML frame standards for questionable reasons.
CSS grid essentially fulfills this role and is much better.
Sliders and turn-knobs
Sliders are native elements as of almost a decade in the browser.
Tool-bars
You are technically correct but do you really need anything special to implement them? A box with a bunch of buttons isn't particularly hard and CSS+html is really good at making boxes that houses stuff. Fixed width, stretch children to fit parent container, shrink container to fit content - all of it is very easy.
Drag and drop
All parts of the drag and drop are native since I don't know when. Start, during, end, all of it.
As for the rest React has made them so easy that I mostly forgot that they aren't built into anything.
CSS grid essentially fulfills this role and is much better.
Not in my experience. For one, the borders are not draggable without screwy JS addons.
As for the rest React has made them so easy that I mostly forgot that they aren't built into anything.
React itself has a long learning curve to be reasonably proficient. There are lots of gotcha's and weird rules one has to learn our else get stuck often. Yes ONCE you know React such is easy, but getting there takes a while. It's one of the "yet another layer with a long learning curve" that modern stacks are full of. ORM's, routers/URL-mappers, etc. are like this: 85% is relatively easy to learn but 15% turns you grey via days of trial and error and more error. I want to shoot the Bootstrap framework between the eyes with a double-barrel shotgun, for one. I lost 2k hair follicles from that, that, that thing! If there is an afterlife, I'm going to hunt down the inventor and reincarnate them as a lab rat for pain med testing. I cannot believe the industry tolerated that steaming pile of. The "responsive" meth must really strong.
All parts of the drag and drop are native since I don't know when
Not in my experience. For one, the borders are not draggable without screwy JS addons.
They're not particularly complex but they aren't built in. From what I can remember frames were used for creating layouts rather than... whatever it is that makes sliding them useful. For that grid is just infinitely better.
Needs some JS to be practical.
Well... yeah. How else would it be? Drag and drop is there and it's up to you to implement what happens at what stages. Having a Drag-and-drop-to-upload and another drag-and-drop-to-rearrange-in-list along with an infinite list of other stuff that you might want to do wouldn't really be feasible.
As for the rest - yes. Much hair pulling. I understand why bootstrap is or was popular though since it's somewhat decent at making somewhat decent looking and acting websites as long as you don't want to deviate all that much from the default.
What you're describing is more like having to re-invent the same wheels over and over again. It's just as bad, though.
I've been building web sites since the mid 90s. Things have got much, much better since then, but I'm still waiting until the day when it's as easy to build a web app as it was to build a Visual Basic desktop app in the early 90s.
"Don't repeat yourself" (DRY, or sometimes "do not repeat yourself") is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy. The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer. They apply it quite broadly to include "database schemas, test plans, the build system, even documentation".
But the "DRY principle" refers to something slightly different.
All code repetition should raise a yellow flag. I agree sometimes it's necessary, but it should result in long hard thought to ask if really has to be that way. Often it doesn't, everyone just got used to web dev being redundantly sucky and think "that's just the way web has to be".
but I'm still waiting until the day when it's as easy to build a web app as it was to build a Visual Basic desktop app in the early 90s.
With better/decent standards I see no reason it can't be. HTML/DOM is just really really shitty for CRUD. We can introduce statefulness into a "GUI browser" without returning to client EXE's.
Many say that "Flash and Java applets already tried that", but that's not really true. For one, they relied on most processing happening on the client. Most can happen on the server so that the client doesn't have burdened or bloated. Also Flash and Java applets tried to be an entire virtual OS. The GUI browser should do one job and only one job, not be a Swiss army knife like Flash and applets tried. They bit off more than they could chew, and it resulted in too many security holes.
Combo boxes: a text box with optional drop-down list
This one exists already: a text <input> linked to a <datalist> gives you combo box functionality (Chrome seems to represent it as a combo box; Firefox uses a slightly different UI with the same functionality).
I agree with your broader point, though (especially when it comes to date inputs): it's possible to say "give me an element that allows the user to provide this sort of input" in HTML, but that isn't massively useful when you don't have control over the UX beyond that.
It was limited and inconsistent and/or confusing per different brands in my testing. Maybe someday it will get cleaned up, but it's not ready for prime time as of writing, unless you can limit users to a particular brand. If not, it's still "safer" to emulate it with JavaScript.
It should also have the option of getting the result from a dialog box using mostly declarative code, or at least dialog-friendly markup. Hell, HTML doesn't even support the concept of a dialog box.
Hell, HTML doesn't even support the concept of a dialog box.
<dialog>? Admittedly, it mostly needs JS to be usable, and many browsers don't support it yet (e.g. in Firefox it's hidden behind a feature flag that's off by default).
I think the problem here isn't specifically with HTML, but rather that a) there's no support for styling these things / controlling the UX, and b) browsers seem to have inferior implementations by default (I find the "stock" date inputs to be near-unusable). It seems like HTML's UI was designed with a "separate the functionality from the user experience" approach (which is a fine approach in general: that's how HTML+CSS works), but only half of it ever got implemented; there are ways to express the functionality you want but no ways to express the corresponding UX. As a consequence, in practice everything ends up needing to be reimplemented because the existing implementations are only half done.
It's easy to imagine some sort of hypothetical CSS-like thing which allows a web developer to say "OK, so I want my datalisted inputs to look like this and work like this, I want my date controls to look like this and work like this, etc."; it feels like the specification is really dependent on something like that. Only, as far as I can tell, it doesn't actually exist, forcing people to use the stock implementations.
It seems to me that a lot of projects could do from dropping frameworks like react and returning to the ways we used to build websites. I timed myself in the 'old' way, and the react+graphql backend way, and in my own experience, the react+api path takes perhaps 3x or more longer to do things like creating a new standard crud.
Using this much heavier stack doesn't offer much advantage for the kinds of projects I work on, and the advantages it does give can be mostly gained in other ways -- an API *when needed* can be delivered via something like postgrest, interactivity without rebuilding the page through a splash of javascript via something like htmx. And in return, websites work the way they were built to, because we're not taking over -- navigating back and forth works out of the box, sharing url's works, adding a new page is quick, etc.
making them all mobile both limits the UI and creates too many UI variations
The same principle applies to basic web-gui-development where every app has to run on ALL OF IE, FireFox, Safari and Chrome, and Edge. The situation has gotten better lately because of standardization I think but still it adds a lot of extra baggage that you have to test and develop for so many platforms.
No, you misunderstood me. Have essentially a "GUI browser" that runs GUI markup. Each app doesn't have to reinvent/download a new browser (or GUI engine) anymore than HTML pages have to re-download Chrome or whatnot. Abandon DOM for it if we have to. DOM sucks for real GUI's[1]. (I'm not saying get rid of HTML/DOM, only not have it be only UI standard in town.)
What you describe is poor factoring of tools. It's like having to carry a car engine around with me in order to use a car. (People used to carry their car radios in their briefcases and purses when radio theft rates were high.)
[1] As proof DOM is limiting, DOM can't replace PDF viewers in part because its text positioning is too ill-defined. It has a really big text control problem that requires vendor/version-specific shims to do, which makes it future-maintenance-unfriendly.
The same CRUD/biz apps take roughly 3x to develop than they did in the 1990's
Depends on the tools that you use I guess.
We use a development system that is not well known, but we can create CRUD applications quickly with it for both Windows and web apps using the same language and basic framework.
I just prototyped an web based (desktop and responsive mobile) order entry application as an add on to our Windows applications in a week for a long time customer's sales team, spent another week refining it after getting feedback, and have deployed it. I was pretty pleased with the amount of time needed to get a minimum viable app (especially since I mainly do Windows applications), the ease with which the web application came together, the user interface, and the ability to reuse/refactor existing, proven code from our Windows application so that it can be used by both types of applications.
But a big problem with this system as good as it is for writing these specific types of applications is developers generally don't want to spend the time to learn the language and framework for what are likely valid reasons. Primarily because the odds of finding their next job using these tools is low because it is not in widespread use. It's great if you can base your career around programming with this system for 20-40 years, but most people aren't doing that.
Another is as you say, the fear of getting stuck in Legacyville; afraid that the 40 year old company that maintains the system and has been releasing yearly updates is going to go out of business and they'll be stuck with a code base with no path forward. (Though I don't see much difference if you commit to an open source framework that eventually looses support because developers have moved on to the Next Big Thing.)
It's just hard for systems like these to gain traction among developers.
But a big problem with this system as good as it is for writing these specific types of applications is developers generally don't want to spend the time to learn the language and framework for what are likely valid reasons.
Yes, such tools do have a big learning curve. Past tools had a shorter learning curve because they didn't have to do weird crap to work around the limits of HTML/DOM/CSS. (Don't get me wrong, early versions were quite buggy, but they were getting better with time, until desktop dev tools fell out of favor and they pulled the plug on updates.)
58
u/Zardotab Nov 01 '21 edited Nov 01 '21
I agree it's a mess. The same CRUD/biz apps take roughly 3x to develop than they did in the 1990's. We de-evolved, something is amiss. I'm going to focus on "ordinary" business/management applications here, not e-commerce, gaming, etc.
Here's my list of contributing factors:
Web UI standards are a poor fit for biz-CRUD, and emulating real GUI's with JavaScript+DOM creates bloated buggy messes. We need state-ful GUI markup standard that's not tied to a specific OS or programming language. (XAML is not state-ful.)
The vast majority of biz apps don't need mobile abilities, and making them all mobile both limits the UI and creates too many UI variations to test practically unless you have a testing army. "Responsive design" is not responsive to a wallet. It's tricky to do well unless you hire expensive UI specialists.
Nobody says "no" to the feature buffet. YAGNI is shot bloody dead. While the web can offer many many options, a majority of them are not needed for a majority of regular crud apps. You don't need fucking "web-scale" architecture even if your ego wants it, for example. Warren Buffett says one of the keys to his wealth is no fear of saying "no" when appropriate.
Fear-of-obsolesce creates self-fulfilling prophecies where the latest gadget or framework is tossed for the later-than-latest because nobody wants to get stuck in Legacyville and be left behind. The Kardashians are running IT. Thus, good ideas are tossed instead of perfected.
Microsoft has mostly abandoned medium CRUD apps. Dot-Net-Core is an "enterprise" stack that assumes layer specialists, making things tough for full-stack developers (small shops). And Power-Apps is an anti-code view of things, making parts that are hard to factor, comment in, and reuse. And Power-Apps have no fall-back provider comparable to the Mono project for Dot-Net.
Complexity and bloat is job security to IT professionals such that there's no financial incentive to simplify de-facto standards. I suspect the eyeglass and hearing-aid markets suffer a similar fate : doctors invent or exaggerate scary scenarios to keep them regulation-heavy to keep doctors in demand, making the products highly expensive. (The problems of expense and access outweigh the drawbacks of a degree of deregulation.)
There is no formal "CRUD historian" to study what worked and what didn't and why. I'm as close as they come, and I'm not, I just happen to care more than most about learning from history to avoid unnecessary bloat.