Is this not introducing a massive UI threat vector considering we’re talking about HTML/JavaScript downloaded from the web?
Closing a 30 pixel gap between native and web
71–80 of 313 posts
Re: Closing a 30 pixel gap between native and web
#72> 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.
What difference does the runtime make to the (average) end user? I love that I can create shortcuts of some web apps that have their own window, menu bar etc. (this is already possible in Chrome) and I don't really care they are "web" apps.
> What difference does the runtime make to the (average) end user?
"Incredibly slow and draining the battery 3x as fast" vs "regular"
Re: Closing a 30 pixel gap between native and web
#73I want the opposite of a PWA. I want an app which can be compiled into Desktop/mobile builds and also interpreted in browsers. An alternate HTML/CSS/JS with no JavaScript.
qt can do that with WASM
Re: Closing a 30 pixel gap between native and web
#74With 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…
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” ap…
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.
Re: Closing a 30 pixel gap between native and web
#75Why are the window decoration buttons considered critical on Windows? People using Windows without a keyboard maybe? I always disabled those (or the whole bar) on any system I've used since I can remember.
Re: Closing a 30 pixel gap between native and web
#76I 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.
Re: Closing a 30 pixel gap between native and web
#77With 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…
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.
Re: Closing a 30 pixel gap between native and web
#78I 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 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.)
Re: Closing a 30 pixel gap between native and web
#79I 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…
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.ahkRe: Closing a 30 pixel gap between native and web
#80I 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…
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): https://dpaste.org/pV1aQ 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 th…
Thanks. I was using AltDrag, but I found it a bit sluggish.