[tabtab]

Re: It's easy to forget, but for years after its introduction JavaScript didn't work well.

And STILL doesn't, at least for anything non-trivial. New browser brands or version often "break" a lot of libraries and code. It's not really JS's fault: HTML wasn't meant to be emulate real desktops, and shoehorning it to do so has made a giant tangled multi-layer mess.

Browser standards should be split into three focus areas:

1. DOC: Document-oriented for text display and editing. It would be similar to existing browser but with more word-processing-like features. [I removed "read only"]

2. GUI: Mouse-centric stateful GUI markup for data-oriented "productivity" CRUD applications.

3. ART: charts, games, music, and movies.

The one-size-fits-all "standard" mostly failed (job security aside), time to split and focus. Let's admit we f!!! up as an industry.

[AgentME]

>New browser brands or version often "break" a lot of libraries and code.

When has it happened that browsers have broken standardized features? Browsers have gone through large lengths to stay backwards compatible. It's hard for me to think of things that have been broken besides nonstandardized stuff (like plugins, or things that only worked in one browser to begin with like IE).

[underwater]

Websites don't exist in neat silos. Web technologies like JS aren't perfect, but they haven't failed be any stretch of the imagination. What other platforms are still alive and evolving decades after their creation?

[tabtab]

VT-100, IBM 3270 terminals, X-Window, Tk, Qt, Oracle Forms (with some caveats).

And just because "web" more or less works doesn't mean we should stop trying. Web UI's for typical CRUD are expensive to build and maintain compared to 90's IDE's. Yes, I realize it made deployment simpler, but programming has at least doubled for the same feature set at the average shop. (There are exceptions, I know, I'm talking average.)

If somebody can justify "it must be that way", I'd like to see the logic. I'm highly skeptical. We just accepted our CRUD Rut as an industry because it's good job security, not because it's efficient. That's somebody else's bill. A good GUI-over-HTTP standard would make a boatload of dev problems float away. I really miss state, for one; it was a good thing. Oh Darling State, I surely miss thee, wherefore art thou? Jetsons tech was yanketh from my finger, and replaceth with Flintstone fiddle diddleth.

(And why are my posts getting bad scores? I don't get it. Ask first, and then neg.)

[anthk]

- Tcl/Tk

- Perl5

- Python

- VT220/VT100 terminals + ncurses

[Polylactic_acid]

The problem is most pages need to fall in to 1 and 2. Wikipedia is a document website but it also has editing features and it also has interactive mouse things like the hover previews.

[tabtab]

Good point. Perhaps I shouldn't have said "read only" in #1. Just plain "document centric", including editing of documents and text.

There will always be some overlap, but that doesn't entirely diminish the value of focus. It may be possible for a given window or panel to select which focus-standard it uses to make mix-and-match a bit easier.

A given "starting" browser, typically the document-oriented one which will contain menus and lists (such as an intranet) could be configured to select the user's or org's desired GUI and Art engine. And each "engine" will contain a minimal common sub-set, mostly around existing HTML.

[agumonkey]

I used to think so, but with reactive components and css layout like grid, you have enough clear paths for most use. This dom thing seems like it's here to stay for a few decades more.

[tabtab]

Everything I've seen so far either has a huge learning curve to do right/well, breaks over time, or both. If there is a product out there that solves these, that would be nice. I'm skeptical, but I'll ask around...