4 ms·

We don't even need to wait for that. Right now web developers are creating the new generation of web-based apps that will consume everything that M1 can give an

We don't even need to wait for that. Right now web developers are creating the new generation of web-based apps that will consume everything that M1 can give and more. In fact these apps already existed, they were just largely ignored because they're so power-hungry (just look at electron and similar stuff).

mrweasel 6y ago
Even worse: Developers will get an M-series Mac, write Electron apps that performs okay. They will then ship them as cross platform app, that will absolutely suck on any other platform.
imtringued 6y ago
Where is that inefficiency supposed to come from though? I mean there are four big inefficiencies that came with JS. 1. Garbage collection and minimum runtime Garbage collection decreases memory efficiency, browsers need a certain minimum amount of resources to render a page, no matter how complicated leading to 500MB RAM text editors like Atom and worse once you open files. Similar problems plague Eclipse and IntelliJ which both often consume 1GB of RAM. The JVM often needs 150MB for an empty or perfectly optimized app. 2. Everything is an object with pointers This is especially bad in Javascript where every object is basically a hashmap. This causes performance slowdowns because even something as simple as looking up a field is a pointer chase through several layers now. Raw numerical data may consume a lot of memory if you are not using typed arrays. Especially bad with ArrayList<Integer> in Java. 3. JIT JIT compilers can only spend a certain amount of time on optimizations, which means JIT languages tend to either suffer from slow start up times or faster start up but less optimizations. 4. GUI complexity Things like having animations and constantly recomputing layouts. If you designed your processors for these things and made them fast at this, the only further source of slowdown is a lack of caring because you have already exhausted the unavoidable technical reasons. E.g. your processor is so fast, you write a naive algorithm that takes 5 seconds on the fastest computer available but then takes 20 seconds on an old computer.
- josho 6y ago
  I think the next layer is cross platform bridges. Look at multi-platform products like ms office and how slow they run on a Mac. I suspect because there is a translation layer to bridge win32 calls to Mac equivalents. And that seems like it would be point 5 on your list.
- zepto 6y ago
  > If you designed your processors for these things and made them fast at this What does that look like? There is a reason Apple doesn’t do #1 and #3 and is moving away from #2 in their own code. They are just inefficient ways of doing things. Designing a processor to support an inefficient mechanism will still lose out to a processor which doesn’t have to.
- Klonoar 6y ago
  I don't think "animations" fits here. Well-implemented CSS animations are generally fine (though this is in and of itself a high skill to do well, I think). If you're still driving animations with pure JS, you probably need a refresher in modern web dev. Diffing a VDOM might fit here, but that's not really GUI-specific - just a combination of your earlier points.

mrweasel 6y ago

Even worse: Developers will get an M-series Mac, write Electron apps that performs okay. They will then ship them as cross platform app, that will absolutely suck on any other platform.

imtringued 6y ago

Where is that inefficiency supposed to come from though? I mean there are four big inefficiencies that came with JS. 1. Garbage collection and minimum runtime Garbage collection decreases memory efficiency, browsers need a certain minimum amount of resources to render a page, no matter how complicated leading to 500MB RAM text editors like Atom and worse once you open files. Similar problems plague Eclipse and IntelliJ which both often consume 1GB of RAM. The JVM often needs 150MB for an empty or perfectly optimized app. 2. Everything is an object with pointers This is especially bad in Javascript where every object is basically a hashmap. This causes performance slowdowns because even something as simple as looking up a field is a pointer chase through several layers now. Raw numerical data may consume a lot of memory if you are not using typed arrays. Especially bad with ArrayList<Integer> in Java. 3. JIT JIT compilers can only spend a certain amount of time on optimizations, which means JIT languages tend to either suffer from slow start up times or faster start up but less optimizations. 4. GUI complexity Things like having animations and constantly recomputing layouts. If you designed your processors for these things and made them fast at this, the only further source of slowdown is a lack of caring because you have already exhausted the unavoidable technical reasons. E.g. your processor is so fast, you write a naive algorithm that takes 5 seconds on the fastest computer available but then takes 20 seconds on an old computer.

josho 6y ago
I think the next layer is cross platform bridges. Look at multi-platform products like ms office and how slow they run on a Mac. I suspect because there is a translation layer to bridge win32 calls to Mac equivalents. And that seems like it would be point 5 on your list.
zepto 6y ago
> If you designed your processors for these things and made them fast at this What does that look like? There is a reason Apple doesn’t do #1 and #3 and is moving away from #2 in their own code. They are just inefficient ways of doing things. Designing a processor to support an inefficient mechanism will still lose out to a processor which doesn’t have to.
Klonoar 6y ago
I don't think "animations" fits here. Well-implemented CSS animations are generally fine (though this is in and of itself a high skill to do well, I think). If you're still driving animations with pure JS, you probably need a refresher in modern web dev. Diffing a VDOM might fit here, but that's not really GUI-specific - just a combination of your earlier points.