Hacker News new | past | comments | ask | show | jobs | submit login
Closing a 30 pixel gap between native and web (windows.com)
378 points by vyrotek on Sept 27, 2022 | hide | past | favorite | 298 comments

> installed desktop web apps are really starting to look and feel like native apps

I think we are having the opposite problem: native apps are really starting to look and feel like web apps, and in many cases, they are.

The problem: the web has a terrible UI toolkit for desktop apps. It has clickable links and basic forms, that's all. It was made for documents, not apps. If you want better than that, you have to rewrite it all by yourself, or more likely, import a framework that does it for you. Traditional Windows apps all use system provided common controls, because they are good, and therefore they have a consistent look and feel, even through OS updates. It is even user customizable. Now it is not uncommon to see 10 different styles in a single screen, Windows since 8 is not even consistent with itself, and it is becoming worse every version. And it is not just aesthetics, there are serious usability concerns here, and system-wide customization is gone.

> Traditional Windows apps all use system provided common controls, because they are good, and therefore they have a consistent look and feel, even through OS updates.

This hasn’t been consistent since at least Vista and the release of WPF, which does totally custom control rendering. Circa 2006.

I think web is taking over on Windows because any of 10 or 15 different design systems can get you to a better app than the native (whatever that means) toolkits in much less time. It is easier to get a decent color picker in a web app than a WPF, WinForms, UWP, WinUI, or Win32 app (assuming you have a reasonably high expectation for UI/UX, as I do).

Even Office and Visual Studio (not Code) are using web technologies to render substantial parts of the UI.

> I think web is taking over on Windows because any of 10 or 15 different design systems can get you to a better app than the native (whatever that means) toolkits in much less time. It is easier to get a decent color picker in a web app than a WPF, WinForms, UWP, WinUI, or Win32 app (assuming you have a reasonably high expectation for UI/UX, as I do).

I'll grant you that it's probably easier and cheaper to get a workable "color picker in a web app," but I don't grant that going that route will get you a "better app than the native."

The reason why the web stuff is taking over is because it's cheaper while providing minimally-viable functionality, full stop. It's not actually good in any other way.

IMHO, the trend here is similar to the one consumer printers took.

The word “cheaper” here is doing a lot of work.

Yes, it’s cheaper, meaning that it allows you to ship more stuff faster. You could make the argument that this results in lower quality, but this isn’t always the case. (For example, VS Code feels great!)

Still, I’d often rather have twice the features at 80% the quality, instead of an extremely high quality product that doesn’t have the features I need.

Cheapness leads to abundance leads to innovation.

VSCode is adequate, not great. The bar for responsive and minimal application is so bad these days thanks to web apps.

You can make fast web apps and you can make slow native apps. Check out VSCode's older brother and be amazed by how unresponsive and glitchy is.

The move to WPF in 2010 killed VS. Even today on today's computers it isn't as responsive as VS2008 was.

VSCode replace Sublime, Visual Studio(full) and IntelliJ IDEs for so many developers. It has all the features >90% of developers and it is faster than VS and IntelliJ IDEs

And it doesn't support window and monitor layouts that were possible and useful in Visual Studio 2003, or probably earlier.

Agree. VS Code is simply not comparable to a full blown IDE. It's a text editor with some integrated language tooling.

Of course it is comparable. They are not quite the same thing, sure, but for many people they are definitely comparable and more often than not, VSCode is the better option. It may not support some things, but the same can be said about the “full blown IDE”.

bold statement, as you claim that VS Code would fit the majority better than say $IDE from JetBrains.

I don't know how you came to that conclusion but I'd guess that you mostly work on small projects? (where I'd say smallish is < 100K LOC)

Stuff I'd miss in VS Code coming from JetBrains Rider:

- Docking of panels to top, bottom, left, right

- built-in database explorer (with table designer, script runner, ...)

- built-in unit test explorer

- built-in memory/perf profiler (not talking about a simple text interface!)

- nice config options of project settings (in either text with completion or the UI)

- NuGet package explorer UI

- integrated IL viewer

- great git blame / annotation view

... could continue for a while

tngranados said "many people" and did not say anything at all about the "majority" of people.

Judging from the fact that many people choose VS Code over JetBrains IDEs, despite being aware of JetBrains existence as an option, seems to be prima facie evidence that it is in fact the better choice for those folks.

It offers about 5 to 10 percent of all functionality of an IDE like IDEA. Much like devs on emacs and vim, most devs on VS Code have literally no idea what an IDE offers [1].

The things that worked in VS Code's favor:

- free. "All software must be free as in beer" is still a prevailing thought in IT, and people are loathe to pay for anything, even if that anything is extremely useful and very difficult to realise and support. On top of that IDEA still has a reputation of being expensive

- reasonably fast

- plugin system is decent and much easier to get into than IDEA, to keep IDEA as an example

- LSP is an overmarketed hype, but it worked in VSCode's immense favor. While it only covers a tiny sliver of things needed for a fully featured IDE, it covers enough of the important features, and is easy enough to implement. This way even languages that never had anything decent beyond broken syntax highlights in emacs and vim now enjoy at the very least an autocomplete

[1] Code refactoring alone is dozens of pages in IDEA docs https://www.jetbrains.com/help/idea/refactoring-source-code....

Have you tried Lapce? It's way snappier than VSCode.

It's great and the best desktop app I've ever used.

I'm sorry for you if it's the best that you have ever experienced. It is very subpar and slow.

It's the best electron app I've ever used. It's so much faster than anything else I've seen use electron.

That's quite the back-handed compliment though, isn't it?

Not really, I’d say VS Code is the only electron app that can stand up to native apps. It’s not the best, but it’s pretty good.

Now, for electron, it’s certainly not a compliment. From electron apps I’ve used, only VS Code is great, Discord is good, and everything else is just really, really bad. It’s apparently extremely hard to use electron and have something close to decent performance.

Right, sorry, I meant back-handed for Electron. I have used VS Code a bit for a class, but am usually an Emacs user.

Hah, nah. Electron gets no compliment at all, backhanded or otherwise. When almost no one can create an app on it that doesn't suck, there are deep issues.

We're taking about a trillion dollar company who can afford all of the talent and has very limited time pressure. I would prefer they do it correctly.

This misses the point. A trillion dollars goes a lot further when the software is cheaper.

But VSCode isn't cheaper. They had to pour millions of dollars and countless man hours into it. And none of those translated into any meaningful improvements of the platform.

It isn't cheap wrt hardware requirements either. My 2.5 year old work laptop becomes unbelievably sluggish if I have to keep multiple Electron apps open.

Innovation? More like W95 (or even ME) compared to NT, and don't even start to compare ME against BSD/Solaris/Linux or Mac OS X.

VS Code isn’t a web app. The first release was and since then most of it has been rewritten to be a native app.

I think I agree with you, but I need a clear definition of "cheaper."

To me, "cheaper" means that companies are putting fewer resources into Windows-specific app development. That's not unexpected, given large portions of their user base are using MacOS, Android, or iOS. Why would I hire 8 developers to make 4 apps, when I could hire 6 developers to make make 3 or even 2 apps? Oh, as an added bonus, now my app can also be loaded straight from a browser, no installation necessary? And I don't have nagging complaints from small-market-share users (Linux and BSD) complaining that my app doesn't work on their machines? Seems like a no-brainer.

From a business perspective, if the end product is good enough that the customers don't complain, what reason is there to not* use web technologies?

Don't get me wrong, I hate that half the software I use today is just a glorified Chrome tab. I hate how I need 16GB of RAM to do my job.

> I think I agree with you, but I need a clear definition of "cheaper."

I think the best definition of MS products in regard with quality and usability is "cheaper" as in "he is cheap". (i.e. only using the lowest quality crap available)

Lazarus will target MacOS, Windows, Linux and all the BSD's creating binaries for all of them from a single source.

Also the deployment makes much more sense in the web. Users are always in the latest version of the software with no install / update shenanigans. This has other implications as well. The application may change internal formats since it doesn't have to worry about older instances of itself etc.

And if you build an updater in your app like chrome / firefox then it needs to be disabled for Linux distributions that have their own package manager.

> It is easier to get a decent color picker in a web app than a WPF, WinForms, UWP, WinUI, or Win32 app (assuming you have a reasonably high expectation for UI/UX, as I do).

What is a decent color picker? Everybody's idea about that is different so basically no 2 websites use the same color picker. In fact, this paper [1] found that the kind of picker (RGB vs HSV, etc...) doesn't really matter, but that better feedback made the difference. So will we get instant feedback from our color pickers now (for example text immediately turning into the color selected)? No, because designers design how they think it should look and feel, not based on how people actually interact with applications.

[1] https://www.researchgate.net/publication/220183526_Model_and...

This one looks pretty solid. There are loads of them. The demos I’ve seen all showcase live feedback.


Compare to the best I can find for WPF: https://github.com/dsafa/wpf-color-picker - no live feedback, dialog only, no documented support for modern .NET. There are some commercial controls available from syncfusion and the like if you want to pay for such things.

Compare to color dialog in WinForms: https://github.com/Kinnara/ModernWpf/issues/72

WinUI has a decent color picker, but there are other trade offs going with WinUI that make it inferior to the web environment (e.g. broken rendering of SVG/paths).

> This hasn’t been consistent since at least Vista

Yes, I believe the Windows UI (at least until 10 since I haven't tested 11 deeply) is becoming increasingly inconsistent because of the many UI frameworks out there. And, while I understand that each app's developer is free to choose whatever framework UI they feel is right for them, I find it hard to understand why Microsoft is not sticking with a consistent framework for all of its apps, it went even far by using Electron for its Teams app! However, the thing that I might never get is: Why is Windows itself (and its system apps, i.e Calculator, Notepad) isn't sticking to a single framework? Yesterday, at night, I turned "Dark Mode" on and was surprised to see that "Task Manager" keeps its Light theme. It's weird how Notepad++ has a "Dark" theme while Task Manager has not!

To "gratifies one's intellectual curiosity", check https://youtu.be/hn5QjtpjW_U

The latest Windows 11 update just switched the task manager to the new UI style with support for dark theme.

I didn't think it's a good video. If Microsoft s latest apps don't have a consistent design, they have spent more money on designing each of them separately. Each of those hover effects and custom title bars needed to be coded separately. That undermines the idea that MS "hasn't prioritised spending on design because it won't help their enterprise customers" and shows it's just an organisational problem.

> This hasn’t been consistent since at least Vista and the release of WPF, which does totally custom control rendering. Circa 2006.

Ignoring 3rd party apps, to me the windows UI died with XP where the consistency stopped being somewhat pushed on the base OS/UX itself.

Strictly speaking nobody cares what APIs are being used or if there are multiple of them as long as they convey a consistent UX. If a consistent UX is pushed on a system level, even custom apps will try to stick to it (see macos).

But the sad truth is that on windows there is no longer one. W10 can show you dialogs from the windows 3.1 style up to a WPA, and you'll likely encounter a mixture all the time because there's no consistency.

I sometimes watch retro hw channels and looking at windows from 3 to 2k reminds me the stark difference.

Office is using web technologies because they don't want to rewrite their code for Office 365, so native users get the Web stuff on a Web widget instead of a proper native UI.

Which is kind of tragic, given how Office was the testing ground for many Windows UI components.

What are you even talking about the only non native app in the office package is teams…

????? Nobody is saying that there aren’t webviews in office I am saying that your statement that most of the desktop office ui is now non native is false and misleading. After reading your other comments in the thread it seems like more of a personal vendetta than factual statements. lmao

Nope, you're the one interpreting that way, I only mentioned that they are adopting Web stuff as means to reduce code duplication between Web and desktop, via Webviews exactly.

So unless you're on the Office team and want to tell us anything, please do lmao.


My dear I am quite free, unfortunely many people on this planet cannot enjoy the same freedom.


Where I come from we don't give tips at the coffee table, the servants earn a proper salary.

Haha you really are a fucking retard. Just remember overconfidence is a slow and insidious killer.

I am quite aware of the fragility of human life.

Dude you really are the prototype of a German honk. Love it.

Personal attacks will get you banned here and ethnic/national/racial attacks will also get you banned here, therefore please don't post like this to HN.


Edit: actually, since you've been repeatedly breaking the site guidelines quite badly (e.g. https://news.ycombinator.com/item?id=33007427, https://news.ycombinator.com/item?id=33006693) I've banned this account. Please don't create accounts to break HN's rules with.

Who cares if it just works? Who cars if it's made in Flash or in COBOL when it just works? What's sad about this? It just works right?

That's the problem: it does not work. I don't care if the programm is written in assembly or in rust as long as it functions properly. But when the blinking cursor stops blinking, when the scrollbar or window border is so thin that i cannot select it with a mouse, when the title bar is so cluttered with buttons that any click brings up a menu instead of being able to double click or click and hold, then _it matters_.

I stop here in order to not throw profanity at MS engineers.

This is evidenced by the layers of settings UIs in modern windows from old school systems properties dialog to newfangled display settings, and in between. It is horrible. They just bundle these UIs atop one another there is no overall usability oversight.

> Even Office and Visual Studio (not Code) are using web technologies to render substantial parts of the UI.

Any more details on what web technologies are being used in Visual Studio and what parts of the UI are done with web?

The Diagnostic Tools window is implemented as a web view, probably since its introduction in… VS2017?. I’m not aware of any other GUI parts implemented using web technologies.

Node.js processes are invisible backend stuff.

This is what I was thinking of. Kind of a telling statement of Microsoft’s perception of WPF when they turn to WebView2 to render newer parts of the UI in their WPF app (which was never ported to WinRT, UWP, or WinUI). They didn’t even use XAML islands for the newer parts, they just jumped straight to web.

You just have to peek into what is running as child process from VS, as node.exe instances.

Mostly related to Web stuff, Blazor or VSCode plugins that they are "porting" into VS.

> The problem: the web has a terrible UI toolkit for desktop apps. It has clickable links and basic forms, that's all

I think you're not giving credit to the best part about the web: CSS.

I've been programming GUIs with Java AWT, Swing, and Qt for years. Nothing comes close to CSS when it comes to defining layouts.

I also spent quite some time building desktop and mobile apps (5, maybe 6 years) and also more than 10 years of building web apps and don’t really share this sentiment.

My feeling is exactly opposite. CSS is messy and hacky way to build layouts (the famous “how to center a div”, etc.) while with UI toolkits it tends to be much more straightforward and standardized.

(Edit: fixed a typo)

When is the last time you used CSS? "How to center a div" has not been an issue with CSS for many, many years. Flexbox and now CSS Grid have overwhelming adoption and most layouts can be achieved with a few lines of CSS.

> When is the last time you used CSS? "How to center a div" has not been an issue with CSS for many, many years. Flexbox and now CSS Grid have overwhelming adoption and most layouts can be achieved with a few lines of CSS.

The html-apps-as-a-local-app (like electron-based stuff) became popular prior to "how to centre a div" was answered.

IOW, they became popular in spite of having shitty layouts specifications.

Flexbox predates electron let alone electron being popular.

Firefox is not a good example of good (G)UI. It was at the beginning until they started copying Chrome.

Before flex and grid CSS had most complex, least friendly and (probably) least powerful layout definition system compared to everything I knew. Creating unecessary elements just to trigger primitive CSS mechanisms was commonplace as was having >3 methods to do some primitive layout task (like centering) depending on where that task was needed. Tables were popular so long because you could do 80% of what CSS could do while knowing <10% of what was needed to do layout without them.

After flex and grid it is just most complex and least friendly. You still need to know all the gotchas if you work with legacy projects or with imported components, but at least there are some sane ways to do basic layout tasks.

For me still nothing beats Adobe Flex when it comes to layout. Without much experience I could easily create UI that looked and behaved good without any resizing problems (although as I remember mobile phones were never supported).

Adobe Flex is one of those things that while I really enjoyed it, Adobe just isn't a good steward of projects/products like it. I do wonder what it would be like if some other large tech company either invented, or took it over.

Flex could be used on mobile through Adobe AIR, but it was slow, and felt all kinds of wrong. This was one of the downsides to Flex, too, in my experience.

I don't know I tried to understand CSS many times but never managed to get it: I'm a backend developer nowadays.

Deep understanding of css can take years. But understanding boxmodel, flexbox and grid won't take long and is enough for must use cases.

Swing Layout managers, XAML styles and control templates, QML.

You can use CSS with JavaFX.

What are these common controls?

Looking at this list: https://learn.microsoft.com/en-us/windows/win32/controls/ind...

Animation -> video tag

Button -> button tag

Combobox -> select tag

Date picker -> input type=date

Time picker -> input type=time

Edit -> input type=text or textarea

Scroll bar -> Not needed, automatic

Hot Key -> WAT?

IP Address Control -> Is this really so common it needs a custom box? does it handle IPV6?

List Box -> Not sure but making a list you can scroll through is trivial in HTML. you set a height of the container and mark it as overflow: auto. Done.

Pager -> seems irrelevant on a browser

Progress Bar -> progress tag

Property Sheet -> N/A

Rich Edit -> This was never good on Windows and it's also not good in HTML. In both cases if you want something that actually has a good UX you have to roll your own or find a library

Rebar -> Flexbox/Grid

Static Control -> most of HTML and far more easier to style

SysLink -> anchor tag

Tab -> trivial to implement in HTML but ok, maybe should be standardized?

Task Dialog -> dialog tag

Track Bar -> input type=range

Tree View -> You can do this with nested detail tags. Not sure it's any more work (in fact I suspect less) than a tree view in C++

Up/Down Control -> input type="number"

It seems all there are far more flexible.

I don't really know which apps you're referring to but I feel like most of the windows apps I use are not using those default controls or if they are they've added heavy customization

I'd see the one control missing most is menus

It means that you've never really developed an actual app. And that you haven't ever thought about all the controls and layouts (with their complex interactions) even in the apps you use daily.

No. Menu isn't "the one control". Menu is one of multitude of controls. Go ahead and try and implement a treeview correctly with nested details (including all the necessary keyboard interactions). Meanwhile treeviews have been a part of native UI kits since... the 80s perhaps?

Oh, and since listviews are so "easy" in HTML, can I finally properly animate adding elements to one or removing elements? With height:auto? And without needing to redraw and re-layout the entire page? Right...

Dialog tag? Does it keep keyboard focus inside the dialog, or do you have to write non-trivial amounts of JS to have this required accessibility feature?

And so on and so forth.

And those are just the most trivial things native UIs solved half a century ago.

> And those are just the most trivial things native UIs solved half a century ago.

My favourite: A window with 1 (only one) input field which is not focused by default. Why ? Why do i have to click and type instead of only typing ?

>List Box -> Not sure but making a list you can scroll through is trivial in HTML. you set a height of the container and mark it as overflow: auto. Done.

As long as your list doesn't contain elements that are too complex, or has too many elements. Otherwise, you enter the world of lists with recycled items, and while Win32 and pretty much every other toolkit has it by default, and oh boy does the web suck at that.

Recently I needed to work with low-level Windows API and default controls. The experience was horrible.

Windows GUI API after 30 years still does not provide any kind of a layout manager forcing to position everything manually on size changes.

A trivial-sounding task like background image beneath controls required days of tries and many lines of code that looked like Voodoo practice than any rational programming.

Then the code uses a custom title-bar that was necessary to update to support Windows 11 snap layout menu. It turned out in the initial release of Windows 11 it was impossible to get that and rounded corners around the application window. Windows relied on undocumented heuristics to infer the desired behavior and if their guess was wrong, one is out of luck. At least Microsoft added API to fix that in a later Windows 11 update.

So it is not surprising that many applications just gave up on that and use WebUI. At least that works much more reliably and in the worst case one can look at the source code.

I think you're not being very fair when it comes to web apps; I think they're a much lower barrier to entry in these days than native applications, especially if you want to target developers who will demand Windows, MacOS and Linux apps from day 0. There are no good cross-platform alternatives out there, with as big a pool of developers or as big an ecosystem.

I mean webapps suck, cross-platform mobile apps suck, and native apps on both desktop and mobile are vastly superior and I will die on that hill. But I understand the tradeoff.

> I think they're a much lower barrier to entry in these days than native applications, especially if you want to target developers who will demand Windows, MacOS and Linux apps from day 0.

Let's be honest, we had multiplatform apps well before desktop-web apps. We are in this situation because GAFAMs pushed very hard the paradigm of always connected web applications (because they had no control over applications running solely on your computer). And since they won this ideological battle, there is not any more investment on multiplatform toolkits.

I really think that all of this is due to political reasons and it have never been about the superiority of the web technologies.

HTML+CSS started as basically a desktop publishing technology, but that's not the case anymore. There's fantastic support nowadays for building app experiences, from the perspective of layout and interactivity. Fair point on system-wide customization, although I really don't miss it. Maybe it's the experience of the web, but it no longer seems weird to me that apps have different design paradigms. But realistically, desktop hasn't had unified design since Java applications started becoming popular 20 years ago.

> There's fantastic support nowadays for building app experiences, from the perspective of layout and interactivity.

As long as you, you know, do no complex layouts or interactivity.

It's still a system for displaying static text documents, and no amount of lipstick can change that without re-doing the entire thing.

If you think it's not the case, animate adding a height:auto element to a list without the browser needing to re-layout and redraw the entire page

I actually wish programs do not put content in the Title bar area. The title bar area is meant for users to move the Window around.

Try opening Microsoft Word, make the window narrow and drag the window. You have to hunt for a small bit of empty space in the title bar or you have to understand you could drag on the Title text, Search box and the Sign in Username, but not the Auto Save text, Upcoming Features icon, or the Ribbon Display Options icon.

I much prefer what a lot of Linux desktop environments support, which is holding down alt and clicking anywhere on a window to move it. With that + a keyboard shortcut for closing a window you can get rid of title bars on apps entirely if you want. Sadly Windows doesn't support it natively, although there's another comment on this thread talking about ways to make it work.

I love this feature and it's since become indispensable to me. I find it pretty funny that my #1 favorite desktop UI feature is from Linux. One of the first things I'll put on a fresh install of Windows or MacOS is a utility that re-creates this behavior.

I use AltDrag on Windows (requires a quick tweak for HiDPI): https://stefansundin.github.io/altdrag/

And Easy Move + Resize on MacOS: https://github.com/dmarcotte/easy-move-resize


That's awesome, I remember when I was a CS student in college I also fell in love with the alt+drag of windows on Linux and I wanted to bring the same on my Windows PC so I wrote this extremely hacky and very unstable tool: https://github.com/Morgawr/EmptyWM

It was one of my first "open source" projects and a great learning experience, I would never recommend anyone to use it because it was full of bugs (also I haven't touched it in like 10+ years) but I used it every day and it was such a great feeling just being able to improve my own life with tools I created myself. :)

This behavior is natively supported on macOS, although it is turned off by default. Click and drag anywhere on a window while holding CTRL+CMD

> defaults write -g NSWindowShouldDragOnGesture -bool true

> reboot

I'm hoping that Microsoft just implements it natively eventually - their window snapping/tiling-lite functionality has been steadily getting better so they clearly have people working on this kind of window UX QOL stuff.

There's a Microsoft utility calls powertoys that makes the window snapping/tiling even better with it's Fancy Zones feature. Also has a color picker which someone in this thread was decrying the lack of on windows.


> window snapping/tiling

Put me in the camp that hates window snap/tiling.

I have a certain workflow that needs this window there, and this one here ... don't snap to a location or go full screen.

Check out FancyZones in Microsoft PowerToys.

On the flip side, I have become so used to AltDrag behavior on windows, that now I consider KDE alt-drag subpar because it lacks the right-button drag to resize.

These little tidbits are the reason I love Hacker News. Thank you for sharing!

In Firefox holding down alt lets you select text in links without navigating to the link target. How do you do that without moving the window?

I didn't know you could do that. I always start dragging from outside the link. Moving windows is a better use of the key for me.

For this very reason (alt-click in applications), I have the window move modifier set to Meta instead of Alt.

Me too. Don't forget about right-click + key to resize the window. I have to use a mac for work and so use Easy Move+Resize to get this same functionality.

alt + right click to resize! how did I never discover this one, thanks

Wow, TIL.

This is such a great little nugget. Thanks.

Desktop windows should be able to have tabs sticking out of them (independent of whatever window title bar they may or may not have, but possibly showing the title or document name or message), along ANY edge, that you can drag around to the desired edge and position, that help you arrange the windows in piles and rows and columns.

Restricting tabs to the top edge of the window is stupid, because text is much wider than it is tall, so you can fit a lot more labeled tabs in a vertical column along the left or right edge of the window, than in a horizontal row along the top or bottom edge of the window. The tabs you get along the top edge of Chrome are useless when you have a lot of tabs opened, because all you can see are the icons, and none of the labels are visible.

That way the tabs are all visible even when the window isn't, and they afford a very easy way to see all the window titles at once, bring the window to the front, drag it around, and pop up pie menus to do things like push it to the back or front (down/up gestures), iconify it, make it full screen, and other window management commands.




>HyperTIES browser and Gosling Emacs authoring tool with pie menus on the NeWS window system (1988)

>HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab. This screen snapshot shows the HyperTIES authoring tool (built with UniPress's Gosling Emacs text editor, written in MockLisp) and browser (built with the NeWS window system, written in PostScript, C and Forth). The tabbed windows and pie menu reusable components were developed by Don Hopkins, who also developed the NeWS Emacs (NeMACS) and HyperTIES user interfaces. (Sorry about the quality -- this is a scan of an old screen dump printed by a laser printer.)

Tabbed windows in combination with pie menus are the ingredients for a great window manager.


>NeWS Tab Window Demo (1990)

Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0. Developed and demonstrated by Don Hopkins.

Ok as a compromise perhaps developers can show custom content in the title bar for a few seconds after startup. That way, the developer can show that they have mastered control of that area, while the user can still drag the window. Win-win.

Windows has pretty decent keyboard shortcuts for manipulating windows‘ positions, though. Clicking and manual window manipulation should very rarely be necessary, shouldn’t it?

Resizing a window with the keyboard shortcuts, especially on a high resolution monitor is time consuming.

I also dislike how apps are now disabling the classic win32 app icon in the top left corner. If you click on it, you get a menu with window management options and double clicking it closes the window. It’s so burned into my muscle memory as the way to close a window I get frustrated when apps hide it.

About 15 years ago, I remember being aghast at Skype hijacking the X in the top-right, minimizing itself to the taskbar instead of either exiting or minimizing to the system tray. Because there was a clear standard action that was intended by that interaction, and Skype had gone out of its way to override that standard action.

Wait till you find out how Windows has hijacked "Shut down the computer"...

I won't say I'm not annoyed at it. When I want to switch back to the Linux partition and Windows instead decides to spend half an hour installing updates, it becomes another reason not to switch to Windows the next time.

I think GP is talking about how "Shutdown the computer" does not, in fact, shutdown the computer (it puts it in a suspended/hibernated state).

As a fallback, you could always use Alt+Space to open the menu, Ctrl+W to close a window and good ole Alt+F4 to close the app

I've seen alt+f4 not have the desired effect (minimising the app or sending it to the tray instead).

Oh god, I thought I was the only one.

Well, here's an AHK script for those that want to move away from depending on the titlebar drag. Use Alt+Shift+Mouse drag anywhere on ANY window to move it on Windows (puns unintended):


I would paste to gist.github.com but the corporate overlords won't let me

If you already have a script running at startup and all that, you can save this as a standalone file called e.g. winmove.ahk and add the following to your existing script:

    #include C:\path\to\winmove.ahk

I have something similar in my Linux setup, Win+LMB anywhere on a window drags it, Win+RMB resizes. Never used a title bar again, highly recommend if you can get a similar setup.

Thanks. I was using AltDrag, but I found it a bit sluggish.

For moving things around across monitors & snipping them to specific half of desktop I personally use Winkey+[shift]+arrows shortcuts, I recommend you check it out if you haven't already! I honestly don't remember when was the last time I needed a window with custom size. Maybe when placing 2 windows side by side? But even then, the OS recognizes that I want to see 2 windows at the same time and adjust sizes of both windows...

Yeah Microsoft Word is terrible in that aspect. You don't even need to make the window too narrow. https://twitter.com/esesci/status/1414631138379792384

FWIW you can still click+drag on the file name/search bar. Not as intuitive but it's a big target that you can still use.

Same thing with, e.g., firefox on ubuntu. Not only do you have to hunt for free space, but because of visual design (in turn because of vanity and frivolity, IMO) it's not clear where it is until you mouse over it and display its highlighted color. The "close" button barely even changes color on the default theme, so god forbid you single-click it. And tabs can accidentally be dragged, rather than just failing to drag the entire window.

This next part is more of a funny absurd story than a complaint, but I once had a recurring bug where the browser UI was shifted down a hundred or so pixels from the top of the window, replaced by some flat "blank" color. But the interactions were still taking place in their expected areas. So in order to fix that, I had to hunt around with my mouse at the top of the window, look for UI elements to become highlighted in the middle of the window, and then move left or right until I was confident I was over the title bar (which I couldn't know for sure, since it itself doesn't highlight).

> The title bar area is meant for users to move the Window around

i thought that's what alt-drag was for? maybe microsoft didn't get that memo either...

The most basic of window operations shouldn't require a hotkey.

Rearranging windows on MacOS and Windows now requires video game precision aiming. It is absurd.

What's more, every app places things in different parts of the title bar, so I have to search for "where to click" based on which app window is up. Absurd.

The move to controls in the title bar is absurd. It used to be Windows had standard chrome, title bar, then menu, toolbar, then content area. Now days it is the wild west what UI elements are where.

The most basic of window operations wants to be bound to a hotkey because it's a basic window operation and there should be easy and quick access to it. Linux does this by default and I find it's an indispensable feature.

To get it on Windows search for AltDrag.

The most basic of window operations should have a visual affordance right in the UI because they're basic and no one should have to pause and ask themself "how do I move/resize a window?"

Remember your Bruce Tognazzini. Shortcuts are just that: shortcuts. They are NOT your primary interface. Everything should be visible and usable with just the mouse.

I don't disagree.

It's for this kind of nonsense that I have "alt-space -> s -> down -> right" burned into my fingertips followed by moving the mouse cursor to resize a window deterministically (along with "alt-space -> m -> any arrow" for move, doubly useful to "rescue" an off screen window)

> alt-space -> s -> down -> right

> alt-space -> m -> any arrow

Are those keybindings default on a particular OS/DE/WM/WC or are they just your personal config?

Default behavior for Windows applications (since 3.x, I think). Alt-Space brings up the Window menu.

Some odd-ball apps will replace it with their own menu, but few apps go to the effort to override the default shortcut it, even if they otherwise hide it.

Works on windows for me. Also never really thought about this for rescuing a stuck window, I've always used winkey + arrow keys and kept mashing buttons until it appears on one of my monitors :P

Alt-space menu is Windows specific IIRC.

It makes sense since Motif was based on OS/2 Presentation Manager which was also the basis for Windows 3.1's look.

Gnome does the same, I use it all the time for "pin window always on top"

Which windows still doesn't have, for some reason.

Gnome doesn't have menu accelerators in the window menu though, so "alt-spc n" does nothing: the alt-spc brings up the window menu, but the n doesn't activate "minimize". This interaction not functioning in Gnome keeps me off Gnome entirely.

super+h minimises. pretty sure you can make it anything you want.

if you're looking specifically for "alt-spc n" to minimise I'm sure you can find a way to make that work - but why? to retain muscle memory between windows and gnome?

My keyboard doesn't have a 'super' key. What does that translate to on a normal keyboard?

Windows key, but like I said you can change it to anything you want.

I'm pretty sure there's an option to emulate the windows key somewhere too

I think openbox uses it as well.

Random sorta related complain: at work when I'm using two different-sized screens, sometime when doing a click and drag to move a fullscreen window from one screen to the other, it's not the top one that's going to get dragged, but instead one 'below' it. Really annoying

I've only ever gotten this on my Macbook

Hard disagree. Vertical space is a scarce resource and I hate when it's used for dead space I can't get rid of or use productively. Alt-drag is the way to go.

That's ridiculous. 640x480 used to be the norm for Windows, and now monitors with 4.5x that vertical resolution are common.

Instead you should be complaining about the trend of apps spacing everything out with excessive amounts of padding.

Vertical space should not be scarce. 16:9 or worse display is the root issue. Framework has a 3:2 and it is lovely though a bit glossy for my taste. Portrait external is another option.

Both on my main machine at home and in the office, I have a 32" 2560*1440 screen and a 24ish 1080p (they work out more it is the same pixel pitch) beside it, which I often effectively use as three portrait screens, sometimes using FancyZones so that the divide on the 32 isn't right in the middle. The setup is a bit tall when sat thought, potentially causing neck strain, but I tend to use the standing desk in up position so that isn't an issue. Tall screens are much nicer than landscape IMO.

The Windows style for bars (both title and status) is way too large. Ditto for the task bar.

It's no wonder people are tempted to not use status bars, and shove as much as possible at the title. If applications could exploit the task bar, they would too.

(Anyway, you don't need an entire bar for system interaction. But applications aren't designed in a way that allows this.)

The older I get, the more I respect bigger user interface elements and text.

It's not even failing eyesight either; I'm still in my mid 30s and have great eyesight and dexterity. I've come to respect bigger interface elements because they are quicker to work with.

I don't have to peck for a title bar if it's there, big and empty in front of me. I don't have to hunt for a scroll bar that hides itself and reveals a 1px wide sliver if I hover over it just right, if the scroll bar is big and always visible. I don't have to aim my mouse like I'm playing a fucking sniper in a fucking FPS if the buttons are clearly texted, colored, bordered, and large.

Being able to /just fucking use the interface/ with broad motions is a fucking godsend. The trend of minimalism, hide-everything, gray-on-white interfaces gets in my way and wastes my time and nerves.


Unfortunately, the designers all seem to have 72" 8K professionally color-calibrated monitors and a $1000 mouse, and think if it works for them that's good enough.

I saw the start of this in the mid-2000s when the web trend was for grey-on-grey 8px fonts. I went to the designer and asked what the heck he was thinking and he showed me his screen; and yeah it was kinda legible there. Still bad design.

Nowadays the trends are flat UI where you don't even know what's clickable/actionable, hidden things that only appear when you mouseover them, and on touchscreens, secret functions that only trigger if you swipe in just the right way with just the right number of fingers in just the right pattern.

Design has just been getting progressively worse and worse ever since 2000/Windows XP.

> Unfortunately, the designers all seem to have 72" 8K professionally color-calibrated monitors and a $1000 mouse, and think if it works for them that's good enough.

Years ago I came across a project developing software for use by soldiers (maps, messaging, that sort of thing). The devs made really tiny icons for the various map symbols. One day an actual soldier came in with a ruggedised terminal and asked the devs to demo the software on it, using combat gloves. Needless to say it was unusable and there was a great gnashing of teeth.

The same project also gave rise to the best bit of user feedback I've ever seen. At an exercise where the software was being trialled, the commanding officer asked one of the soldiers what he thought of the software. He replied (in a northern English accent) "The fucking thing is fucking fucked, sir", and the trial was cancelled about ten minutes later.

The larger the elements that you don't use all the time, the smaller all the other ones have to be.

If you have large high resolution screens, you won't miss the space, but you can't blame people for optimizing their own applications for the screens most people use.

You're telling me I can't afford an 8 pixel wide scroll bar on a fucking 1920 pixels wide monitor?

Meanwhile nearly every article nowadays has a useless header image that takes up the entire screen, pushing the content out of view until scrolled down.

Give me nice and thick title bars and window borders, give me wide scroll bars, give me ginormous buttons with proper borders and textual descriptors. Minimalism is nonsense if critical contextual information is denied.

I am telling you people don't need 80 pixels of vertical space spent on title and application switcher, and can use those better with actual content.

But if you want to put words on my mouth, go ahead.

I do, because big and easy-to-handle title bars and taskbars make for easier and quicker usage of the interface.

I also have 15 layers of tabs in one of my Pale Moon windows, but that's beside the point.

> If you have large high resolution screens, you won't miss the space, but you can't blame people for optimizing their own applications for the screens most people use.

Have you seen the new Microsoft calculator ? (i.e. calc.exe). It seems to be designed to be operated by spear throwers from 100 foots away.

It's not, or at least it wasn't prior to ~Win8 or so. Yet monitor resolutions have steadily increased, so perhaps it's a reasonable on with a huge monitor.

Anyway, you don't need an entire bar for system interaction

Having to click on a tiny area to move a window, instead of a relatively wide rectangle, is a huge regression.

> If applications could exploit the task bar, they would too.

Winamp did exactly that, on Windows 95. The capability is there.

Pretty sure it's even bigger on Windows 11, same with the taskbar. Gnome 3 has the same issue.

Used to be able to specifically set the size of the title bar in Windows 9X and NT 4-XP or so.

Looks like the perfect place to fake some browser chrome and trick people...


I think you'll only get access to this API if the user has explicitly installed your app as a PWA, not just when visiting it as a webpage.

And then a shady company offers to buy the owner's website...

That’s a real problem, of course, but it seems fairly equivalent to any native app you install that can update itself or otherwise make a network request to obtain instructions.

Native apps that autoselfupdate have RCE vulnerabilities by definition and should be considered remote access malware already, before the developer release keys are compromised.

I am the reason Signal desktop now has a preference to opt out of autoupdate.

"It won't happen to me."

I agree with you. On the other hand, in the case of a native application, we can hope that the antivirus removes it. I hope that Microsoft has planned to update Defender accordingly.

Unlike the native app you probably won't have to worry about web page encrypted your files and asking a ransom.

For now

JavaScript malware has been a thing for a while now, and antiviruses have been targeting it accordingly.

It's not necessarily a JavaScript malware. A pure HTML page with a <form> tag could suffice to steal credentials.

XSS will mean that attackers control browser UI, that's kind of bad

Bad ? I thought that was a feature. "Want to change your browser behaviour ? Just put this CSS in user.js".

That was my first thought as well, but I couldn't remember the name for that boundary. I hope there is a well-designed per-site control/setting/user consent system to keep tech support scam sites (or worse!) from adding one more tool to their arsenal.

I’ve seen it called “The Line of Death”


With all this Electron and PWA focused development a cannot shake a feeling that we add an extra layer of a "runtime" on top of an operating system, that could be avoided. An extra layer which occupies RAM space and processor time which feels unnecessary but it is where we are headed. I wonder if the reason is simple, that we (myself included) have not provided anything better or the reason is that big corporations who control most of the market have pushed this technology forward. I hope we can learn from this and bring back some of this lost performance while keeping the productivity and security gains.

The bottom line is that Electron is portable. Unless native apps become as portable as Electron there will be a need for this layer.

The optimistic scenario is that WASM becomes the single target that everyone settles on, and that the performance penalty is minimized while the security sandbox is strengthened.

I see this all the time, and I honestly do not get it. As someone that has ported a game written in C++ for Windows to Linux... its not that hard. It took me 2 days, about 4 hours of work total, and most of the ports I had to make were because I'm an obstinate developer and didn't use the std lib functions that would handle the OS wrapping for me.

Now, I've never ported an app to mobile, and that may be entirely different. However, and this may be an unpopular opinion, I don't want developers building an app that's meant to be used on a mobile device and a desktop. They're 2 separate ways of using a computer and they should be treated as such.

When I think of desktop apps like Photoshop, Outlook, Word, Chrome, and Da Vinci Resolve, they all look and behave very differently than their mobile counterparts (if they have one). If you want to develop for mobile and desktop, then you need to invest the time to make it a good experience on both. I hate desktop apps that have been mobile-ified to support mobile-first design. Design a proper UI and UX for the platform you're targeting. Otherwise don't bother "supporting" a platform you never test, intend to test, or design specifically for.

> ported a game

Most of the immediate pain with native to native ports is shift between UI frameworks. This always requires a huge investment to do correctly.

Not sure about your specific game, but if you're using an engine or handling widget rendering yourself, you won't feel this pain.

Simply changing your compiler target is easy. This is not what people are complaining about obviously.

> Not sure about your specific game, but if you're using an engine or handling widget rendering yourself, you won't feel this pain.

Out of all the apps that I listed, I don't believe any of them use native desktop widgets/controls/ui frameworks, except the Microsoft products. And even then, the Microsoft products are definitely using customized widgets which means they're writing a lot of custom rendering code anyways.

Edit: I'd also like to add that the original comment said that electron is portable, implying that portability is a tremendous feat. This is what I'm arguing against. Sure if you wrote your entire app in WPF, that's going to be next to impossible to port. But if you want to make a cross platform app, then it's not difficult to use a framework like QT to have a native cross platform app as opposed to embedding an entire browser runtime to get a portable app. This false dichotomy is what I don't get. It's not 2000 anymore, there's no reason portability has to be treated as some boogeyman that can only be solved by shipping extremely bloated software for a native cross platform app.

Also, here's a big list of C++ GUI libraries if QT doesn't float your boat https://www.reddit.com/r/cpp/comments/babfl5/a_pretty_big_li...

Porting a large-scale windows desktop app to linux takes engineer years.

Not with QT and C++.

Java Swing apps were portable across Windows, Mac and Linux desktops waaayy back in 2004 and probably earlier. Write once run everywhere _was_ very much possible back then.

The biggest complaint was they didn't look native. From working on a Swing application back then, management and marketing would often ask if we could make it look more like other Windows applications, because looking like a native Windows XP application suggested it was modern and cutting edge.

As soon an iTunes landed on Windows, the requests for UI improvement changed from "make it look like Windows" to "make it look sexy" - which meant different things to different people.

Electron, to me, feels like an attempt to take a browser engine and turn it into a poor replacement for the JVM.

I worked on Java apps around that timeframe. Despite spending a lot of effort refining our widgets and using some animated transitions (ref the "Filthy Rich Clients" book) the applications generally felt more dated and cheaper-looking than native apps.

For enterprise apps with no strong competitors these minor aesthetic issues didn't impact revenue so those UIs remained in Java. But for everything else it was worth it (financially) to migrate to native.

I sometimes armchair quarterback and wonder whether Java would have been more successful if the Swing folks had focused more on design. It seemed like the most they ever did UI wise was attempt to catch up to platform native widgets so they were perpetually several years out of date and slightly inconsistent. Had they skated to where the puck was going to be rather than where it is perhaps Java applications would be the ones people pointed to when asking devs to "make it look sexy" instead of iTunes.

Yep, we did some deep customisation of a couple of key UI widgets and found it very time consuming. Changing the Look and Feel to Nimbus was a major improvement, but that came with semi-regular breakages when performing minor version JVM updates. I vaguely remember us overriding a couple of Nimbus defaults but finding that could have unexpected consequences elsewhere in the UI (ie LaFs are complex), so we didn't go down that path much.

While Swing styling support wasn't that great, I miss the flexibility of nesting layout managers for composing complex, resizable UIs.

When Java FX was first announced, I started learning it to see how we might use it for our applications. At the time it lacked a lot of widgets we needed, but it had much better support for styling. Sadly I didn't keep up with Java FX. While I have no direct need for it in my current job, I still get the itch to whip up the occasional desktop app, so I plan on getting back up to speed soon.

This feature itself has nothing to do with Electron. Electron has long had similar capabilities.

> The optimistic scenario is that WASM becomes the single target that everyone settles on

oh hell no. I reject this in the strongest possible terms. You don't need a web browser to create a program. This is pure laziness. I am a developer. Browser based app is fine for small stuff. But nothing as large as Visual Studio Code, should ever be created as a browser app. This is just an awful idea because it results in dogshit performance, an order of magnitude worse than native solutions.


I encountered hell the other day. I saw a corporate Citrix deployment that had 45 users running three electron apps on an underprovisioned server with the CPU, disk and memory rammed at 100% lagging out. That’s 135 separate browser stacks basically.

Microsoft are moving office to this stack as well. Ugh.

Of course I was there trying to work out why our simple old fashioned web app was running slowly in a chrome tab…

Our hospital system uses Citrix and the application patients have to sign in with runs on some web framework instead of being a native Windows app. Such a frustrating experience using the on-screen keyboard to enter your name to sign in.

It makes perfect sense for the user but developers will always argue for Electron so that they only have to test one browser engine.

I can’t even gets web devs to test on anything but Chrome and when something they code does break I have to listen to the Safari whine even though they all use iPhones so are part of the reason it’s relevant. Dread to think how an argument for supporting 3+ web engines for a “native” app would go.

A lot of developers are not fans of Electron. Generally, it's a quality vs quantity tradeoff. Are you willing to make a crappier thing if it means more people can use it?

For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user.

> For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user.

Back when I worked at Microsoft, 2014 or so, we had serious problems finding Win32 developers. We essentially had to train people up. While I am sure the Windows org had lots of them, put out a job req and even internally not very many people are going to have native Windows development on their resume.

Nearly had to draw straws to see who had to get "stuck" learning Windows stuff.

I imagine native MacOS developers are similarly rare as a % of the overall developer pool.

Android and iPhone developers, easy peasy.

Likewise, Web developers, not a problem.

The other thing is, Electron has tons of momentum behind it, which means more and more people jump onboard to learn it, which makes hiring easy. Tutorials and learning resources get made, making developing for it even easier.

IIRC we ended up dropping the native C++ Windows app and just used C# and one of the UI toolkits, I forget which one.

> Back when I worked at Microsoft, 2014 or so, we had serious problems finding Win32 developers. We essentially had to train people up.

Microsoft only has itself to blame for this. They charge an arm and a leg for their dev environment setting it up is a pain no matter what, the stuff you get “free” when you pay for the dev environment is not nearly enough to create anything worthwhile. So why should any CS department bother with win32 circa 2005. As much as Balmer liked to chant about the importance of developers he sure liked to milk them dry.

For decades MS had the best development environments, best training, and best documentation.

MS fucked it up with the wpf->silver light->winrt transitions.

Win32 is a horrible API but it was stable and there was a time Win32 developers were everywhere.

Visual Studio is still one of the best real IDEs out there. The tooling for modern languages is a sad joke compared to what we had in 2005. And modern documentation is so bad it is absurd. People don't realize how much $$$ MS used to spend on sample code (MSDN samples were large fleshed out sample products!) and on documentation teams.

Comparison point, last time I tried to use Google cloud, I had to use the way back machine to look at an old version of the docs because the embedded sample code had gotten broken during an update 2 years prior and no one ever fixed it.

You forgot another two major fuck ups, killing .NET Native and C++/CX, without a proper migration path to a GUI framewokr that is anyway WIP and will take a couple of years to even reach some kind of parity with WPF.

I still mostly use Microsoft technologies, but that was a big middle finger to everyone that was willing to go through all WinRT rewrites since Windows 8, advocating for the technology.

It may be more the myriad of technologies and the fact that they change them out almost as often as their underwear. Same problem we have with javascript frameworks.

What is it that we need 10 years experience in this week? Win32, OCX, DCOM, CORBA, OWL, ActiveX, WinForms, WPF, ASP, SliverLight, .Net, XNA (etc. etc.)?

Kind of amusing that so many people turned to web tech to escape that treadmill and then just totally recreated it in javascript.


I didn't even know these existed.

>> I imagine native MacOS developers are similarly rare as a % of the overall developer pool

Which is a shame, because as bad as Xcode is, developing native apps on the Mac is almost pleasurable compared to Windows or Linux

When WinDev keeps pushing for stuff like COM, with tooling that already felt primitive when Visual C++ 6.0 was around, it is no wonder that they have such hard times.

Eventually even those of us that know Win32 quite well don't want to deal with it.

What seems even crazier is not even wanting to test against different builds of Chromium to help keep pace with Electron updates. At that point isn't one's code just too brittle?

> Dread to think how an argument for supporting 3+ web engines for a “native” app would go.

Well, on mobile, it's slightly different. If you use Capacitor, it uses the OS' native WebView, which is either Chrome (Android) or Safari (iOS). You gotta test for two web engines, but fortunately, they're relatively close.

I think a solution like this for desktop would make sense. Modern browser engines don't have that many differences and it would make the runtime a lot smaller (thin wrapper around the already installed browser engine).

Sure, it has its downsides, but mobile apps have been written like that forever (via PhoneGap before and now Capacitor) and have come a long way since.

>but fortunately, they're relatively close.

I mean I wish I worked with people with that opinion but somehow the 60+ devs I've worked with over the past 5 years manage to code things that work in Chrome but with many parts broken in Safari and an attitude that it's Safari's fault.

I have little patience for this attitude because the period of time I worked as a dev I had to support IE5.5, IE6, IE7, Safari, Firefox and Chrome. But it is the prevailing attitude.

The obvious solution to this is to remove the bottom layer so that the browser is not a layer on top of the OS, but is the OS.

That won't meaningfully change performance at all. Browsers aren't slow because they have to make slow syscalls - they mostly don't. They are slow because web technologies themselves are slow, sometimes by design, sometimes because of security/abuse concerns, but often just because HTML & CSS are absolutely crap platform for interactive UIs, something they were never intended to be and retrofitting that doesn't result in a very efficiency stack.

> HTML & CSS are absolutely crap platform for interactive UIs

I mostly disagree. HTML is great for plain forms, that seamlessly work at different form-factors (from mobile to desktop) with very little work. Browsers are also good at graphical outputs.

Browsers can fall down when you need rich, complex, or custom inputs: because virtual keyboards are very different from real keyboards (iOS especially poor), and touch is very different from mouse, and game consoles are something else again!

But we go where the users are, which is usually a wide variety of devices which makes browser based deployment the default choice, so you work within the limitations of browsers.

> HTML is great for plain forms

I'm not sure I'd call that an "interactive UI" though as that's pretty much a static layout. Which yes HTML is fine at handling.

> Browsers are also good at graphical outputs.

They're okay graphical outputs, not good ones. The feature sets are good, but the performance is all over the place and pretty much always sub-par as they are very defensive against content. Meaning the difference between the fast path (so plain scrolling) and the "slow" path (nearly anything else) is absolutely massive. Even things that are all but free on native toolkits, like just animating a color, can tank browser performance.

> But we go where the users are

Of course, which is mobile apps ;)

No but the point is just browsers aren't slow because they are an OS inside an OS. The layering isn't the cause of really any problems other than the binary size of the browser itself.

TUI data entry is great for forms. Html allows too much leverage to confuse the user.

I have seen this attitude on HN before, and it really confuses me.

You know what an OS is, right? You can't just say, "the browser window is the only window" and say that "is" the OS. At some point some native code is going to need to send bits back and forth between hardware. You will need to provide a filesystem, you will need to provide device drivers, you will need to provide a windowing system, etc etc.

By the time you get from NAND to usable browser, you will have build an OS. Sure, I guess you could throw in a JS runtime and insist all user level software is in node/HTML/CSS, but there is still an OS underneath all that! (And the OS isn't why it's slow anyway.) There is so, so much more to computers than running JS and rendering HTML and CSS.

Hypervisor based os is future ,for eg qubes os

TBH, it doesn't matter how many levels of abstraction you have when the programs are crap.

better yet we should just outlaw personal computers and laptops, they are causing too much trouble. Better for everyone to just have iPads and iPhones, kill Android too.

Well , to not shoot yourself in the foot, port first the development environmets to those platforms. /s

I choose it for portability. I can ship to my users today, work on new features for all users, or I can spend 3-4-5-6 months dealing with differences in platforms, differences in tooling, build environments, deployment, etc....

I also it choose is because as a programmer it's far easier IMO to make a web tech app look good than a native app. CSS, Unicode text, emoji, images, video, canvas, webgl, it's all easy, portable, and batteries included, vs the various platform specific ways of providing those features.

I'm gradually starting to see X11/Xlib as a solution for cross platform desktop apps. It is the native GUI API for most UNIX operating systems. Ports exist for Windows(win11) and Mac which makes X11 technically portable to them as well.

Its not exactly an elegant solution I have to admit. But the licensing problems with QT make a lot of people nervous, GTK seems to be pretty polarizing, and for whatever reason WxWidgets and FLTK never really got much adoption/didn't progress very far.

[0] https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-...

I think wxWidgets was pretty big in the 2000's, with quite some programs using it. To name one example, the Code::Blocks IDE uses it.

FLTK has never seen adoption even to the level of wxWidgets I think, but to be honest it is also quite simply hideous. I have not found a proper looking theme for it either, since I was mildly interested in using it to add a simple GUI to a Rust tool.

I don't know why WxWidgets seems to be less popular now than it was back then. I remember it being somewhat popular. Now people hardly seem to know about it.

FLTK looks horrible next to most modern applications. But FLTK 2.0, which has been abandoned for 10 years, actually looks pretty modern and the API is actually pretty elegant. There was some kind of split in the community about FLTK 2.0 breaking backward compatibility and I guess the 1.0 people won in the end.

They saw it's good so are now deprecating it.

When you see decades of Windows version after Windows version, each billing itself as "the fastest Windows ever!" and each having higher minimum system requirements than its predecessor, two conclusions are inescapable:

1. The Redmond wizards have devised a method to make software run faster and all it requires is faster hardware.

2. Microsoft is in bed with hardware manufacturers.

What are you talking about?

I'm running Windows 10 on a 2009 computer - one which was low-mid end back then. Only upgrade is an SSD.

The system requirements are something they put out on paper, parent isn't necessarily saying you need a better PC, just saying Microsoft themselves say that, which you can verify yourself.

Modern Windows PCs feel very noticeably snappier and more responsive than older ones. For all my complaints about Windows, that certainly isn't one. I've had to go back and work on old XP boxes, and that is not a pleasant experience.

Admittedly a good chunk of that is SSDs, and better hardware plays a role. But hardware was going to get better anyways regardless of Windows - at least they didn't use the better hardware to make the effects fancier/get sloppy and end up at square 1 like so much of other software.

> Modern Windows PCs feel very noticeably snappier and more responsive than older ones

If you run the same version of windows on both PCs, yes.

> With all this ... PWA focused development a cannot shake a feeling that we add an extra layer of a "runtime" on top of an operating system...

Is this not ChromeOS? A little OS, a lot of browser and little else?

Do you think Microsoft loves it that people are building Windows apps with Google tech?

But this ship has sailed a long time ago.

I think they do love it! I'm pretty sure they chose Chromium for Edge because they see Electron or something like it as the future.

That ship seems to have sailed with the (over?)use of VMs a long time ago.

Love how we're realizing that .hta was actually incredible. I have fond memories of building my own https://en.m.wikipedia.org/wiki/HTML_Application

Quick shout out to the Compiled HTML[0] (.chm) format for similar but unrelated reasons. The Help viewer application was one of the pinnacles of good UX, in my opinion.

[0]: https://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help

A while back at $DAYJOB I tried to get a CI pipeline to bundle our docs as .chm, but the official tooling (hhc, with-or-without Sphinx as a frontend) is windows-only pre-unicode nonsense; the only Linux native chm compiler i found was Halibut (from the author of PuTTY) which has many of its own idiosyncrasies.

Is there any normal-looking way to make a chm from a directory full of html files?

I haven't made one in ages, but I have heard Calibre might be able to process CHM and possibly even generate it (cannot confirm).

The only working bookmark I have now that standalone MSDN is basically defunct (RIP, legend) is:


(might wanna archive before MS redirects it to welcome.microsoft.com or something)

Not sure if that helps but it's all I got!

.hta really had to go through the standardization process to tighten up security. Those things were awesome, but you'd basically be owned immediately.

It's kind of impressive that one can still run the same .hta app even on Windows 11 according to the wikipedia article:

> HTAs are dependent on the Trident (MSHTML) browser engine, used by Internet Explorer, but are not dependent on the Internet Explorer application itself. If a user removes Internet Explorer from Windows, via the Control Panel, the MSHTML engine remains and HTAs continue to work. HTAs continue to work in Windows 11 as well.

I am reminded very strongly of the line of death:


Now, don't get me wrong, I love the idea of progressive web apps, but the web is also easily the very least secure thing I do with my computer on a regular basis. The last thing I want is yet another way for a web page to pretend to look like a native app. Even with my decades of experience, I am liable to be fooled in a hasty, tired moment, and I suspect I'm not alone.

In other ways, web environment is the most secure part of your OS. Download and install an .exe and it's essentially completely unsandboxed and has free reign over your computer. These 'PWAs' are much more limited and scoped.

That's the first article that came to mind when I read the article: this is going to be a godsend to phishers. Granting random sites the ability to render a counterfeit toolbar, including an address-bar with the green padlock that reads "https://bank.com" or "https://sso.internal.corp.com" will be a security nightmare

Worth noting that this feature is limited to installed PWAs, so you'd either have to convince the user to install a PWA via the URL bar affordance (which already requires real HTTPS and respects the LOD), or to manually install a site-as-app through the browser's (relatively buried) UI, at which point you get the same site you're already on, but with a new titlebar. That seems like a pretty unrealistic vector and is much less complex then just getting users to install an .exe.

That said, even with the Window Controls Overlay, the minimal browser controls (close/restore/minimize) are mandatory, as is the browser-owned "..." menu which includes basic trust information for the site as well as app controls (uninstall, permissions, etc.).

> so you'd either have to convince the user to install a PWA via the URL bar affordance (which already requires real HTTPS and respects the LOD),

Getting a valid SSL certificate for getFakeSaas.com is free, and respecting LoD has no effect at this time. Once the PWA is installed, there is no LOD, amd my PWA can phish any domain I desire with faked affordances.

Separately from the issue of titlebars, I want Chrome's PWAs to open external links in my default browser (Firefox), not a new Chrome window.

Sadly I can't make Firefox install web apps as system icons because they removed experimental Firefox SSB support (they said to reduce maintenance overhead). Interestingly I found https://addons.mozilla.org/en-US/firefox/addon/pwas-for-fire... but have not tried it yet.

Yeah I hope Firefox could support desktop PWAs. I am moving towards Firefox from Edge due to the Manifest v3, but I cannot leave Edge due to its better PWA support, which my daily driver code-server relies on.

As someone who moved from Brave to Firefox recently and also missed PWA support, the first thing I did was install that extension and it's not bad!

A little tedious to setup, especially as the PWAs all get new profiles with their own extensions, themes, etc. But other than that, it works fine.

I think this is a sign that Microsoft sees the writing on the wall. There will be a day when Windows is left behind, and they want to make sure that they can continue to deliver the Microsoft experience, even on other platforms.

I don’t think Windows is ever going to be left behind, you still need a kernel to make use of all your hardware and an OS to give users something to do. I view this move as Microsoft recognizing that the future of most development is cross-platform web technologies and they need to give Windows users reasons not to migrate to macOS and ChromeOS (though it’s ok if they do as long as they’re paying for O365 and Azure).

> I don’t think Windows is ever going to be left behind

I do, but not for reasons most people think about.

The Windows 11 UI/UX is trying to emulate MacOS. Clearly, Microsoft is giving the finger to people that use Windows because it's not MacOS.

I can't wait for Windows 12 to happen and all the UX things I hate about MacOS get implemented in Windows. Might as well start training my muscle memory to hit the Windows key instead of CTRL now, so that when Microsoft decides that CTRL-X/C/V should be WIN-X/C/V, I'll be ready.

Or maybe I'll just switch to Linux.

In either case, I'll leave Windows behind.

Few years back everyone was complaining Apple was copying Microsoft by going all in on flat UIs.

While at MS I did run into the ever present problem of many designers only using MacOS so their designs would basically say "do what MacOS does!"[1] which entailed a lot of work by developers to change the default Windows UI widget behaviors to look like MacOS. Thankfully when I got one of those requests across my desk I was able to point and shout at MS's design language rules and say no. :/

[1] I don't think it was on purpose, I just think many designers have never used anything else and they didn't even realize other UIs exist outside of MacOS and iPhones. These problems started popping up when MS loosened up on their rules about only using MS products for development, it was a needed change but ugh, UX designers and their MacBooks...

I can't stand flat UIs.

Not having buttons be obviously clickable/touchable is a bug, not a feature, as is having UI elements blend in with each other.

I personally use WindowBlinds to make my Windows 10 UI look like Windows 2000. I love having a taskbar that has 3D buttons. I like not having multiple windows from a single program getting grouped together.

Windows 2000 (or Windows XP with the Classic theme enabled) was the best UI Windows ever had. It's been downhill ever since.

I agree, but I’ve always wondered if flat UIs had a performance advantage. Like, if your GPU just rendered a bunch of rectangles of a single color instead of having to mask rounded corners or draw borders around things, could the UI run with less resources? Maybe it’s conspiratorial but it helps me sleep at night as a remember not finding buttons during the day…

Considering we had 3D controls in the Windows 3.1 era when some people were still running on 25 Mhz 80386 CPUs and 4 MB of RAM, I'm not too worried about the performance impact.

> so that when Microsoft decides that CTRL-X/C/V should be WIN-X/C/V, I'll be ready

Already starting to go this route. While you can still ctrl-x/ctrl-v, most of their newer features implement the windows key, including win-v for paste using clipboard history.

While printscreen works, you can use win-s to take a screenshot now too.

Well as long as printscreen key still works, adding another shortcut is fine. And win+s isn't really that bad compared to Mac's ctrl+shift+alt+spacebar+F4+right-click or whatever it is. Mac has the worst, most bizzare 'short'cuts anyone ever come up with.

I think you're right, but that also poses the possibility that Windows will get left behind, as a kernel. If the future of development happens on the web, the significance of Windows as a kernel is going to greatly diminish. We've already reverse-engineered a huge amount of Windows API calls, and you can run vast amounts of fairly complex Windows software without the NT kernel at all.

If our future does shift towards thin-clients and web-browsers, MacOS and Windows will make increasingly less sense. Both OSes have a pretty significant amount of cruft and unjustified overhead which already seems unnecessary to a generation of Google Docs and Soundcloud users.

>"If our future does shift towards thin-clients and web-browsers"

Please no. I like to control what I have. No way for me to be fed by thin client. Sure I do not mind web apps / services where it makes sense (banking for example). But the possibility to be suddenly cut off for whatever reason (maybe my app provider does not like my political views) - fuck that. Or when everything goes through some portal what will prohibit from them jacking up subscription fees sky high? I understand by many developers wanting to use webapp hummer for everything but I think they're digging their own grave

Those problems are also realistically an issue for native apps. The internet is your distribution platform regardless of if the web is your target.

I would hope that the industry could work together to provide a comfortable cross-platform app development experience, but none of the big players bought-in. So now the web is our only option, and they're the ones to blame.

For what it is worth I distribute my products from my company's website. However little reputation I have is all mine. It does not depend on some portal. The revenue is all mine as well. Besides those products are heavy apps that use features not accessible from non native apps.

I don't see how an offline-first browser app is worse then a native app in terms of control.

My answer was in particular to: "If our future does shift towards thin-clients and web-browsers".

Thin client leaves processing to a server. It does not matter in this case if your "offline-first" UI is resident / cached on a client side. These are just glorified web bookmarks

Windows isn't the only kernel and it's not a huge part of Micrsofts revenue

I think this is the wrong take.

Microsoft is trying to land on the PWA beachhead in an attempt to make mobile devices irrelevant and app agnostic.

Furthermore, they want to provide the tooling to develop and deploy into this ecosystem. Github, Github CI, VSCode, Azure, ...

They have been at it for as long as MSHTML exists, in various kinds of packaging.

Check Active Desktop, HTA, WinJS,...

I have to agree with this. Many Win32 things are disappearing, Azure is running on Linux and Microsoft is porting their major Win32 cash cow services to run on Linux as well.

Azure runs on Windows and Hyper-V

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact