Live data from Hacker News

High-Level Is the Goal

bvisness.me

141–150 of 158 posts

Re: High-Level Is the Goal

#141
post #121

I know this article is largely about too many js frameworks and also a call to making better tooling for low-level programming. But it is also largely about the fact that most people making those js frameworks are not low-level programmers. Folks really ought to check out Datastar. It's a newish js framework that is extremely innovative despite leaning as much as possible on browser apis. It's htmx + alpine + much mo…

I'm switching to Data Star because it feels like it exists in the golden zone between HTMX and React.

I'd say it's not in between so much as subsumes both, and then does even more. While being smaller, faster and simpler. Htmx v4 (in beta) will close the gap by becoming a heavier datastar-lite with idiomorph and sse built in, but no signals, SDKs, and just all-round polish and back-to-front integration.

Re: High-Level Is the Goal

#143
post #110

React gets used because no matter if there is a better way, that's what the company mandated. They want to hire "react devs". Perhaps AI will help us by allowing us to swap to simpler and better solutions without the same level of pain and without necessarily having to hire experts in that new solution?

Moving to preact, at the very least, is not a huge endeavor.

Re: High-Level Is the Goal

#144

I think the point about tooling being the problem deserves more emphasis. I'm a firm believer that the right thing to do should be the easiest thing to do. Currently, the easiest place to innovate is at the top of the stack, using web technologies and languages like JavaScript. You can see this with languages like Rust and Go—they're some of the first low-level programming languages with actually good tooling, and, a…

> and not have to worry about the right libraries being installed on my system and whether I've generated a Makefile. Packages are easily searchable, hosted on popular platforms like GitHub, and I can file bugs and ask questions without having to join an obscure mailing list or deal with an unfriendly community.

Maybe it's just me, but that right there is the stuff of nightmares. What library, and written by who, is it going to pull in.

Re: High-Level Is the Goal

#145

The author doesn't understand the point of low level, and strikes me as a person who's programming to "fit in"

I work at Mozilla on their wasm compiler.

The social justice company that laid off many engineers, has questionable finances, and been subsidized by google enough (google needs them to exist) that they became dysfunctional? You're not helping your case WASM never fulfilled it's promises either

Re: High-Level Is the Goal

#146

I think the point about tooling being the problem deserves more emphasis. I'm a firm believer that the right thing to do should be the easiest thing to do. Currently, the easiest place to innovate is at the top of the stack, using web technologies and languages like JavaScript. You can see this with languages like Rust and Go—they're some of the first low-level programming languages with actually good tooling, and, a…

> and not have to worry about the right libraries being installed on my system and whether I've generated a Makefile. Packages are easily searchable, hosted on popular platforms like GitHub, and I can file bugs and ask questions without having to join an obscure mailing list or deal with an unfriendly community. Maybe it's just me, but that right there is the stuff of nightmares. What library, and written by who, is…

Agreed. I don’t think easy package management is the problem, though. Rather, it’s just triggered a Cambrian explosion of packages, and now security needs to catch up.

Re: High-Level Is the Goal

#147

I think the real conclusion is: someone has to make a native cross-platform desktop UI framework that doesn't suck. (Yeah Qt exists, but it really sucks...) Until then, everyone will default to just using the browser for a desktop app, and the beatings will continue. Because of this, I'm really looking forward for PanGUI to step up ( https://www.pangui.io/ ), their UI framework is very promising and I would start usi…

I’m also looking forward to gpui (https://www.gpui.rs/) from the Zed folks.

Re: High-Level Is the Goal

#148

I think people overestimate the necessity of 'high level' conveniences or the difficulty of writing C/C++ to the metal. For example, take Dear.IMGUI which is a c++ UI framework with a kind of data binding, which generates vertex buffers which can be directly uploaded to the GPU and rendered. It supports most of the fancy layout stuff of CSS afaik (flexbox etc), yet its almost as low level as it gets. The code is also…

You give up on hot reloading when using dear imgui and C++, though. There's nothing comparable to Vite in most ecosystems for building desktop programs, as far as I'm aware.

Tooling is the problem, I've used imgui and it's pretty good. But not nearly as practical for prototyping UI.

Re: High-Level Is the Goal

#149

I think the point about tooling being the problem deserves more emphasis. I'm a firm believer that the right thing to do should be the easiest thing to do. Currently, the easiest place to innovate is at the top of the stack, using web technologies and languages like JavaScript. You can see this with languages like Rust and Go—they're some of the first low-level programming languages with actually good tooling, and, a…

> and not have to worry about the right libraries being installed on my system and whether I've generated a Makefile. Packages are easily searchable, hosted on popular platforms like GitHub, and I can file bugs and ask questions without having to join an obscure mailing list or deal with an unfriendly community. Maybe it's just me, but that right there is the stuff of nightmares. What library, and written by who, is…

But what's changed is decisively not "Now I don't know which libraries will be used or who made this library" but instead "The library I wanted was easier to get because the tools work".

Re: High-Level Is the Goal

#150
post #39

He makes an interesting point that we are coding programs that run more slowly now than they did 10 years ago. Javascript has only gotten faster over the last decade, computer have faster CPUs and more RAM. The problem is the frameworks and the programs have gotten slower. What did we gain exactly? Reddit is better at displaying videos and images now. But it's slower despite faster hardware.

I hate the state of affairs. That said my guess is what we „gained“ is tons of telemetry, tracking and the likes, engineers not needing to think about performance to get a feature out, which absolutely lowers the bar to entry, high level abstractions and ux and visual bells and whistles of varying importance and quality (infinite scrolling, streaming updates, image blend modes, blur effects, scroll timeline animation…

As much as I dislike invasive tracking, I don't think the blame lies with Marketing on this one. In most cases I think you could implement all the awful surveillance you want with extremely minimal overhead, even on the web. Certainly malware developers are at the extreme of invasive + low-overhead!

Certainly there are cases where some manager says "put this script in Google Tag Manager and don't ask any questions", but rarely have I ever seen that be the bottleneck. Programmers actually just write really bad frameworks, and then other programmers use them to make even worse software, for literally no reason other than "maybe this framework design would be cool".

Post reply on HN