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

251–260 of 313 posts

Re: Closing a 30 pixel gap between native and web

#251

Post by svnpenn »

loudmax wrote: post #21
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 bottom line is that Electron is portable. Unless native apps become as portable as Electron there will be a need for this layer. The optimistic scenario is that WASM becomes the single target that everyone settles on, and that the performance penalty is minimized while the security sandbox is strengthened.

> The optimistic scenario is that WASM becomes the single target that everyone settles on

oh hell no. I reject this in the strongest possible terms. You don't need a web browser to create a program. This is pure laziness. I am a developer. Browser based app is fine for small stuff. But nothing as large as Visual Studio Code, should ever be created as a browser app. This is just an awful idea because it results in dogshit performance, an order of magnitude worse than native solutions.

Re: Closing a 30 pixel gap between native and web

#252

Post by [deleted] »

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.

[deleted]

Re: Closing a 30 pixel gap between native and web

#253

Post by pjmlp »

desindol wrote: post #246
pjmlp wrote: post #244

Earlier quoted context omitted.

My dear I am quite free, unfortunely many people on this planet cannot enjoy the same freedom.

Quoted post unavailable.

Where I come from we don't give tips at the coffee table, the servants earn a proper salary.

Re: Closing a 30 pixel gap between native and web

#254

Post by svnpenn »

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.

better yet we should just outlaw personal computers and laptops, they are causing too much trouble. Better for everyone to just have iPads and iPhones, kill Android too.

Re: Closing a 30 pixel gap between native and web

#255

Post by desindol »

pjmlp wrote: post #253
desindol wrote: post #246

Earlier quoted context omitted.

Quoted post unavailable.

Where I come from we don't give tips at the coffee table, the servants earn a proper salary.

Haha you really are a fucking retard. Just remember overconfidence is a slow and insidious killer.

Re: Closing a 30 pixel gap between native and web

#256

Post by pjmlp »

desindol wrote: post #255
pjmlp wrote: post #253

Earlier quoted context omitted.

Where I come from we don't give tips at the coffee table, the servants earn a proper salary.

Haha you really are a fucking retard. Just remember overconfidence is a slow and insidious killer.

I am quite aware of the fragility of human life.

Re: Closing a 30 pixel gap between native and web

#257

Post by guhidalg »

Sohcahtoa82 wrote: post #160
com2kid wrote: post #92

Earlier quoted context omitted.

Few years back everyone was complaining Apple was copying Microsoft by going all in on flat UIs. While at MS I did run into the ever present problem of many designers only using MacOS so their designs would basically say "do what MacOS does!"[1] which entailed a lot of work by developers to change the default Windows UI widget behaviors to look like MacOS. Thankfully when I got one of those requests across my desk I…

I can't stand flat UIs. Not having buttons be obviously clickable/touchable is a bug, not a feature, as is having UI elements blend in with each other. I personally use WindowBlinds to make my Windows 10 UI look like Windows 2000. I love having a taskbar that has 3D buttons. I like not having multiple windows from a single program getting grouped together. Windows 2000 (or Windows XP with the Classic theme enabled) w…

I agree, but I’ve always wondered if flat UIs had a performance advantage. Like, if your GPU just rendered a bunch of rectangles of a single color instead of having to mask rounded corners or draw borders around things, could the UI run with less resources? Maybe it’s conspiratorial but it helps me sleep at night as a remember not finding buttons during the day…

Re: Closing a 30 pixel gap between native and web

#258

Post by whywhywhywhy »

WA wrote: post #210
whywhywhywhy wrote: post #7

Earlier quoted context omitted.

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…

> Dread to think how an argument for supporting 3+ web engines for a “native” app would go. Well, on mobile, it's slightly different. If you use Capacitor, it uses the OS' native WebView, which is either Chrome (Android) or Safari (iOS). You gotta test for two web engines, but fortunately, they're relatively close. I think a solution like this for desktop would make sense. Modern browser engines don't have that many…

>but fortunately, they're relatively close.

I mean I wish I worked with people with that opinion but somehow the 60+ devs I've worked with over the past 5 years manage to code things that work in Chrome but with many parts broken in Safari and an attitude that it's Safari's fault.

I have little patience for this attitude because the period of time I worked as a dev I had to support IE5.5, IE6, IE7, Safari, Firefox and Chrome. But it is the prevailing attitude.

Re: Closing a 30 pixel gap between native and web

#259

Post by desindol »

pjmlp wrote: post #256
desindol wrote: post #255

Earlier quoted context omitted.

Haha you really are a fucking retard. Just remember overconfidence is a slow and insidious killer.

I am quite aware of the fragility of human life.

Dude you really are the prototype of a German honk. Love it.

Re: Closing a 30 pixel gap between native and web

#260

Post by jrootabega »

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…

Same thing with, e.g., firefox on ubuntu. Not only do you have to hunt for free space, but because of visual design (in turn because of vanity and frivolity, IMO) it's not clear where it is until you mouse over it and display its highlighted color. The "close" button barely even changes color on the default theme, so god forbid you single-click it. And tabs can accidentally be dragged, rather than just failing to drag the entire window.

This next part is more of a funny absurd story than a complaint, but I once had a recurring bug where the browser UI was shifted down a hundred or so pixels from the top of the window, replaced by some flat "blank" color. But the interactions were still taking place in their expected areas. So in order to fix that, I had to hunt around with my mouse at the top of the window, look for UI elements to become highlighted in the middle of the window, and then move left or right until I was confident I was over the title bar (which I couldn't know for sure, since it itself doesn't highlight).

Post reply on HN