191–200 of 418 posts
As much as I like cross-platform stuff, I also really like native UIs that follow native UX patterns, etc.
Also ChatGPT hangs and has more weird bugs compared to Codex.
Earlier quoted context omitted.
That’s why HN users constantly advocate for Vim, a program in which every single thing works completely differently from every other modern application.
Yes, if there's one lesson from historical UI research that still holds, it's that mode switching is expensive. That's why people install vi plugins everywhere. Wait...
I don't get the point of this. The world is trying to make computers faster and more accessible, more web UI slop isn't going to help that. Dumping Javascript entirely is the first step on that road.
It's trivial to write slow UI application in any tech stack, and just being 'native' really means nothing nowadays.
> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap. This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just sli…
Web devs are used to their target being evergreen, so I suppose you could opt in or out of that model: "just give me what you got".
if (typeof Array.prototype.includes === ‘undefined’) { …
request.then(response => response.json())
Earlier quoted context omitted.
Who cares if it looks native? Native UIs change all the time too and not always for the better.
Change over time is something different from apps looking vastly different at any given time.
Earlier quoted context omitted.
We were writing and shipping desktop applications with it back in the nineties. Although many of the arguments against it were similar to the arguments against Electron today.
I think the UI look and feel was very ugly for many users and that caused its demise. The cross platform skin was ugly. The native skins were in the uncanny valley. The framework was reasonably good for its time. By the time good looking UI frameworks came, the bad reputation was already set.
Earlier quoted context omitted.
Which native framework? Even in a "post-vibe code" era I wouldn't want to create multiple versions of the same app, and none of the "platform-native" GUI toolkits run on everything. SwiftUI is apple-only, gtk has pretty bad compatibility on non-linux, qt is decent but requires C++ or python, and even so still not much for mobile. Don't even get started on "Windows frameworks", because as I write this sentence they ma…
> if you want a truly universal UI Right. If you want your app to look the same, custom way, ditching what the OS has to offer. Some developers still believe an operating system has useful UI components and patterns worth adopting. From this thread it's clear that there's plenty who don't. Personally I view that as a regression.
Of course there is value in having "OS-native" buttons, transitions, windows etc. And many parts of GUIs are basically standardized. The problem is all the parts that are not, and have to look the same everywhere.
Earlier quoted context omitted.
Deno also just strips the type annotations when running TS code - at least by default. To get type checking you'll need to run via `deno run --check`, or use the separate `deno check` subcommand. No big deal since type checking and linting usually happens automatically in the IDE during development.
Good to know. Does it also preclude features like enums?
> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap. This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just sli…