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

221–230 of 313 posts

Re: Closing a 30 pixel gap between native and web

#221

Post by pjmlp »

com2kid wrote: post #88
criddell wrote: post #74

Earlier quoted context omitted.

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

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.

Re: Closing a 30 pixel gap between native and web

#222

Post by ohgodplsno »

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…

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

Re: Closing a 30 pixel gap between native and web

#223

Post by JaggerJo »

lozenge wrote: post #198
akmittal wrote: post #194

Earlier quoted context omitted.

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.

Re: Closing a 30 pixel gap between native and web

#224

Post by pjmlp »

com2kid wrote: post #184
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…

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…

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.

Re: Closing a 30 pixel gap between native and web

#227

Post by pjmlp »

echelon wrote: post #25
dmayle wrote: post #12

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

Re: Closing a 30 pixel gap between native and web

#228

Post by amelius »

p1necone wrote: post #100
wolpoli wrote: post #44

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…

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.

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.

Re: Closing a 30 pixel gap between native and web

#229

Post by desindol »

pjmlp wrote: post #216
n8cpdx wrote: post #90

Earlier quoted context omitted.

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

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…

Re: Closing a 30 pixel gap between native and web

#230

Post by pjmlp »

desindol wrote: post #229
pjmlp wrote: post #216

Earlier quoted context omitted.

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…

https://www.office.com/

https://learn.microsoft.com/en-us/javascript/api/office-ui-f...

Post reply on HN