Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Closing a 30 pixel gap between native and web

blogs.windows.com

Post reply on HN
Print view View original

281–290 of 313 posts

Re: Closing a 30 pixel gap between native and web

#281

Post by n8cpdx »

fuzzy2 wrote: post #243
mdmglr wrote: post #176

Earlier quoted context omitted.

> 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.

Re: Closing a 30 pixel gap between native and web

#282

Post by sedatk »

mixmastamyk wrote: post #212
sedatk wrote: post #61

Earlier quoted context omitted.

Alt-space menu is Windows specific IIRC.

Motif/CDE, +/- 1990. https://docs.oracle.com/cd/E19683-01/806-4743/6jdq6q20i/inde...

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

Re: Closing a 30 pixel gap between native and web

#283

Post by sangnoir »

kylealden wrote: post #280
sangnoir wrote: post #185

Earlier quoted context omitted.

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…

> 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.

Re: Closing a 30 pixel gap between native and web

#284

Post by VyseofArcadia »

amadeuspagel wrote: post #24
MaXtreeM wrote: post #6

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 w…

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.

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.

Re: Closing a 30 pixel gap between native and web

#285

Post by Night_Thastus »

RunSet wrote: post #68
MaXtreeM wrote: post #6

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 w…

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.

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.

Re: Closing a 30 pixel gap between native and web

#286

Post by dmitriid »

pronlover723 wrote: post #190
GuB-42 wrote: post #86

> 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 rewr…

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…

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.

Re: Closing a 30 pixel gap between native and web

#287

Post by dmitriid »

acjohnson55 wrote: post #267
GuB-42 wrote: post #86

> 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 rewr…

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,…

> 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

Re: Closing a 30 pixel gap between native and web

#288

Post by marcosdumay »

Dalewyn wrote: post #272
marcosdumay wrote: post #271

Earlier quoted context omitted.

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 non…

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.

Re: Closing a 30 pixel gap between native and web

#289

Post by dang »

desindol wrote: post #259
pjmlp wrote: post #256

Earlier quoted context omitted.

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.

https://news.ycombinator.com/newsguidelines.html

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.

Re: Closing a 30 pixel gap between native and web

#290

Post by jimmygrapes »

mappu wrote: post #143
jimmygrapes wrote: post #70

Earlier quoted context omitted.

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:

https://learn.microsoft.com/en-us/previous-versions/windows/...

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

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

Post reply on HN