6 ms·

Holy fuck, not me. Honestly, I wish we could just skip straight to nothing but web apps. They work, they work consistently, they work cross platform. Native

Holy fuck, not me. Honestly, I wish we could just skip straight to nothing but web apps. They work, they work consistently, they work cross platform. Native apps are absolutely no guarantee you don't have performance problems, and I really don't think it's the render time for HTML/CSS in a webview that's slowing things down. Most times it's just poor consideration for performance from the get-go. Chuck in a bunch of screens that are fetching remote resources before being displayed and viola... MS Teams. ---- Trust me, the development team that fucks up performance with Electron will absolutely fuck it up with native too. This is like blaming the shitty bathroom remodel on the choice of tile instead of the poor craftsmanship.

sershe 4y ago
I dunno, native apps from 2000 on much worse hardware were running more or less the same features much better. Web (and electron/etc.) apps combine encouraging anti-patterns with lowering the barriers of entry too much, it's like if we allowed anyone to build bridges out of 3D printed parts. I am libertarian on most things, but I make exception for things like that... infrastructure safety, air pollution, child abuse and web scripting - these are/got so bad they need to be heavily regulated to keep idiots in line.
drcongo 4y ago
Out of interest, are you a Windows user? It's the only platform where native apps are even worse.
- horsawlarway 4y ago
  I use Linux/Windows/macOS just about daily. Personally - I'd prefer to be on linux full time, but work issues macbooks, and I develop applications that run across all three, so I use all three.
  - drcongo 4y ago
    Thanks for replying.
jimlongton 4y ago
> Trust me, the development team that fucks up performance with Electron will absolutely fuck it up with native too. Microsoft is celebrating a "massive" performance improvement which means Teams, which mostly renders text chat, opens in 10s instead of a minute. I really doubt native apps would have delays like that.
- horsawlarway 4y ago
  I'm willing to bet a good bit that most of the performance improvement is coming from the "Client data layer" that they show in their updated graphic about the new stack. I really doubt the performance issues are based on the webview's performance rendering text. If so, VSCode wouldn't exist... and it does exist. I haven't used angular in a long time, so you could maybe convince me that it's a shite framework from a performance perspective (I'd believe this, honestly) but I still bet money the delay is not local processing delays, but waiting for remote resources.
  - kyriakos 4y ago
    Even typing in teams has a perceivable latency which I doubt it caused by accessing remote resources.
  - mike_hearn 4y ago
    There's a lot of space between rendering text and doing a slow remote database query. HTML is great but it just wasn't designed for building efficient UIs: • No multi-threading, by implication you can't do things like deserialize large object graphs on a background thread. To get data to your UI you have to deserialize it on the UI thread, leading to jank. • JS is a JIT compiled dynamically typed language. The memory overhead compared to C++ or even AOT compiled Java is correspondingly higher. • DOM/CSS are extremely generic because they have to satisfy both document and app use cases. They're both low and high level simultaneously. On one hand that's great for making interactive documents - an important class of thing that non-web tech mostly ignores - on the other hand it means a lot of branches in hot paths, stringly-typed everything, big code footprint in the renderer, heavy objects, high level libraries can't use shared memory and more. The header file for Blink's DOM Element class is ~2000 lines by itself. • No modularity whatsoever at any level. HTML just accretes more and more stuff as the years go by. There's no way to opt out, or select a lighter weight faster renderer. As it grows, memory usage and CPU time goes inexorably upwards despite fantastically huge budgets thrown at optimizing it. • The one-size-fits-all sandboxing model imposes enormous overheads. Do I really need apps from well known brands like GitHub or Slack to be strongly sandboxed? Not really. It's nice to have a safety net in case of exploits, but I don't actually need these apps to be treated as radioactive all the time and the cost of doing so is very high. Native apps can use the latest DirectX on Windows, where hw features appear first, but Chrome serializes OpenGL command streams from the renderer across process boundaries and then does extensive validation before rendering them. • JS was never designed for large teams. Why did Java become so popular in the enterprise? Because it has lots of rules and features that are intended to let lots of devs work together without stepping on each others toes or making too much of a mess. JS doesn't have the same approach. It all adds up!
ASalazarMX 4y ago
> Honestly, I wish we could just skip straight to nothing but web apps Why must you curse us like that? Web apps became such a clusterfuck because HTML and the world-wide-web were never intended to run applications, but more and more was piled upon it until it somehow did. Apps in the browser have shown undeniable advantages, but now that we've seen what we need, why not design a cross-platform toolkit that allows web apps through a protocol actually designed for applications. Something like Java/Flash tried to do, but using what we learned about web apps, back ends, and standardization.
- aaomidi 4y ago
  HTTP never intended to be anything other than content delivery pipe. Protocols evolve.
  - ASalazarMX 4y ago
    Meant HTML, comment corrected.
- frodowtf 4y ago
  You mean WebAssembly?
- mike_hearn 4y ago
  Let me know what you think of this attempt at such a platform: https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI4J5AbxVWKEeYr6hscT8/edit https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI... By the way, one of the wild-card impacts of GPT-4 might be that native apps arise again. It's very good at translating code from one platform to another.
cudgy 4y ago
Couldn’t disagree more. Web stacks are abominations of a technology never intended to be actual apps. Yes, I am blaming the shitty web app rewrite on the choice of an inappropriate technology stack. Web apps many times don’t even work on the same platform with browser dependencies. Ever had to load a web page on a different browser to get it to work?

sershe 4y ago

I dunno, native apps from 2000 on much worse hardware were running more or less the same features much better. Web (and electron/etc.) apps combine encouraging anti-patterns with lowering the barriers of entry too much, it's like if we allowed anyone to build bridges out of 3D printed parts. I am libertarian on most things, but I make exception for things like that... infrastructure safety, air pollution, child abuse and web scripting - these are/got so bad they need to be heavily regulated to keep idiots in line.

drcongo 4y ago

Out of interest, are you a Windows user? It's the only platform where native apps are even worse.

horsawlarway 4y ago
I use Linux/Windows/macOS just about daily. Personally - I'd prefer to be on linux full time, but work issues macbooks, and I develop applications that run across all three, so I use all three.
- drcongo 4y ago
  Thanks for replying.

jimlongton 4y ago

> Trust me, the development team that fucks up performance with Electron will absolutely fuck it up with native too. Microsoft is celebrating a "massive" performance improvement which means Teams, which mostly renders text chat, opens in 10s instead of a minute. I really doubt native apps would have delays like that.

horsawlarway 4y ago
I'm willing to bet a good bit that most of the performance improvement is coming from the "Client data layer" that they show in their updated graphic about the new stack. I really doubt the performance issues are based on the webview's performance rendering text. If so, VSCode wouldn't exist... and it does exist. I haven't used angular in a long time, so you could maybe convince me that it's a shite framework from a performance perspective (I'd believe this, honestly) but I still bet money the delay is not local processing delays, but waiting for remote resources.
- kyriakos 4y ago
  Even typing in teams has a perceivable latency which I doubt it caused by accessing remote resources.
- mike_hearn 4y ago
  There's a lot of space between rendering text and doing a slow remote database query. HTML is great but it just wasn't designed for building efficient UIs: • No multi-threading, by implication you can't do things like deserialize large object graphs on a background thread. To get data to your UI you have to deserialize it on the UI thread, leading to jank. • JS is a JIT compiled dynamically typed language. The memory overhead compared to C++ or even AOT compiled Java is correspondingly higher. • DOM/CSS are extremely generic because they have to satisfy both document and app use cases. They're both low and high level simultaneously. On one hand that's great for making interactive documents - an important class of thing that non-web tech mostly ignores - on the other hand it means a lot of branches in hot paths, stringly-typed everything, big code footprint in the renderer, heavy objects, high level libraries can't use shared memory and more. The header file for Blink's DOM Element class is ~2000 lines by itself. • No modularity whatsoever at any level. HTML just accretes more and more stuff as the years go by. There's no way to opt out, or select a lighter weight faster renderer. As it grows, memory usage and CPU time goes inexorably upwards despite fantastically huge budgets thrown at optimizing it. • The one-size-fits-all sandboxing model imposes enormous overheads. Do I really need apps from well known brands like GitHub or Slack to be strongly sandboxed? Not really. It's nice to have a safety net in case of exploits, but I don't actually need these apps to be treated as radioactive all the time and the cost of doing so is very high. Native apps can use the latest DirectX on Windows, where hw features appear first, but Chrome serializes OpenGL command streams from the renderer across process boundaries and then does extensive validation before rendering them. • JS was never designed for large teams. Why did Java become so popular in the enterprise? Because it has lots of rules and features that are intended to let lots of devs work together without stepping on each others toes or making too much of a mess. JS doesn't have the same approach. It all adds up!

ASalazarMX 4y ago

> Honestly, I wish we could just skip straight to nothing but web apps Why must you curse us like that? Web apps became such a clusterfuck because HTML and the world-wide-web were never intended to run applications, but more and more was piled upon it until it somehow did. Apps in the browser have shown undeniable advantages, but now that we've seen what we need, why not design a cross-platform toolkit that allows web apps through a protocol actually designed for applications. Something like Java/Flash tried to do, but using what we learned about web apps, back ends, and standardization.

aaomidi 4y ago
HTTP never intended to be anything other than content delivery pipe. Protocols evolve.
- ASalazarMX 4y ago
  Meant HTML, comment corrected.
frodowtf 4y ago
You mean WebAssembly?
mike_hearn 4y ago
Let me know what you think of this attempt at such a platform: https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI4J5AbxVWKEeYr6hscT8/edit https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI... By the way, one of the wild-card impacts of GPT-4 might be that native apps arise again. It's very good at translating code from one platform to another.

cudgy 4y ago

Couldn’t disagree more. Web stacks are abominations of a technology never intended to be actual apps. Yes, I am blaming the shitty web app rewrite on the choice of an inappropriate technology stack. Web apps many times don’t even work on the same platform with browser dependencies. Ever had to load a web page on a different browser to get it to work?