Hacker News Reader

Comment by dheera | Hacker News Reader

Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested <div> layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.

View on HN

You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right?

Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...

Except that the abstraction layer for the user has remained the same.

The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.

The abstraction layer has only remained the same visually, and only for a loose definition of "visually."

In the "good old days" the user interface was 640px x 480px (original VGA[1], skipping past the original MDA, CGA, and Hercules graphics cards[2] since they predated "modern" GUIs). Then it was expanded to 800x600, etc. The programs of those days were hard-coded to the graphics adapter resolution. If a program did not support the graphics adapter you had, you had to run your GUI in lower resolution compatibility mode. Sometimes it didn't work at all.

In lower resolution compatibility mode, the program's display got uglier and uglier as the screen resolution went up.

The abstraction layer today is adaptive and high DPI. Since the abstraction layer abstracts away the actual display resolution, programs (generally) can take advantage of the resolution that is available on a given display without change, allowing a program to run on small hardware displays (phone/tablet form factor) up to mega 4K++ displays, looking better and better as the screen resolution goes up.

[1] https://en.wikipedia.org/wiki/Vga

[2] https://en.wikipedia.org/wiki/Hercules_Graphics_Card

Precisely. And even Win32, which is being touted in this thread as somehow far superior to the Web stack, was never designed for high DPI apps. It's far worse than the Web stack, with exact pixel hardcoding everywhere. That's why the HiDPI situation on Windows is such an inconsistent mess. Meanwhile, the Web scaled up to HiDPI so seamlessly that most people never even noticed any friction. This is the benefit of the declarative model of CSS.

Win32 was designed around DPI-independence from day one. That's why things like GetSystemMetrics exist. Unfortunately, the app developers chose not to use them.

GDI was originally designed to run on printers as well as screens, where the DPI values are completely different.

The declarative model of CSS has nothing to do with it. You can specify pixel values in CSS if you like.

> You can specify pixel values in CSS if you like.

And many (most?) do... leading to the reinterpretation of what "pixel" means in the CSS spec. Yes, CSS pixel does not mean a physical pixel on the screen.

> Win32 was designed around DPI-independence from day one. That's why things like GetSystemMetrics exist. Unfortunately, the app developers chose not to use them.

Integer pixel coordinates are right there in the most fundamental functions:

    HWND WINAPI CreateWindow(LPCTSTR lpClassName,
                             LPCTSTR lpWindowName,
                             DWORD dwStyle,
                             int x,
                             int y,
                             int nWidth,
                             int nHeight,
                             HWND hWndParent,
                             HMENU hMenu,
                             HINSTANCE hInstance,
                             LPVOID lpParam);

WPF is perfectly fine for high DPI apps and still beats all this web stuff by orders of magnitude.

CSS people still think a grid is a choice of "small" "medium" and "large" columns/rows. Haha.

> WPF is perfectly fine for high DPI apps and still beats all this web stuff by orders of magnitude.

> CSS people still think a grid is a choice of "small" "medium" and "large" columns/rows. Haha.

CSS Grid is literally Microsoft taking the WPF grid layout and porting it to the Web!

Yes, that is what I'm saying. They are not porting it because previous solutions have been just as capable.

But they did port it. That's why CSS Grid exists…

Yes, but his point is that for ages it didn't exist. Like, for 2 decades and something, was first tables, then "floats" BS.

And even now it's still not mature and supported in all browsers.

Isn't this a false dichotomy? Why not create more modern, declarative native APIs and libraries, or use them where they already exist?

> the old stuff worked just fine

> we don't need the new stuff

> how about we throw both away to shut everyone up, would that make either side happy?

How about: Take what we learn from new development so that we can improve the older, lower-level stuff, and strip away some unnecessary levels of abstraction?

Yep. I did some swift development recently and while I absolutely loved the language I was struck with how much worse the uikit APIs are compared to react.

There's nothing special about javascript the language. The nice thing about web development is that the really fast framework iteration cycles. And everyone complains about them, but as a result we have some fantastic APIs for UI development in javascript land now. (Eg, react.)

What I want to see is someone port those lovely abstractions across to native languages. For example, a port of choo[1] to swift on top of uikit would be gloriously fast, efficient, small and easy to work with.

[1] https://github.com/yoshuawuyts/choo

Because it's less effort and more likely to be successful to just improve Web implementations.

Sure, but it's also more likely to make my laptop with 16 gigs of RAM, 8 simultaneous threads and SSD feel more sluggish than the one I had 10 years ago.

Edit: I'll add, I frequently see people say that Windows XP was the best OS ever made. Why the rose-tinted glasses? It was the tail end of the era when hardware was getting faster, faster than software was getting slower.

Where are the Michael Abrash's of today teaching people how to write tight, fast code? Seems a lost art...

Yes, I know, he's still around...

Luckily there are a few people that still care, just look at the response Handmade Hero has gotten.

Those videos on data oriented design were also very interesting: https://github.com/taylor001/data-oriented-design

The thing is, using C++ instead of React for mobile development of a simple application would probably make me miss deadlines... So we just stick to whats popular.

Building UI's in something like Qt, GTK or swing was never really that time consuming, especially given the limited amount of controls one screen in a mobile app.

Except today's machine language is javascript.

Except that the abstraction layer for the user has remained the same.

This is absolutely not true.

Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos (or control-control sequences for WordStar users like me).

Going from desktop apps to webapps changed the abstraction layer of how we access and share documents. No more installing software on the desktop. Docs are available on every computer we log into. Multiple people can edit the same document.

Maybe you don't care about document sharing and would be happy installing old school word processors and spreadsheets? That's a fair statement to make, but the market appears to be voting otherwise.

>No more installing software on the desktop

At least VS Code has to be installed. It is a plus for Google Docs & Co, but not universal. And in most cases, instead of installing you now have to create an account.

>Docs are available on every computer we log into. Multiple people can edit the same document.

Those features are completely independent from the platform the application uses. Those features are commonly implemented in web apps because for a long time they had no other choice, but cloud storage and collaborative editing can be equally well implemented in a destop application.

> Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos

cough Blender ...

Unfortunately - the OSS world has a shortage of good UX people, and the engineers tend to be the ones steering the ship.

I would point to Eclipse as another classic example of "obviously designed by an engineer". There's tons of functionality under the hood and it's a fantastic jumping-off point for further customization... but its layout is intensely non-intuitive in so many ways compared to a purpose-built IDE.

Everything is locked away in menus and "perspectives". If you're writing a Java web app - do you want the Java perspective, the Java EE perspective, the Web perspective, or the Debug perspective?

I hear GIMP's no picnic to work with either but can't confirm personally.

I fear the day "good UX people" come to GIMP and Blender.

It used to be that OSS was developed by people that actually used it. Maybe it wasn't pretty, it had a steep learning curve, but it got things done and was efficient once you learned how. Often you got fresh perspectives on how an interface could be done, since people got fed up with existing solutions.

Nowadays you get UX experts preaching how an interface is supposed to look like, which mostly means copying Apple or Google. You get tons shiny whitespace. Burger menus, because that's what "everybody is used to".

GIMP with "good UX people" would turn into a bad copy of Photoshop.

GIMP is pretty easy to pick up if you've used desktop apps before. It follows the sort of conventions you'd expect.. Blender, on the other hand, has a very unique approach to UX.

Well, that is true of nearly all 'pro' creative apps. Maya, Illustrator, ...

>You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right?

No, we don't. With Windows API there's no sandbox and extra embedded language overhead (it's still native code like in DOS, and even optimized better, able to use more available memory than DOS would allow, etc.).

Oh, and you also got the benefit of a FULL graphical interface over DOS. Here you have slower performance, extra cruft, bad apis AND the same final output (as a GUI app).

Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack.

There was a big new overhead -- in DOS you could write directly to video memory, and control the graphics cards registers directly. In windows you had to go through libraries. Until DirectX came along, it was basically impossible to write even reasonable performance animations in windows, hence the lack of games in windows 2 and 3.

That is not true, before DirectX there was WinG and there were quite a few good games done in WinG.

The lack of games was mostly due to reluctance of game developers to abandon Assembly and using directly PC hardware, specially because C and C++ compilers were "too slow".

WinG didn't come around until 1994 though. If you wanted to ship a game in 1990, you had a choice of using GDI or using MS-DOS.

And the "assembly" argument doesn't make any sense. You can program Windows games in assembly if you want.

Windows only became relevant for home users after version 3.0, actually the 3.1, which was released in 1992, so of course no one was shipping Windows games in 1990!

Sure you can use Assembly on Windows and there were a few books teaching exactly that, but you weren't allowed to touch the graphics hardware any more, unless you were doing a graphics driver, and do all those graphic card tricks, specially mode X.

> Not to mention that the Windows API UI toolkit, while bad, is sane compared to the web stack.

Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!".

"Sane" environments don't force you to make up a distinction between "long pointers" and "pointers" if you want to conform to the house style in order to match 16-bit x86 real mode. Or route all events through one WndProc, forcing use of "message crackers" to poorly recreate the ergonomics of addEventListener. Or have to recreate the vector graphics stack not once but twice in order to deal with the lack of forward thinking (GDI, GDI+, Direct2D). Or deal with incredible apartment threading complexity to maintain VB6 compatibility. Etc. etc.

If you had said .NET, maybe. But Petzold-style Win32 is bad.

>Completely disagree. Charles Petzold's HELLO.C is hundreds of lines of code. Hello World on the Web is, well, "Hello world!".

It's actually 87 lines of code, with a disclaimer comment, ample empty lines, a callback to play a wav when clicked, and an error message for when it's not run on NT. So, like 30-50 lines of actual Hello World necessary code. And that includes the starting up boilerplate.

That's about as relevant as complaining about the large binary size of a hello world program in a language creating static binaries. It might be larger than expected, but it usually includes a whole runtime. So once you add actual code, the binary's size doesn't scale linearly with the code size.

For comparison, a modern CSS "reseting" file, which just removes empty values is usually larger than the hello.c example.

This is the problem with trivial/contrived examples. They don't show you how the thing you're discussing scales in actual use.

In this case, the hello world in HTML is not representative of what you need to do to create a medium/large SPA in HTML.

And the old Windows api you could always wrap in higher order stuff, or even use as a basic layer to create your own UI library (still native).

The web stack, because of how it is done, you can't.

Petzold's Hello World is far more than what I'd consider a Hello World in Win32, because in addition to what you noted, it also creates a "full" window with all the associated complexity of managing its drawing yourself. A more suitable Win32 Hello World is not that much more complex than the traditional C one:

    #include <windows.h>
    #include <winuser.h>

    int main() {
        MessageBox(0, "Hello World!", "Hello World!", MB_OK);
    }

From there, one can progress onto "dialog-based applications", where the bulk of the layout is declarative (in the resource file) and the C part is two functions, a callback for messages and a main() which just calls DialogBoxParam(). No WM_PAINT handling is necessary for those. A "full window" application is actually not necessary for many use cases. I've been working with Win32 for over a decade and a half and written at least a dozen little apps for various things, but the vast majority of them are not "full window" apps.

In other words, I'd say Petzold was at least partially responsible for giving the impression that Win32 is impossibly complex even to start with. Fortunately others have come up with better introductions like http://www.winprog.org/tutorial/ or even https://win32assembly.programminghorizon.com/tutorials.html since then, but it seems that the damage has already been done and a whole generation of programmers have gotten the "Win32 is hard" notion embedded into their minds.

You are forgetting the magic CSS incantations, which are browser and version dependent, to accelerate something that is just granted on any native UI toolkit.

I agree that the paint/compositing distinction is bad (see my reply to Paul Irish), but Win32 has just an opaque a distinction. GDI is much worse for modern hardware acceleration than the Web is.

GDI is a dead worse, already replaced by better solutions for anyone that cares to use them, yet it still scales better than most web stuff.

HELLO.C in question: https://www.johndcook.com/blog/2014/11/12/hello-world-is-the...

I was unfamiliar.

Complaining that win32 has to do stupid things to get basic features in comparison to the web seems pretty laughable.

Why? The consensus opinion here seems to be that Win32 is a better API than the Web. I'm pointing out that this is an extreme case of rose-colored glasses.

I have had to use the win32 API within the last year. I left that job, I regret nothing.

As much as I want as few layers between me and the hardware as possible, I would rather have many sane layers like much of the web than 1 insane layer like the win32 API. It doesn't follow good C, C++, std library or other conventions. Many functions have multiple poorly documented modes based on which structs you pass are empty or null pointers. It also just fails often for no reason I can understand, and the distinction between windows application and console is quasi magical and counterproductive.

Posix... Is a blessing by comparison. Every time I need to touch it it take me something like a single hour and I have a function that works reliably and just does what I need. Until we get to X11 and manipulating those windows. Then I just want to punch everything, but at least X11 works once the code is written, even though its inside out and backwards.

Now I just strongly prefer to use a good library to get at OS facilities. Things like SDL, boost or Intel Threading build blocks, etc. They are fast and generally tight enough I can open them and understand down to the hardware when I want.

There is a point to be made here though that is more valid than the argument against moving away from command-line DOS applications to Windows API applications.

Moving from text-based to graphical is a much different shift than what we are talking about here. The idea here is that we are creating many abstractions to get the same basic result. I can't rewrite Atom.io for DOS, but I could rewrite Atom.io to use the Windows API directly rather than being Electron-based.

We're talking about VS Code using 13% of the CPU while idle to render a blinking cursor. What benefit does the user get from this? We could render a blinking cursor with less then 13% of a much less powerful CPU years ago.

Or, as a better example - rewriting from Electron to Qt rather than Win32. Obviously Electron was chosen to be cross platform. But I still don't get the web renderer obsession. We already have high perf cross platform solutions. Use them.

On a related note, it seems crazy to me that for actively maintained, cross-platform, native widget GUI libraries, your options are… Qt.

(Not that Qt is a bad library, but it's bizarre that such an important area is so neglected by our industry).

An interesting observation. But isn't the explanation rather obvious? Writing desktop applications to sell for money, that has quietly disappeared. It still exists, somewhere, but so does horseshoe-fitting (the few experts are probably making decent money, but it's a zombie business nonetheless). Between a few established offerings that won't be looking for a new framework any time soon, desktop-packaged web and all the gratis stuff, where would new GUI toolkits find their footing? Desktop means potentially offline and offline means almost all monetization schemes don't apply. (including those that don't work except for instilling hope in investors)

Yes, I know why it's the case nowadays: at my work, for example, I occasionally touch all the major areas of modern software development — server backends, mobile, Javascript-in-the-browser and meta-software for writing software — but I've never done what the average person, and maybe even I, would think of when they hear the term "software development."

And it does seem very very strange. I'm imagining this Socratic dialogue:

---

Socrates: What is the most popular programming language?

Developer: Java.

Socrates: And why is Java so popular?

Developer: It's the first language most people learn nowadays, so everyone knows it.

Socrates: So it's popular because it's popular?

Developer: Well, it's very similar to C++, which was the most popular language when it first came out, so it was easy for people who already knew C++ to learn.

Socrates: So why not keep using C++?

Developer: C++ had a lot of problems that made it hard to use, and Java solved a lot of those.

Socrates: Such as?

Developer: If you wrote an application in C++ that ran on any given operating system, like Windows, you wouldn't be able to run the same code on another operating system like Linux or Mac; you would have to rewrite much of your work from scratch to support more than one operating system. Java is "write once, run anywhere." Your Java program will run exactly the same way, without having to rewrite anything, on any operating system that has a Java implementation.

Socrates: Interesting! Can you show me?

Developer: (Writes "hello world," demonstrates it runs the same in both cmd.exe and Bash)

Socrates: And that works with real programs too?

Developer: What do you mean? This isn't a very long or useful program, but it is an real program.

Socrates: What's special about what you just showed me? Can't you write these command line things in any language? Look: I learned a bit of Python a few years ago. (enters python -c "print 'Hello, world!'" in both terminals)

Developer: OK, maybe that wasn't the best example, but when you're doing more complicated stuff it gets harder and harder to write code for more than one operating system in a language like C++, so a language that runs the same everywhere, like Java, or Python, is better to have.

Socrates: So like an application that you would install?

Developer: Exactly!

Socrates: OK! So could you show me a real application then? Like, it says "Hello, world!" in a window, with a menu and buttons and stuff? And it will be the same on both Windows and Linux?

Developer: No, that's not possible.

Socrates: Hm?

Developer: You can't do that in Java.

Socrates: So, Java is the most popular programming language, but you can't use the programs you write in it?

Developer: Alright, you got me there. Usually Java is used for writing applications that run on servers, not PCs.

Socrates: Servers?

Developer: Yeah, like if you go to a website, there might be an application on its server to fetch your account information from a database.

Socrates: But why do you need a special application for that? Can't you just ask for the information you need directly?

Developer: Good question. We're moving in that direction. But for some things you really do need some kind of custom logic, and for those things Java is a good solution across different platforms.

Socrates: What different platforms are there in servers?

Developer: There aren't really that many platforms. Almost all servers run Linux. But there's also a few that run Windows, or FreeBSD, which is very similar to Linux.

Socrates: So if you were on a less popular operating system, like Windows, you would use Java to be compatible with Linux?

Developer: Probably not; really, the only reason you would use Windows on a server instead of Linux is if your application were written in C#, which is Microsoft's Java competitor.

Socrates: So Java is the most popular-because-it's-popular programming language you can't write programs in, and it's useful because it runs on every platform, on only one platform?

Besides the fact that you can have reasonable UI in swing (look at IDEA), and that Java was designed for Solaris initially, and that Java is still way faster that any JS (sockets, compare-and-set primitives, +direct access to native memory, shared memory IPC and the like... which makes it prime candidate for server applications) it makes for a good example what an uneducated developer might say.

>Socrates: OK! So could you show me a real application then? Like, it says "Hello, world!" in a window, with a menu and buttons and stuff? And it will be the same on both Windows and Linux? >Developer: No, that's not possible.

swing? awt? javafx?

I exaggerate somewhat, but all three are low-quality and further development appears to be abandoned.

They are good enough in the hands of those that care to learn how to use their APIs, and way better the web will ever be.

It's a huge undertaking with a questionable business model, especially as most things have moved to the web and/or mobile. But it is amusing that there are way more free, cross-platform, high-quality game engines than GUI toolkits.

>You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right?

Ugh, reddit's standard, snarky response: "you do realize... right?"

There's simply no way to get around the fact that by and large, many in-browser apps are poorly performant by any modern standard.

To me, it seems like there's a faction within the web development community whose goal is to take things that worked perfectly fine as native apps and re-implement them with poorer performance in the browser, with seemingly no benefit.

I wish these people all the success in the world, if that's what they enjoy doing. But for the most part I simply cannot tolerate the work they produce.

The benefit is to their paymasters, as they get to extract rent (either directly or via ads) without having to contend with software pirates because the actual software logic is sitting pretty in a server cluster somewhere.

Effectively we are back to the world of time-share terminals.

Ironically, we may yet see a renaissance in native code as more investors realize that the US broadband situation (especially wireless) is not getting better anytime soon. This leads to the realization that always-on, high-speed, low-latency broadband is not a safe assumption. Disconnected operation will become more important as the product space for always-on solutions becomes ever-more crowded.

This realization that always-connected apps might be joined by disconnected apps is emphasized when looking to markets across the world. There are more disconnected people in the world than always-on, high-speed, low-latency connected. There is a burgeoning middle class characterized by sporadic, low-speed, high-latency connections, who are willing to spend some money online, for those times they make it online. They might spend pennies each today, but whoever captures those markets is addressing billions of underserved online customers. I'd take a billion $0.01 payments a day any day.

And they get to use open source libraries without having to share any single piece of their changes.

Except we're using divs, markup elements originally intended for research documentation, and using them to emulate modern UI techniques. I don't mind abstractions, but we should at least be using something built to task.

The most egregious example of abuse of technology for me is the browser version of Wolf3d, where they used divs to essentially replicate the vertical column drawing of a raycasting engine: http://3d.wolfenstein.com/

That game only works in the US, as it seems.

But if you set the cookies

    document.cookie = "age_checker=pass; expires=Thu, 18 Dec 2037 12:00:00 UTC; path=/";
    document.cookie = "is_legal=yes; expires=Thu, 18 Dec 2037 12:00:00 UTC; path=/";

It does work elsewhere, too. (Otherwise it just redirects to your local wolfenstein info site)

Abstraction is about coming up with general designs from many specific implementations. You can layer abstractions but layering is not fundamental to abstractions.

Just because a design introduces extra indirection into a system does not mean that the design is providing any abstraction.

Likewise just because a design changes from one implementation to another does not mean anything has been abstracted.

Your example of moving from DOS to Windows is really good for illustrating this. DOS had almost no hardware abstraction support, you had to include drivers for a lot of hardware into your application. Moving from DOS to Windows 3.1 only provided abstractions over the video drivers, for example when it came to network cards you still had to use DOS drivers.

Moving a text editor from DOS to Windows does not provide you with any abstractions for things like the cursor. It is only changing the API for the sake of having your text editor run on a different platform.

Guess what? This is the same with trying to get your cursor and text rendering working on a web browser. There is absolutely no abstraction here, you are just changing your code to work with the very awkward DOM API.

Yea, but that came with other benefits, like mandatory accessibility and unified look (at least on the mac). Where are they on the web? Does anyone proactively consider ARIA? Consistency of user interface is just a laughable dream.

But hey, thank god we finally have a framework we can inject ads in at will.

It depends on what efficiency buys you, and what you trade efficiency for.

When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness.

For some applications, even today, when maximum efficiency is necessary, purpose built machines ('soldering together the flip-flops that make up your logic and memory') are still used - it's just that it's often an ASIC that is fabricated.

> When Windows was developed, we had enough CPU power to do the basic tasks people wanted done with a computer at a reasonable speed - the idea was that spare capacity was being traded for user friendliness.

And in many cases that led to an instant drop in productivity. Those old green-screen systems were not pretty but they were quite efficient to use.

I've actually witnessed a very large oil & gas company switch over from those old dos programs to a new win32 program, and to a man, every person who had any experience on the old system bitched about how much slower it was to get anything done.

Having worked on the system myself, they were right (this was as a noobie to both systems).

There is something to be said for a small, tight system.

Some time ago HN linked to a blog from a Norwegian tasked with mailing 3.5" floppies to doctors.

This because the doctors insisted on using a DOS based patient journal, as they could operate it completely by keyboard while maintaining a conversation with the patient.

I speculate that one reason for this is that DOS allowed each program to have full keyboard access, while Windows and other GUI has to reserve certain keys for managing the UI (switching between windows etc).

Thus what was earlier a series of single key presses now involves holding down a modifier for the duration. And that is if the developer even remembered to put in a hotkey for said action.

You don't need the Windows reserved keys for anything with an application. You could make a fully keyboard operable UI for an application on Windows.

It's just that software makers don't do it; most everyone thinks everyone loves to do things with mouse et al.

Do you happen to have the link to this blog handy? I'd be interested in reading it.

You got me digging, so here is the HN discussion about it.

https://news.ycombinator.com/item?id=10287889

Google Docs takes a good 2-3 seconds to spin up a UI on my i7.

I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.

> there's a networked file system > a multi-user collaboration engine > a realtime notification system

None of these apply to a new, unshared document. Those subsystems can be loaded slowly over the following 10 seconds, that's fine. Is it such a hard thing to ask to make the UI responsive within 0.1 s? Like, be able to type stuff and have it appear on the screen without delay?

It's so bad that I often use the basic HTML version of Gmail because it loads in less than 1 second. The normal "AJAX" version loads in 3-4 seconds. And I have a 200 megabit connection. Who wins at getting me my information faster?

Over the past year or two Gmail has gotten really slow. I'm not sure what happened, because there are no new features I can think of that would cause this.

It's gotten so bad that I'm considering moving to another provider or using a good old email app again.

Outlook.com as well. When it launched, it was blazingly fast. Now it comes with a loading screen and really laggy.

Bloated single page apps is the curse of the modern web.

Use the basic HTML version. It's worth the loss of a couple features from regular gmail or inbox for a much snappier UI (even with it fetching full new pages from the server all the time!)

I like my vim-style keyboard shortcuts thought :-/.

I've noticed that too! Do you use Inbox? I do and I was thinking about going back to the classic interface to see if it's faster.

I tried Inbox. I thought for a while that Gmail stars == Inbox pins. When I found out that I was missing out on emails I had previously starred, I quit and went back to Gmail.

Also, Inbox did not show me full e-mails on my Android Wear smartwatch while Gmail did. Also, I couldn't figure out how to set up the filters I needed in Inbox.

Oh, I tried Inbox but Gmail was nice and fast compared to that pos.

I would recommend Fastmail. Moved over for similar reasons and never looked back

I imagine it would be hard for Google to run integration tests if the whole app took 15 seconds to load instead of 3. Not to mention that if there's an error loading part of it, people will complain that they wrote a document but it wasn't saved/shared like they expected.

Google Docs is truly amazing technology for the browser. It's just bringing its model to "native" apps that I have very mixed feelings about.

>Instantiating all that over a network in 2-3 seconds is really fast.

I see. In your opinion, do you think Chrome would be even faster if it managed to spin up an entire sandboxed docker container (in case any web site wanted one, to do whatever it wants with), as well as another one with a full Postgresql install (again in case any web site wanted one, to do whatever it wanted with, oh, and also for Chrome's own bookmarks and stuff), yet still launched within a blazing 14 seconds?

Would that be even faster, considering?

Because from where I'm standing, that wuold be 5-7 times slower.

And 3 seconds to start is 2.95 seconds too slow for me to start typing into a URL box, which could appear within 50 ms if it was done right instead of done wrong.

Chrome does things wrong instead of doing things right, and it really is that simple. I'm a human, not a network share. I use software so I can interact with it. It should do the rest on it's own time and as needed.

Loading a bunch of stuff "quickly" does not equal being quick. Google should know better.

...a whole 2-3 seconds!

Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud...

I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!

> Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud...

At the same time, we are now living in the future. With "pocket super-computers" that are more powerful than the Crays that existed when you were waiting on 300 baud text rendering, yet we are using 13% of that power just to render a blinking cursor? Does that not seem like we haven't made as much progress as we should have?

That's totally unfair. You should compare it to startup time of Word from, I don't know, 10 - 20 years ago. Around the same time (if not less), and Google Docs still can't match the features of old Words.

The point being, for the past decade or two, we've been burning all hardware performance improvements on things that are neither visible to user, nor enable them to do more with their computer. Surely, there must be ways of spending those CPU cycles and RAM bytes on things that are actually useful and enable people to do more / better / faster work.

On a per-application basis, you are probably correct. But if the additionally abstraction layers allow there to be greater diversity of applications and more tools for more niche cases because development is easier and/or faster, then that is directly immediately beneficial to the end user. Not to mention faster design iteration, implementation of new features etc.

> On a per-application basis, you are probably correct. But if the additionally abstraction layers allow ...

Windows 7 boots in approx. 5 seconds to the desktop (if no password is set), and stuff like Word or Visio starts instantaneously. Web applications on the very same computer are a whole different story.

Let's just acknowledge that SaaS is not and never was about any kind of benefits for the user or customer, but just about either centralising resources and services back to the vendor's control and/or increasing money extraction.

I have never seen word open instantly. When I do it there is always a second or two for teh obnoxious splash screen, then often 10 to 15 seconds waiting for it to do whatever. Notepad++, yeah, that opens nearly instantly.

I mostly use Ubuntu and there Libreoffice still has a stupid splash screen. After that though the amount of time is too small for me to count.

> But if the additionally abstraction layers allow there to be greater diversity of applications and more tools for more niche cases because development is easier and/or faster

Please try to find a single example where this is true. Niche cases and greater diversity all come from a lot of work keeping runtimes up to date and APIs backward-compatible. This is only because of Free Software. Trying to credit this to "abstraction layers" is insulting to all of the programmers working on Free Software libraries, compilers, runtimes and operating systems.

What I'm suggesting is that, e.g., there are more Slack, Atom, VS Code, (and those are just Electron apps) etc. and/or those apps have more features because of the speed of development and iteration afforded by these inefficient abstraction layers.

So, I can't give a specific example but am instead pointing at the diverse ecosystem of applications and rich functionality. It's logically impossible for me to prove that these apps wouldn't exist without inefficient abstraction layers. It's my supposition, and the developers who write electron apps would probably agree.

> It's logically impossible for me to prove that these apps wouldn't exist without inefficient abstraction layers.

The literally millions of applications not written on top of the specific crapware you list are an existence proof. This was the case even with assembly/Pascal/BASIC applications on microcomputers in the 1980s. Your whole argument is that somehow the web stack is easier to write applications on top of because <insert nonsense adjectives like "diverse" and "rich">. To go back to the Pascal example, a lot of people who program in Delphi strongly disagree even today, and Delphi has been around since 1995. What makes you think that the web stack has a higher speed of development than other software tools? Why do you think that high-speed development depends on inefficient abstractions? That is all total nonsense. There are a lot of problems with the web stack. You need to stop making up bullshit rationalizations and learn about other approaches to software development.

Very good questions that I can't answer. And it's not my 'bullshit rationalization' -- I'm not the one who decided to build all these products on this "crapware" stack. I'm just suggesting that this stack was chosen for some (hopefully) logical reason.

If speed of development isn't the reason, then what is the attraction? I'm serious and curious. I looked through your profile and you clearly know your shit. Are we just in a period of a bad stack being popular and used despite there being other, better options?

Why should he compare it to Word? Was it a cloud-based product that synced all files between multiple machines of radically different form-factors from PCs to phones? No?

Google Docs uses the Internet, so did anything on an old modem. Word didn't (especially 20 years ago).

So word processors have to be slow to use the network?

I'm not sure your arguement makes any sense.

I can't remember the stand-up routine, but the punchline applies:

"10secs! I was supposed to be at work 15 seconds ago!"

thanks.

https://www.youtube.com/watch?v=_HozBKiWGsQ

Yeah. I remember when Gmail introducing the floating compose window with some limited window management was a big feature. But, desktop GUIs have been doing this since the 80's...

> instead of a native widget that writes directly to the screen.

"Writing directly to the screen" (by which I assume you mean writing pixels one by one to the framebuffer) is a bad idea for modern graphics hardware. It was fine on the 486, but nowadays you need the ability to do global optimizations for good 2D (or 3D) graphics performance. Ironically, the Web stack is much better positioned to do this than, say, Win32, because of the declarative nature of CSS.

Besides, as some downthread have pointed out, you didn't "write directly to the screen" in Win32. You went through GDI.

It seems reasonable this might be true, but it's not. In video games we went down the road of retained-mode graphics APIs (declarative-type things, so that they can do the kinds of 'global optimization' you mention) but we abandoned them because they are terrible. Video games all render using immediate-mode APIs and this has been true for a very long time now and nobody is interested in going back to the awful retained-mode experiment.

You build custom retained-mode APIs on top of the immediate mode APIs—they're called game engines.

What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL. You frequently end up switching shaders and issuing a new draw call every time you draw a rectangle, and you draw strictly in back to front order so you completely lose your Z-buffer.

Imagine if games worked like that: drawing in back to front order and switching shaders every time you drew a triangle. Your performance would be terrible. But that's the API that these '90s style UI libraries force you into. Nobody thought that state changes would be expensive or that Z-buffers could exist when Win32, GTK, etc. were designed. They strictly drew using the painter's algorithm, and they used highly specialized routines for every little widget piece because minimizing memory bandwidth was way more important than avoiding state changes. But the hardware landscape is different now. That requires a different approach instead of blindly copying what the "native" APIs did in 1995.

Ehh, game engines are not really retained-mode in the way you mean. There isn't usually a cordoned-off piece of state that represents visuals only. Rather, much of that state is produced each frame from the mixture of state that serves all purposes (collision detection, game event logic, etc).

"What happens if you try to present an immediate mode API for UIs is the status quo with APIs like Skia-GL."

I don't know what Skia-GL is, but in games, the more experienced people tend to use immediate-mode for UIs. (This trend has a name, "IMGUI". I say 'more-experienced people' because less-experienced people will do it just by copying some API that already exists, and these tend to be retained-mode because that is how UIs are usually done). UIs are tremendously less painful when done as IMGUI, and they are also faster; at least, this is my experienced. [There is another case when people use retained-mode stuff, and that's when they are using some system where content people build a UI in Flash or something and they want to repro that in the game engine; thus the UI is fundamentally retained-mode in nature. I am not a super-big fan of this approach but it does happen.]

"and you draw strictly in back to front order so you completely lose your Z-buffer"

That sounds more like a limitation of the way the library is programmed than anything to do with retained or immediate mode. There may also be some confusion about causation here. (Keep in mind that Z buffers aren't useful in the regular way if translucency is happening, so if a UI system wants to support translucency in the general case, that alone is a reason why it might go painter's algorithm, regardless of whether it's retained or immediate).

"But that's the API that these '90s style UI libraries force you into."

90s-style UI libraries are stuff like Motif and Xlib and MFC ... all retained mode!

I don't agree that an IMGUI style forces you into any more shader switches than you already would have. It just requires you to be motivated to avoid shader switches. You could say that it mildly or moderately encourages you to have more shader switches, and I would not necessarily disagree. That said, UI rendering is usually such a light workload compared to general game rendering that we don't worry too much about its efficiency -- which is another reason why game people are so flabbergasted by the modern slowness of 2D applications, they are doing almost no work in principle.

Back to the retained versus IMGUI point ... If anything, there is great potential for the retained mode version to be slower, since it will usually be navigating a tree of cache-unfriendly heap-allocated nodes many times in order to draw stuff, whereas the IMGUI version is generating data as needed so it is much easier to avoid such CPU-bottlenecking operations.

I will also say that this is not an academic argument for me; I am in the middle of writing yet another immediate-mode GUI right now, for the game editor I am working on. Every day I am freshly glad that I am doing things as IMGUI instead of RMGUI.

Here is a (somewhat old) video explaining some of the motivations behind structuring things as IMGUI: https://www.youtube.com/watch?v=Z1qyvQsjK5Y

This argument looks like you and pcwalton are arguing about different definitions of "immediate mode API". I think both of you agree with each other on object-level propositions.

pcwalton seems to be presuming that part of the contract of an "immediate mode API" is like old-school ones it actually immediately draws to the frame buffer by the end of the call.

Whereas you are talking about modern "immediate mode API"s where the calls just add things to an internal data structure that is all drawn at once, avoiding unnecessary shader switches etc. IIRC this is how Conrod (Rust's imgui library) and https://github.com/ocornut/imgui work, although with varying levels of caching.

One point to make about retained mode GUIs is I remember reading an argument that immediate mode is great for visually simple UIs, such as those in video games, but isn't as good for larger scale graphical applications and custom widgets. For example when rendering a large text box, list or table you don't want to have to recalculate the layout every frame so you need some data structure that sticks around between frames specific to the widget type, so that's what retained mode APIs like Qt do for their widgets.

Sure you can do the calculations yourself for exactly which rows of a table are currently in view and render those and the scrollbar with an immediate mode API, but the promise of toolkits like Qt is that you don't have to write calculations and data structures for every table.

"so you need some data structure that sticks around between frames specific to the widget type, so that's what retained mode APIs like Qt do for their widgets."

Immediate mode GUI systems are allowed to keep state around between frames and the most-featureful ones do. The "immediate mode" is just about the API between the library and the user, not about what the library is allowed to do behind the scenes. The argument that retained-mode systems are inherently better at this doesn't hold water; it is kind of an orthogonal issue.

I'm definitely aware of this, it's why I mentioned "varying levels of caching". The Conrod imgui that I mentioned basically uses retained mode GUI data structures behind an immediate mode API through diffing for performance reasons.

This works just as well/quickly as a retained mode API in almost all cases. There's some cases like extremely long tables with varying row heights and sortable columns, where you need an efficient diff of the table contents. Since recalculating layout and sorting every frame is inefficient. Retained mode APIs do this with methods to add and delete rows. It's possible to do with an immediate mode API, but to detect differences in the rows passed in quickly you need to use a functional persistent map data structure with log(n) symmetric diff. Or you can just have an API that is mostly immediate mode but has some kind of "TableLayout" struct that persists between frames and is modified by add and remove functions.

I'm curious what API you would use for implementing a table with varying row heights (that you only know upon rendering but can guess beforehand), sortable columns and millions of rows. I implemented this in an immediate mode GUI API a few months ago, and I did it with persistent maps and incremental computation in OCaml. Incrementally maintaining a splay tree and a sorted order by symmetric diff of the input maps. This isn't as nice of an API in languages like C++ so I'm wondering if there's a better way.

"I'm curious what API you would use for implementing a table with varying row heights (that you only know upon rendering but can guess beforehand), sortable columns and millions of rows."

In general my policy is that when things get really complicated or specialized, the application knows a lot more about its use case than some trying-to-be-general API does, so it makes sense for the application to do most of the work of dealing with the row heights or whatever. (It's hard for me to answer more concretely since it depends on exactly what is being implemented, which I don't know.)

Motif and Xlib use expose events to handle drawing. Doesn't imply retained mode drawing; you could use either in the handler.

It is a little confusing because we are talking about both rendering and GUIs, but ... "retained mode" in this case refers to the GUI itself, not the method of drawing. Motif and Xlib are "retained mode" in the GUI sense because if you want there to be a button, you instantiate that button and register it with the library, and then if you want it to become visible or invisible or change color you call procedures that poke values on that instantiated button. In IMGUI you don't preinstantiate; you just say "draw a button now" and if you don't want it to be visible, you just don't draw it, etc.

This is a fair point. All the mapped XWindows are certainly "retained" from this point of view.

But can you imagine something like Word being written without the "retained-mode" abstraction?

Yes, absolutely, and in fact I think it would be a much better program.

There is plenty of available spectrum between native widgets and writing entire applications inside the web browser. Electron is a fashion statement and a convenient short cut to portability, that comes bundled with a mountain of complexity and technical debt. Moving the DOM to a native "server" removes most performance issues and allows applying the full power of a real language. https://github.com/codr4life/libc4dom/blob/master/tests/main...

Separating layout from styling and behaviour is something that many GUI toolkit developers have decided is beneficial.

Most "modern" mainstream native toolkits - e.g. GTK+ 3, Qt 5, WPF - encourage this separation into layout - GtkBuilder, QML, XAML - and style - CSS, Qt Style Sheets, XAML Styles.

So, this isn't a "web browser" problem. Or, this style of GUI isn't the problem with Electron. I find GTK and Qt apps to be plenty responsive enough, even when their GUIs are loaded from XML files.

Also compare Google Docs with Microsoft Word and LibreOffice cold start up time. You will see 2-3 seconds is fast and the two mentioned are not even loaded from a remote resource...

Excel loads in ~1 second...and doesn't have UI lag after it does.

Try working with large data sets in Google Docs and you'll have that 2-3 second lag time with _every_ operation you perform.

On the flip side, the new Windows "Metro" style calculator app takes several seconds to load ... and is less usable than the old calc.exe.

I've found this so often, I have a dual Xeon and 16GB of RAM and a calculator of all things taking more than a second is unacceptable.

I got a popup inside the calculator asking for feedback about it once with an inbuilt form and submission. I can only assume it has toooooons of hidden away cruft that does everything but assist in calculating things.

I can see it now.

Manager: All apps have to use this feedback framework now, no exceptions. Getting feedback is super important so we can be more Agile!

Dev: ok... uh, but this is 40x the size of all of calc.exe. Plus it's just a calculator and we've refined it for years so it's pretty good already. Isn't that kinda nuts?

Manager: metrics! Feedback! Agile! Just do it!

IMHO calc.exe has been getting worse since XP:

https://news.ycombinator.com/item?id=10791667

(Note that the "Calculator Plus" mentioned there has --- not suprisingly(!?) --- disappeared from Microsoft's download center, but you can still find the official, signed installer by searching for "CalcPlus.msi".)

It takes maybe half a second on my 4 year old Core I5.

Sometimes it does. I've seen this happen on several machines, some containing recent i7s. And if it does "pop up" quick, it has a loading screen. Let that sink in. It actually has a full-colour screen while it figures out how to render a few numbers and buttons. FFS.

Which is still kinda impressive given that calc.exe starts in milliseconds.

Or try working with it over an intermittent connection, everything goes haywire.

If you don't have plug-ins, Word 2010 (which, even without plugins is far more functional than Google Docs) loads in under half a second on a modern machine.

I really can't reproduce that. I used MS Office since Office '97, and even Office 2000 on a Windows 98 machine loaded in about three seconds. Nowadays, with Office 2010 or newer you won't even see the splash screen anymore. Start menu -> click -> poof, application is there. Google Docs is nowhere near that.

Very simple, there's a couple of orders of magnitude greater number of developers and designers who have skill with web technologies than native UI. Similarly there's a couple of orders of magnitude more options of UI frameworks and design patterns. Add to the fact that Blink, Webkit, V8 and Chakra have been constantly pushing the bounds on speed bringing a web technology based front end within touching distance in terms of speed vs. native.

Given all these factors, any product using web technologies for UI can move much faster than products which don't. Like how Sublime and every other programming text editor basically got eaten up by VSCode and Atom in about a year and half.

It's the typical web story. You can get to "good enough" with blazing speed, but the limitations of the web make it hard to achieve a high level of polish.

Very simple, there's a couple of orders of magnitude greater number of developers and designers who have skill with web technologies than native UI.

There is a very succinct rebuttal to that, and a good explanation for why apps based on "web technology" are they way they are: "quality is not quantity."

> Very simple, there's a couple of orders of magnitude greater number of developers and designers who have skill with web technologies than native UI.

[citation needed] - web application development is incredibly complex and can't be compared to just "web development" (e.g. writing a HTML document or template and styling it).

I still use Sublime. I've also used Atom and I didn't see any features it had that Sublime didn't. They're both very basic text editors, with the difference that Sublime is about 100x faster and less bloated.

I don't get this criticism. HTML/CSS is the closest we have to a universally understood syntax for designing interfaces.

Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it.

Any issues with performance is due to the implementation of the platform that renders this HTML/CSS interface. It's much more likely Google Docs feels sluggish due to the javascript it executes in order to control the rendering of its html/css, rather than the rendering itself.

HTML and CSS are a bad fit for rendering heavy graphical interfaces because they fundamentally follow a document flow rather than grid-based layouts. Flexbox and css-grid are helping some in this area, but they are not used very often.

(not to say that HTML and CSS aren't useful, but they are far from the idea means of rendering a UI).

HTML does work fine when you use it for mostly document focused work, and I enjoy the interactivity and connectivity that web browsers have brought to the web, but I'd love to see an improvement on it all.

Flexbox is that improvement.

If you discount flexbox due to "not [being] used very often", then you can't logically argue for burning down the HTML and CSS stack and replacing it with something else that has zero market share.

My point wasn't so much that Flexbox isn't that improvement, but that I haven't yet had a chance to fully learn it, and I suspect that a lot of front-end developers are in a similar space. I plan on rectifying that soon, but it is yet another thing to add atop the large number of other things that comprise understanding modern web browsers.

I'm not saying that we should burn the HTML and CSS stack. It has served the web very well and will continue to do so, but until the last few years, it's been a document focused stack that's been twisted into doing app development, and in some sense, it still is.

HTML and CSS are not the best tool for heavy GUI development, a la Photoshop, Visual Studio (not VS Code) or other large GUI intensive things. Most web apps have yet to replicate the combination of features and/or performance of those types native applications. Flexbox is an improvement there that helps with layout, but that doesn't change the fact that we are working with the DOM under the hood, with all of its various quirks and performance issues. (Not to say other GUI frameworks/APIs are perfect, or necessarily better. Some of them just allow you to optimize a little closer to the metal).

One can point out that large GUI tools like Photoshop aren't being created as much these days, outside of AAA game dev, CAD, or the like, or that many large GUI's use web views to help display documents, a la Steam.

I sincerely hope that Servo's "Web Browsers are essentially AAA game engines" approach catches on.

I'd be interested to see how an event-based html5 canvas GUI library would compare to DOM.

Q: How do you make a video maintain an aspect ratio and fill up the width of a parent? A: Nested div hell.

Q: How do you make an image maintain an aspect ratio and fill up the width or height of the screen, whichever comes first? A: Nested div hell and JavaScript.

Q: How do you make a scaled background image stay put even when the keyboard input pops up on a phone? A: Supreme JavaScript, CSS, and div hell.

Q: How do you center a paragraph of text vertically in a div? A: Nested div hell.

I'd say FlexBox is pretty inadequate. Why can't we have things like:

    #my-video {width:80%;height:calc(width*2/3);}

CSS object-fit handles your first two complaints, and CSS Variables handles your last one.

Aren't CSS Variables just constants you can reuse? How are they going to let you set width to 80% and height to 2/3 of whatever that ends up being?

Because percentages in heights are usually relative to the width of the containing block.

Just because it's the best we have (if you're looking for a cross platform solution, anyway) doesn't mean that we've reached the peak and can just quit. We can do a hell of a lot better, and doing anything less is tragically underselling ourselves. There are no laws of physics preventing a better solution from existing. No, creating something better isn't easy, but neither have any of the other technological breakthroughs.

HTML/JS/CSS is just a stepping stone like any other, not an endgame. Don't grow complacent with it. Demand something better.

> it's the best we have (if you're looking for a cross platform solution, anyway)

No it's not. If you want a fast full-featured cross-platform GUI toolkit, there are many: GTK+ and Qt are especially great, and have bindings for several languages.

I can't speak for Qt, but GTK+ is not that great outside of the Linux bubble. IMHO, of course.

Qt is not that fun either, at least two years ago. Old style class hierarchies, clunky abstractions and awful build step (QMAKE). It got better with the use of lambdas, no longer necessary to have class to connect to a signal, lambda works as well.

However QML is an improvement. It was a bit quirky to get render the way you wanted and it was not native & look and feel, but maybe have gotten better since I used it. I could imagine that TypeScript + QML could be quite pleasant. Big downside is that the install size of your program is quite big.

They aren't that great in the Linux bubble.

I say that from the developer and the user perspective.

Qt isn't native. They're drawing their own widgets that look close to native - that's why you can theme Qt apps.

Factually incorrect, since Qt uses native widgets when possible. Applying Qt stylesheets usually disables use of the operating system's styling engine, i.e. only then Qt starts drawing the widgets by itself. Widgets that are not part of the native widget assortment are drawn by Qt.

Then what is this blog post about? https://blog.qt.io/blog/2017/02/06/native-look-feel/

Qt Quick Controls which has nothing to with QtWidgets.

> Posted in Dev Loop, Qt Quick Controls, Styles

"Quitting" is not how I'd describe Atom and VS Code.

You might not like the envelope they are pushing, but they are cutting-edge explorations into web tech, coinciding with other cutting-edge developments like HTML/JS -> Native interfaces.

Are they really cutting edge? Or are they just an excuse to cram more javascript and web tech into unrelated areas.

Just because js is good on web, doesn't - and shouldn't - mean that we should be doing that.

There are now many more expressive languages which compile to HTML, CSS and JS. We are 'stuck' with these 3 technologies that are still very functional and we should just embrace them as the low level language of UIs.

Of the 3, javascript is the most dispensable, there's nothing stopping us writing platforms which have UIs designed in HTML/CSS but have a DOM controlled by python/c#/ruby.

I was not suggesting we stop progressing, but we need to recognise the phenomenal amount of overhead involved in replacing these 3 technologies. What benefit would be served when they can just be abstracted on top of, at least with regards to the web?

Case in point, Assembly Language, we could theoretically replace the standards that have been reached over decades of collaboration with something more suited to our modern leanings. But what would be the point, when we've long since abstracted it out of our minds?

Why invent a new standard? HTML is fine, CSS is fine. Most importantly, everyone understands it and can work immediately with it.

In order to render HTML, CSS and JavaScript, you need an entire web rendering engine. A new standard would let us get by with a lot less.

> In order to render HTML, CSS and JavaScript, you need an entire web rendering engine.

Getting to piggyback on V8 and Blink work is, I suspect, often a benefit rather than a cost in the eyes of developers of Electron-based editors. Sure, it's bigger resource load, but for use cases where the performance is acceptable, it's a lot less developer load to get the functionality out the door.

Until you have to reimplement even blinking cursors.

No, even after that I'm pretty sure it's a net win in developer time.

>Why invent a new standard?

Because they suck?

Care to argue why? Also, there are countless alternative languages to compile down to HTML or CSS available. Feel free to create your own if none agree with your personal leanings.

CSS has many weird is corner cases where you have an issue and after a lot of debugging, trying things, getting mad you find on Stack Overflow that you add a ilogical rule like "min-width:0", so css is ok until you end up in a tricky problem where you need to understand how the css code works under the hood to fix. Other issue with css is too big and complicated, good layout modes are added but we stil ahve the old ones and you need to understand everything because most developers work on existing code and you hit all kind of layouts like floating,absolute,relative. Flexbox layout seems better but stil worse then layouts I have seen in MXML and WPF. So ignoring JS that you could replace, getting a new GUI for the Web inspired by MXML/WPF or QML with a sane subset of css would improve the situation.

> you add a ilogical rule like "min-width:0"

Yeah, like my favorite of these lately, widows and orphans. Chrome changed a default that affected inline-blocks within columns that caused them to wrap prematurely after version 52 or so. It is especially bad because the other popular browsers don't even support these yet and looked fine.

>Care to argue why?

Where do I start?

1) Designed for document presentation, not for apps. 2) Limited widget selection (native forms and that's it). 3) Different implementations between vendors. 4) Bad at layout (20+ years to get to Flex and Grid CSS layout which kind of resembles UI layouts but is still not supported everywhere. 5) Slow 6) Batter hungry 7) Too many un-needed UI layers (DOM over native widgets) 8) Extra language layer (JS on top of v8 on top of native execution) 9) JS is not the best language to write large scale software (to put it mildly) 10) Restricted access/integration to native platform APIs.

Do you want to listen to the reasons, or just tell them to "go make your own if you don't like it"? You can't have it both ways.

I agree that simply saying X sucks is not a valid argument. Howeever with CSS/HTML the flaws are too numerous and already discussed ad nauseam over the past 15 years. Everytime a new version of CSS comes out, people go and try it and find out that it sucks, whether its th broken box model or the broken float layout techniques or the constant fiddling you are forced to do to get anything working. Every web developer I've seen adopts the 'edit and refresh' trial and error model of developing which is the direct result of a bad spec. Which also explains why there isn't even a reference implementation. As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI.

> Which also explains why there isn't even a reference implementation.

As someone who has spent years implementing those standards, a reference implementation would not help me at all.

> As far as UI layout is concerned I am fairly sure I could out-compete a web developer in terms of time taken to implement, using something like IMGUI.

Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.

>a reference implementation would not help me at all.

Well, considering that the web has been for decades a landmine of subtle rendering differences based on different interpretations of the same standards, it would surely help others...

Also, I'm not sure what you're saying here. That, warts and all, you love the web as a programming platform?

Well, maybe you do.

But then again, you don't program everyday IN it. You program a rendering engine for it in Rust, so you're safely protected from the horrors of web programming.

>Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.

Aren't (or at least weren't) most computer games "immediate mode" too, and far more demanding than any web page?

> Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.

Which isn't a problem if you're layout algorithm is fast/simple. If it's not, then it's a bigger issue.

>As someone who has spent years implementing those standards, a reference implementation would not help me at all.

I don't quite understand what you meant your comment to be indicative of. That nobody else would consider it useful? That you personally see no value in reference implementations at all?

>Dear imgui's layout model doesn't scale at all, due to the fact that it's immediate mode. It redoes layout from scratch every frame.

Could you detail the UI are you thinking of where IMGUI is inefficient but HTML/CSS isn't? Not asking for a formal spec, just a general usecase..

My problem with CSS/HTML is that productivity scales inversely when using them.

There was XUL and it used native widgets.

XUL is dead now, HTML+CSS won.

  > everyone understands it and can work immediately with it.

Only if by "understands" you mean "everyone is capable to throw things at the wall and seeing what sticks". I have seen a lot o HTML and CSS and let's just say, only a small fraction looked like it was done by someone with understanding "what" and "why". Otherwise it was just tortured to the point "somehow works unless someone changes something".

this person speaks truth

I've done some raw C Win32 GUI programming and I've done some modern electron stuff as well.

I know which I'd rather offer as my toolkit of choice for a project on which I wanted lots of people to contribute code to!

Please don't use win32 as an example for all native UI coding, its garbage. Consider Qt or anything else, even X11 looks good compared to win32.

Would be better to compare it to transfer a state/screen over the wire/internet on 486 vs. doing the same nowadays ;)

Well a x server on a 486 was probably also faster...

Besides the X-server point, it's not just the state transfer that's causing web UI to lag.

Javascript is meh, it's HTML and CSS that are the real culprits for the crazy inefficient GUI rendering. HTML was great for what it was designed for, but we're ten years beyond that.

Something will come in and replace HTML, it's just a matter of time. The main driver is mobile. The many layers of abstraction burn battery, one day phone manufacturers will get tired of it and do something.

Something like XUL, XAML or Enyo? Wait for it.

Something like React Native that targets Windows/macOs/Linux rather than iOS/Android? I think that this would be a better way to deal with using Javascript as the dev environment, while at the same time passing on Electron.

Reply on news.ycombinator.com