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

181–190 of 313 posts

Re: Closing a 30 pixel gap between native and web

#181

Post by vxNsr »

Falkon1313 wrote: post #179
vxNsr wrote: post #152

Earlier quoted context omitted.

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

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…

> OCX, DCOM, CORBA, OWL,

I didn't even know these existed.

Re: Closing a 30 pixel gap between native and web

#182

Post by glandium »

MereInterest wrote: post #142
bitwize wrote: post #137

Earlier quoted context omitted.

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

Re: Closing a 30 pixel gap between native and web

#183

Post by szastamasta »

c0mptonFP wrote: post #172
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…

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

Re: Closing a 30 pixel gap between native and web

#184

Post by com2kid »

vxNsr wrote: post #152
com2kid wrote: post #88

Earlier quoted context omitted.

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

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

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.

Re: Closing a 30 pixel gap between native and web

#185

Post by sangnoir »

zeta0134 wrote: post #162

I am reminded very strongly of the line of death: https://textslashplain.com/2017/01/14/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 fo…

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

Re: Closing a 30 pixel gap between native and web

#186

Post by pacifika »

robocat wrote: post #97
kllrnohj wrote: post #55

Earlier quoted context omitted.

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

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

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

Re: Closing a 30 pixel gap between native and web

#188

Post by Kiro »

kajaktum wrote: post #167
bigyikes wrote: post #113

Earlier quoted context omitted.

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…

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

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

Re: Closing a 30 pixel gap between native and web

#189

Post by howenterprisey »

sorenjan wrote: post #154
p1necone wrote: post #100

Earlier quoted context omitted.

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.

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.

Re: Closing a 30 pixel gap between native and web

#190

Post by pronlover723 »

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

Post reply on HN