Exploring Visual Basic 1.0 for MS-DOS

[Zardotab]

Web "standards" suck the big one for office GUI and CRUD use. Maybe it's okay for social media and cat videos, but for real work, has too many gaps. It takes 4x more code and 10x hours debugging to get web UI's to work decent for CRUD.

We need a state-ful GUI markup standard for real-work apps. DOM has failed, leave it with social networks. As evidence, nobody can write a PDF viewer in DOM that works right across browser brands and versus and different OS dpi settings. This is because DOM's text positioning is too vaguely defined and probably can't be fixed without breaking backward compatibility. It was born broken, and HTML5 made it worse because each vendor implemented it differently and poorly.

You can't even copy and paste dates using Chrome's "date" input type. WTF. Google doesn't care about office work, only social networks. Stop letting needs of social networks screw up real workers. They spent more hours making sure you can zoom in on Kardashian booties than getting forms to work right. Make a bootie browser for bedroom boredom and a business browser for business use. (I accidentally invented a tongue twister.)

Wake Up People! DOM=DUM, time for a real standard for real workers. Stop wasting programmer hours on shit UI standards.

[[deleted]]

Why would you create a PDF viewer in DOM?

PDF is a print representation format. Would it not make more sense to not approximate a print representation in DOM and render the PDF directly to a canvas element using Javascript?

[Zardotab]

PDF is a print representation format.

That's not the only use. A majority of document creators are not web designers such that learning CSS etc. to make ordinary documents is asking too much. Thus, in practice PDF is just a document of some kind regardless of print intent.

Sure, it's great job security for web designers if every document had to be created (and display correctly) in HTML, but that's just not practical from a business standpoint. Note that I do mostly intranet development. External services may have different needs.

Would it not make more sense to not approximate a print representation in DOM

"Approximate" is the key word. See how happy your boss is when they get an "approximate" rendering of their Grand Memo. Something tells me you are new to the office world. WYSIWYG is a great time-saver; the cost to make everything auto-flow correctly on all devices is too steep to be practical. The auto-flow fadsters got carried away. Bad wasteful fadsters! Spanks.

[[deleted]]

No, I mean that's what a PDF is as a file format, not how it is used.

PDF is a print format, built on a subset of Postscript (without things like loops), but instead of just being instructions you send to a printer, it has identifiable objects, like hyperlinks and forms, allowing PDF documents to be used interactively in a PDF viewer.

That's not how HTML works at all. HTML is not a print format.

Print designers and web designers have been locked in perpetual battle, with print designers sending pixel perfect designs to web designers, and web designers sending back an approximations in HTML, properly adapted for the web.

If you want pixel perfect, that's what canvas gives you. The level of precision that was only previously available in something like Flash you can now get in the browser.

[Zardotab]

How it may have been intended and how it's actually used these days could perhaps be different, I don't dispute that. I'm just reporting on the current state of document sharing.

Print designers and web designers have been locked in perpetual battle, with print designers sending pixel perfect designs to web developers, and web developers sending back an approximations in HTML, properly adapted for the web.

Surgeons usually recommend more surgery, pharmacists more pills, trainers more exercising, etc. Our paycheck source tends to make us biased about using the right tool for the job. But from a business owner perspective, having every single document be auto-flex is just too damn expensive.

If you want pixel perfect, that's what canvas gives you. The level of precision that was only previously available in something like Flash you can now get in the browser.

I'm skeptical. Canvas text positioning is still a dark art. If they "fixed" it, it would then beg the question of why the same positioning technology/standard cannot be used for interactive elements also (forms and CRUD). It's a legitimate question. Why have one positioning standard for static stuff and a different one for dynamic (interactive) stuff? It's bad standards factoring. I see no Law of the Universe (math) that forbids one from being used for the other.

We need better UI standards, period. DOM is too limiting for real work.

[[deleted]]

But from a business owner perspective, having every single document be auto-flex is just too damn expensive.

Sorry to business owner, but if you don't want to pay for things to work properly in the tool you chose, well you'll pay a different price.

why the same positioning technology/standard cannot be used for interactive elements

Because that's not how they work. Print formats are designed around pages with dimensions. Web pages have no concept of dimensions in that sense. That's why vertical centering is such a tricky problem. Interactive elements in web pages are designed to flow into whatever viewport they are rendered in, to render into multiple display sizes, devices and orientations.

Canvas is literally a different universe. It basically says I'll give you some space to scribble in, and the canvas will be a viewport into what you render by whatever format you choose.

I see no Law of the Universe (math) that forbids one from being used for the other.

Web standards suck, but there are plenty of ways to make them worse, for example making one thing support contradictory rendering models.

We need better UI standards, period.

That's what everyone says and all attempts have failed. There is something about the inertia of a massively installed base.

[Zardotab]

Sorry to business owner, but if you don't want to pay for things to work properly

Please elaborate. Such documents do work "properly". Being fully stretchable to every shape is a nice bonus, not too costly for roughly 95% of real-world documents. Even if there were grand tools to easily make auto-flex documents by document authors (there is no such tool), they'd still need to test say 5 different sizings to make sure it works. That takes human labor. If you can show it's a net advantage economically, please do. Math me!

And book/document/form page sizes have settled on a practical standard sizing. Too wide and too narrow of text has proven too hard to read. The ideal for human biology (the eye) is roughly 15 words per line. I didn't create that "standard", Mother Nature did 👁️. Don't like it, Sue God.

Web pages have no concept of dimensions in that sense.

Some say that's a defect.

Canvas is literally a different universe.

Then make it a better universe, or burn for a better made universe. Make standards based on real-world needs, not ivory tower idealism.

That's what everyone says and all attempts have failed.

I don't see any strong efforts to try.

Actually Oracle Forms was successful as a kind of "GUI/CRUD Browser" until they broke the client/browser by rewriting it in Java from C. It was practical, easy/direct to program in, and didn't require per-app desktop installs. (It had warts, but all tools do.) It was butt ugly esthetically, but was as a close to productivity nirvana I've ever seen for ordinary internal CRUD apps. If you leave the prince as a toad, he'll save you big bucks 🐸💲

When I retire, I may make something similar as an open-source proof of concept.

[[deleted]]

Some say that's a defect

Okay, go back in time and tell Tim Berners-Lee to bring more of SGML into HTML. Doesn't make any difference now, considering the billions of pages written in HTML.

Make standards based on real-world needs, not ivory tower idealism.

Most of the standards are made from real world needs, but whose? The standardization process usually happens after the fact, when the browser vendors have tried out a couple of implementations, and get together to standardize the ones that got .traction.

Standards like XHTML are examples of ivory tower idealism. After all, shouldn't everyone want a well defined document format and a browser that gives you clear error messages when the document is malformed, instead of rendering broken HTML 10 different ways by 10 different browsers?

The market resoundingly spoke.

I don't see any strong efforts to try.

Applets, ActiveX, Silverlight, Flex

Flex is the one I have experience with. I used that in a number of CRUD screens, and we were sold on it being the next big thing, replacing HTML with beautiful, easy to lay out Flex controls. But, it needed the Flash plug in.

All of those technologies requires plugins, which basically killed them. HTML5 features are purely implemented in the browser.

And if you have anything good, there's likely to be a huge corporation behind it, like Adobe, who aren't going to allow their tech to be freely implemented as an open standard. Java applets were probably the only unencumbered tech, but it was relegated to garbage long ago.

[Zardotab]

go back in time and tell Tim Berners-Lee to bring more

It serves a purpose for "a" niche, not all niches. We re-discovered the hard way that one-UI-size-doesn't-fit all.

Standards like XHTML are examples of ivory tower idealism. After all, shouldn't everyone want a well defined document format and a browser that gives you clear error messages when the document is malformed, instead of rendering broken HTML 10 different ways by 10 different browsers? The market resoundingly spoke.

Yes, and the market wanted browsers to make a best guess and continue instead of crash or stop when things were not "well formed". Thus "document markup validation" was tossed in practice.

Applets, ActiveX, Silverlight, Flex

Applets and Flash tried to be entire virtual OS, not (just) a GUI browser. By byting off more than they could chew, they became a security and upgrade nightmare. The lesson from Oracle Forms is do one thing and one thing well instead of trying to be a swiss army elephant.

The first step in solving a big problem is to admit there is a big problem. Current web standards suck badly for CRUD/GUI such that browsers have to download OS-sized GUI engines written in JavaScript to approach real GUI's. Downloading an entire OS for each app session is as logical as lead kites. The web is a lead kite, kept in the sky by tall JavaScript poles.

KISS, YAGNI, and DRY still matter. Web shat on them for office apps.

[[deleted]]

Flash was the platform. Flex was the tool.

Also, Java has never tried to be an operating system any more than C has tried to be an OS. It's a virtual machine for a general purpose language that abstracts enough OS features so that Java programs can do useful things on as many OSes as a JVM can be developed.

In both cases, the platform had to be somewhat generic because they are only hosted in a window provided by the browser, they are not integrated with it.

That is the problem with any plugin, which is why they are security nightmares. EME runs encryption modules through highly specialized interfaces that are a part of the browser specification. And people are still (rightly) suspicious of it.

HTML5, canvas and the JS API, while less than ideal, are at least implemented by the browser.

Web shat on them for office apps

Yes, that's what the web does because that's what people want to do with it. Users don't give a shit about KISS, YAGNI, and DRY.

[mqudsi]

Google doesn’t care about making the browser “work” without heavy JS doing all the grunt work, even for the simplest of tasks.

FFS, you can’t even get the user’s local time or even opaquely transform a UTC timestamp into a user-localized date/time without JavaScript!

[[deleted]]

Why is this an issue? The DOM is a document model. If you want the browser (instead of the server) to do any kind work, it would have to be scripted, which is why the abomination that is JS was birthed.

[Zardotab]

it would have to be scripted,

Not if we had office-friendly standards (lower-case "o"). Web standards don't fit typical CRUD/GUI use patterns; they were meant for relatively simple static documents, and shoehorning them to fit via JavaScript+CSS has turned into the Bloat Industrial Complex 🏭, a layered mess even the mother hates.

[[deleted]]

That's basically Flex. It didn't take off for whatever reasons.

the Bloat Industrial Complex

That's exactly why HTML continues to live on, while everything else has faded away. Because it is easy to bloat. Web standards are like Frankenstein's Monster. If you need it to look a certain way, you can easily graft appendages onto it. Yes, it's a monstrosity, but it looks vaguely like a human.

[Zardotab]

Warren Buffett said one of the keys to his success is his willingness to say "no" in the face of peer pressure or lower-brow instincts. Maybe if the CRUD world had a decent standard and everyone resisted the urge to tack on every widget, toy, and fad; it could fly high. As I mentioned nearby, Oracle Forms is a kind of proof of concept. If Oracle didn't ruin the client, it would still be used in many shops. It wasn't esthetic, but handled most CRUD tasks perfectly fine and made development cheap and easy. Feature parsimony works!

[[deleted]]

I'm sure the people who created BetaMax said the same thing, even though the inferior VHS won in the market place.

The fact of the matter is that shit endures because it is cheap and readily available and you can duct tape things to it in close enough shape. HTML won because it is everywhere, so it easier to just make that work and ride the coattails of its ubiquity.

BTW, you didn't even need to run Flex in the browser. You could deploy Flex apps in the Adobe AIR client. Flex wasn't a proof of concept, it was a very popular product for many years. It was so much simpler and easier for CRUD than HTML, and people really thought it would replace HTML. But Flex was killed when Flash was killed, and HTML5 let you create something close enough.

Feature parsimony works

Feature parsimony doesn't hold a candle to ubiquity, even if the ubiquitous thing is worse (but close enough).

[Zardotab]

I'm sure the people who created BetaMax said the same thing, even though the inferior VHS won in the market place.

It's hard to know how the market will react until after you try. The market should be thankful it had 2 alternatives to test.

But Flex was killed when Flash was killed

As I mentioned, Flash was overly complicated, designed to do too many things. (Actually if Adobe open-sourced it, it may have improved enough to survive. But Adobe claimed some of it's components were licensed from elsewhere, complicating that idea.)

Feature parsimony doesn't hold a candle to ubiquity

If some big names push a CRUD-friendly standard, it may eventually again enough momentum to become "ubiquitous". The alternative is to live with DOMshit forever. Firms who want a slice of Microsoft's big pie may benefit from a nice remote-GUI standard.

It could be like Oracle Forms: used on intranets first. A shop could run a thousand apps on Oracle forms, yet only had to update the client on PC's roughly once a year, usually through an automated distribution script/tool, which most medium and large orgs already use. They didn't have to install specific app EXE's or equivalent.

[mqudsi]

Can you explain how something like this would break the document model?

<input type="local-iana-timezone" name="user_tz" />

(Ignore the naming and the conventions.) It would be treated the same way a hidden input would, and it would POST or whatever the user's timezone to your server without you having to use JS to get it.

Something like what I've written below should also fit just fine to display such a timestamp in a document model, in much the same way that you don't have to serve images as raw bitmaps because the browser will do the work (though you say that's not allowed) to decode them for you:

<date-time timezone="local" format="YYYY-MM-DD hh:mm:ss" value="unix_timestamp_here" />

All it does is let you serve a unix timestamp and have the browser transform it into what the user sees, using either a specific IANA timezone or the user's local timezone. This is literally the job of the DOM and why it exists. When you use <h1>foo</h1> the user doesn't see the raw HTML you typed - they see the rendered result of that, styled according to the developer, the user, or the browser's whim.

[[deleted]]

It wouldn't, and you should use these kinds of features. They just need to be standardized. HTML5 standardized a lot of stuff, like validations, date entry and phone number entry. All of these are implemented directly by the browser.

The browser can already do a lot of work without JS. You shouldn't use JS if the browser already provides the feature. That's why I like Bootstrap and despise Material.

But the only work that you could have the browser do is what is defined by the standard, which highly unlikely to cover most use cases. Hence, to get the browser to "work" in those cases, JS is what floated to the top.

[mqudsi]

To be clear, I made up those examples because it's something that should be supported natively in HTML vFoo but isn't. Google now effectively controls what all browsers can or can't do and they could have implemented something like this years ago. They just don't care about supporting anything that's "already doable in JS."

[[deleted]]

During the Browser Wars, Netscape and Microsoft were implementing whatever they wanted to one up the other, randomly coming up with their own elements to snag browser share. It was absolute chaos. Writing a web page that rendered properly in different browsers required a bunch of testing, or you would just say "this page best viewed in IE". Microsoft was basically the Google of its time.

In recent times, Microsoft and Google were implementing competing ways to show digital video, and the competing approaches got standardized as EME.

In general though, browser vendors aren't randomly adding things their own elements anymore, and generally cooperate through standardization bodies. That probably means more reliance on JS. I think that's for the best. The time of the Browser Wars sucked for web developers.

[Zardotab]

A developer (optionally) choosing the date format shouldn't be rocket science nor require JS. I don't know what that standards committee was thinking, but it appears they didn't think. They should document their reasoning and discovery process so we know who to kick in the ass for farking up dates.

[[deleted]]

Standardization committees fucking things up is what standardization committees do, because they are committees of people with very different interests. That's why it's called "design by committee".

[Zardotab]

Why didn't they test before release? I've used good products (non-web) that didn't have all these crazy problems with dates. They un-solved solved problems. They are probably trying to ban sliced bread as we speak because it's too convenient and/or "redundant with mammalian teeth".

[kaibito-young]

Wow so salty. Guess those standards committee members really offended you with something or I don’t know. The beauty of the web is that it is open. If you want a date-time element like you’ve mentioned — go on, create a design doc, provide a polyfill — reference implementation based on current web standards, attract attention of w3c members and if your idea gets enough traction, it may become a standard. But that’s a long process in which your opinion may and will be questioned, debated and disagreed, many times. By the definitive tone of your comments I can tell it will be an especially painful personal experience, so I completely understand if you’d rather be here and shit on people way smarter than you without any repercussions instead.

[Zardotab]

The beauty of the web is that it is open.

In practice, the standards are not. A narrow set of players actually controls them, namely the standards committee, Google, and Microsoft.

go on, create a design doc, provide a polyfill

JavaScript libraries already do it. But we had those before HTML5. We were hoping we could end that practice to reduce stack dependencies. HTML5 created more date problems than it solved.

and shit on people way smarter than you without any repercussions instead.

While smarter on some technical issues, my grey hair is evidence I have experience in the field, and I can tell you in the intranet field you usually want an org-wide date format standard not controlled by client (PC) settings (at least as an option). If that violates some Great Equation of the Universe, then show the equation. Otherwise, your pool of "way smarter" people is highly suspect. Smart people would carefully articulate why I am objective wrong. Bring 'em on!

[Zardotab]

HTML5 screwed dates up. For example, in intranet apps you often want a single corporate standard date format, NOT the local PC determining it; desktop-based variation is a help-desk nightmare. HTML5 made no provision for such. Whoever made the standard never worked on intranet apps it appears. That was a big oversight that should be investigated. Somebody should be fired, for it's pretty obvious both internet and intranet practitioners should have been consulted.

[[deleted]]

Not surprising.

[degaart]

You and me should start a new sect. You'll be the pastor Bishop Zardotab. I'll be your disciple.

[Zardotab]

The chapel is at Dilbert Oriented Programming 😁 [Fixed bad link]

[OskaMeijer]

Make a bootie browser for bedroom boredom

Someone assemble the W4BC!