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

41–50 of 313 posts

Re: Closing a 30 pixel gap between native and web

#41

Post by make3 »

kanonieer wrote: post #32

> We’re excited to announce the availability of a new PWA feature that closes this gap and helps blur the line between apps and websites even more. I don't see how they can use "blurred line" as a positive trait here. There are important differences between native apps and web apps, why hide this information from a regular user, especially when this information can be conveyed by 30 pixels.

because actual regular answers don't understand what any of this means, and this just means that the devs have more control over what experience they give them

Re: Closing a 30 pixel gap between native and web

#42

Post by mmastrac »

MartinMond wrote: post #30

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

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

Re: Closing a 30 pixel gap between native and web

#43

Post by int_19h »

gildas wrote: post #23
tshaddox wrote: post #20

Earlier quoted context omitted.

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.

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.

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

Re: Closing a 30 pixel gap between native and web

#44

Post by wolpoli »

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.

Re: Closing a 30 pixel gap between native and web

#45

Post by FpUser »

smoldesu wrote: post #37
guhidalg wrote: post #18

Earlier quoted context omitted.

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

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

Re: Closing a 30 pixel gap between native and web

#46

Post by int_19h »

kanonieer wrote: post #32

> We’re excited to announce the availability of a new PWA feature that closes this gap and helps blur the line between apps and websites even more. I don't see how they can use "blurred line" as a positive trait here. There are important differences between native apps and web apps, why hide this information from a regular user, especially when this information can be conveyed by 30 pixels.

We're talking about web apps that are specifically intended to be installed locally and look like native apps. What are those "important differences" in this context?

(and note that you can still use PWA in the browser if you want to, and thus deny it this ability)

Re: Closing a 30 pixel gap between native and web

#47

Post by rnestler »

MartinMond wrote: post #30

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

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.

Re: Closing a 30 pixel gap between native and web

#48

Post by smoldesu »

FpUser wrote: post #45
smoldesu wrote: post #37

Earlier quoted context omitted.

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…

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

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.

Re: Closing a 30 pixel gap between native and web

#49

Post by postalrat »

gildas wrote: post #23
tshaddox wrote: post #20

Earlier quoted context omitted.

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.

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.

Re: Closing a 30 pixel gap between native and web

#50

Post by postalrat »

armchairhacker wrote: post #33
danans wrote: post #28

Earlier quoted context omitted.

So ... Flutter? https://flutter.dev/

Sure. As well as certain other platforms like Kotlin multiplatform The only issue is that these still have to compile to JavaScript, which in practice leads to slower performance and potential for improper semantics on the JS side. It would be better to have them executed in WASM and then have better WASM-browser integration

A better WASM-browser integration would mean more security risks running WASM.
Post reply on HN