Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ode to the M1

fabiensanglard.net

Post reply on HN
Print view View original

151–160 of 286 posts

Re: Ode to the M1

#151

Post by wiseowise »

zarzavat wrote: post #69
mrd3v0 wrote: post #17

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their program[6]. In other terms, I fear that once devs figure out how powerful the M1 is, they will throw more "features" at it. Can we please stop replicating the "growth" fallacy into software ecosystems? Haven't we learnt enough about how unsustainable and damagin…

Electron is quite efficient. You get a modern GPU composited UI, and JavaScript is by far the most highly optimized scripting language out there. The problem with Electron is RAM, disk space, and download size, which is because every app needs to ship its own copy of Blink. This is a solvable problem, but nobody is incentivized to solve it.

It has been solved decades ago: it’s called a browser.

Re: Ode to the M1

#152

Post by satvikpendem »

LtWorf wrote: post #111
presentation wrote: post #43

Earlier quoted context omitted.

Keep hoping, because it won’t happen. Practically no consumers care except for other software engineers complaining loudly on HN, and meanwhile companies save millions by not handcrafting their CRUD apps in assembly.

Consumers care but have no choice. Like consumers that want to buy a phone that fit in the hand… there is none at a reasonable price.

How do you know they care but have no choice? Are average people besides devs talking about how slow their web apps are?

For your small phone example, even Apple is cutting production of their smaller phones because not enough people are buying them. The entire premise really is overblown online.

Re: Ode to the M1

#153

Post by memefrog »

sneak wrote: post #150
Lukas_Skywalker wrote: post #107

Earlier quoted context omitted.

Money is only part of the equation. It's pretty wasteful to have to toss a computer because one component failed, when that specific component would be replaceable in other brands.

This seems like a movement of the goalposts. I'm not that concerned about electronic waste, and I haven't seen any great arguments why anyone really should be. It's not replaceable in other brands, because approximately no one is making a laptop remotely equivalent to the M1/M2. Perhaps the Surface Pro, but even that isn't a good comparison. Remember when Apple made the first Air and it was so far ahead of every othe…

>I'm not concerned about electronic waste.

Why not?

Re: Ode to the M1

#154

Post by dnh44 »

makeitdouble wrote: post #97
wtallis wrote: post #52

Earlier quoted context omitted.

> Wasn't the whole OSX's new paradigm a switch to high level language and frameworks , with compositing window management to display super fancily rendered hello worlds ? No, not really. You're making it sound like Classic MacOS applications were written in assembly, when it was mostly C++. Switching to Objective-C was more of a lateral move, not a clear step forward in time or level of abstraction. The Mac OS X grap…

Many Obj C libraries were a wrapping layer on top of the Carbon APIs and in terms of abstraction Obj C is also a level above C++. Passing everything as messages is an additional layer of indirection. NextSTEP itself was a big change compared to X or Windows's GUI stack. NeXT machines were beefy and adjusted to high workloads so the user experience wasn't problematic, but it's still more resource use than the standard…

Electron’s bloat and power consumption wouldn’t bother me so much if the performance was actually good on a fast machine. But the experience is awful compared to a native app.

Re: Ode to the M1

#155

Post by satvikpendem »

speedgoose wrote: post #21
mrd3v0 wrote: post #17

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their program[6]. In other terms, I fear that once devs figure out how powerful the M1 is, they will throw more "features" at it. Can we please stop replicating the "growth" fallacy into software ecosystems? Haven't we learnt enough about how unsustainable and damagin…

For that you need a better alternative. I’m not aware of anything.

Flutter works pretty well for apps like these.

Re: Ode to the M1

#156

Post by memefrog »

Dalewyn wrote: post #72
ThrowAway1922A wrote: post #49

Earlier quoted context omitted.

What do you mean still? They’re only a few years old at this point. It shouldn’t be impressive that a basically new computer still does everything that one would want to do.

Keep in mind that people in their 30s and older today either grew up or lived their working years during a time when upgrading computers every year or two was the norm.

That hasn't been necessary for 15 years.

Re: Ode to the M1

#157

Post by wiseowise »

raverbashing wrote: post #95
the_gipsy wrote: post #87

Earlier quoted context omitted.

If somebody just made Electron into a HTML/CSS/JavaScript engine capable of opening just the HTML/etc parts from, say, an HTTP server, and then shipped it to all users worldwide...

Heh I wonder if anyone did that comparison, an Electron app vs Chrome + a local copy of node+express whatever running the backend

Why does it have to be node and express? You can compile lightweight Go, C++, Rust binaries.

Re: Ode to the M1

#158

Post by satvikpendem »

DonHopkins wrote: post #122
slowmovintarget wrote: post #74

Earlier quoted context omitted.

Godot? Targets Windows, UWP, MacOS, Linux, BSD, Android, iOS, and Web: https://docs.godotengine.org/en/stable/about/faq.html Nothing says you have to use it to make a game. I recall seeing articles here on HN about using it as a cross-platform app development framework. GDScript may be less appealing than JavaScript, however.

Godot is wonderful. But GDScript is a horrible, terrible, ill conceived idea. So how's the QuakeC development ecosystem these days? How good is ChatGPT at generating QuakeC? Who's still programming Unity3D in Managed JScript or Boo?

I wonder if Bevy might be a good alternative, it's in Rust which isn't a proprietary language.

Re: Ode to the M1

#159

Post by satvikpendem »

Y-bar wrote: post #80
zarzavat wrote: post #69

Earlier quoted context omitted.

Electron is quite efficient. You get a modern GPU composited UI, and JavaScript is by far the most highly optimized scripting language out there. The problem with Electron is RAM, disk space, and download size, which is because every app needs to ship its own copy of Blink. This is a solvable problem, but nobody is incentivized to solve it.

A similarly bad problem is that Electron apps by default does not adhere to the operating system conventions and API:s, and often also does not use the the features which makes the OS good. For example all Electron apps I use have their own implementation of a spell checker rather than hooking into the system one. Normally in Mac OS if I add a word to the system dictionary all apps will learn that word, but in each E…

Most consumers don't care about native controls. In fact for a company it's more important to have a unified UX across all devices so that the user can pick up easily from one to the other, ie Macbook to iPhone. Slack is a good example of this.

Re: Ode to the M1

#160

Post by whilenot-dev »

rhaway84773 wrote: post #86
winter_blue wrote: post #62

Earlier quoted context omitted.

What I'd really like to see with CEF et al, is JS being dropped, in favor of directly controlling the DOM from the host language. Then we could, for example, write a Rust (or Kotlin, Zig, Haskell, etc) desktop application that simply directly manipulated the DOM, and had it rendered by a HTML+CSS layout engine. Folks could then write a React-like framework for that language (to help render & re-render the DOM in an e…

We already know HTML/CSS are not the best way to do layout. We already have many desktop based UI frameworks to create cross platform desktop apps. GTK, QT, etc which are also superior to the single app, limited size focused Android/iOS UI frameworks. More importantly, unlike iOS/Android, they’re even cross platform. HTML/CSS/JS are successful because of the same reason electron exists. The success of the web means t…

> HTML/CSS/JS are successful because of the same reason electron exists. The success of the web means there’s a huge developer base that knows how to work with HTML/CSS/JS

The actual reason is a different one IMHO. The implementation of web standards enabled cross-platform engines that provide every UI customization one could possibly need for a SaaS product. This decision included many benefits for businesses and developers alike, such as:

- User data stays in the walled garden

- Users most probably already have a web-browser installed

- Responsibility to keep the runtime (web-browser) up-to-date is on the user side

- Automated updates (POV user)

- No installation instructions

I think it as much as a business decision as it was the decision from developers to bet on HTML/CSS/JS instead of GTK, QT, etc.

Post reply on HN