1
point
hsn915
Joined 3,053 karma
https://hasen.substack.com/
twitter: hasen_judi
- Non-native English speaker here.
I would not understand the last two sentences. Sidle? Tromp? I don't think I've seen these words enough times for them to register in my mind.
"Strode", I would probably understand after a few seconds of squeezing my brain. I mean, I sort of know "stride", but not as an action someone would take. Rather as the number of bytes a row of pixels takes in a pixel buffer. I would have to extrapolate what the original "daily English" equivalent must have been.
- There are two issues:
- Hosting a website is not so easy for the average person, even the tech savvy person, specially if you try to learn it now using the way large websites are developed.
- Static site blogs lack interactivity: people can't comment on your blog. You have to post a link to Twitter or HN (here!) and interact with people over there.
- Static site blogs also don't usually let people "subscribe" by email or whatnot, so unless people bookmark your website or follow you on Twitter, they are not going to find your content.
P.S. this is a problem area I'm trying to work on, at least on the technical front.
- 3 points
- I think it was around 2015 when everything was basically AWS and Kubernetes
The turning point might have been Heroku? Prior to Heroku, I think people just assumed you deploy to a VPS. Heroku taught people to stop thinking about the production environment so much.
I think people were so inspired by it and wanted to mimic it for other languages. It got more people curios about AWS.
Ironically, while the point of Heroku was to make deployment easy and done with a single command, the modern deployment story on cloud infrastructure is so complicated most teams need to hold a one hour meeting with several developers "hands on deck" and going through a very manual process.
So it might seem counter intuitive to suggest that the trend was started by Heroku, because the result is the exact opposite of the inspiration.
- Sprouts/Gardener: a project to make self-hosting possible (and easy) without linux sysadmin skills
Current version focuses on static site hosting, with templates and zero-config localhost preview, one button to publish changes live.
Part of making this project involves creating a GUI framework for Go
Using flexbox-like layout system, it can render UIs for desktop apps in pure go (without using html/js/css).
- 1 point
- It is time to acknowledge that AI coding does not actually work.
ok, you think it's a promising field and you want to explore it, fine. Go for it.
Just stop pretending that what these models are currently doing is good enough to replace programmers.
I use LLMs a lot, even for explaining documentation.
I used to use them for writing _some_ code, but I have never ever gotten a code sample over 10 lines that was not in need of heavy modifications to make it work correctly.
Some people are pretending to write hundreds of lines of code with LLMs, even entire applications. All I have to say is "lol".
- 3 points
- CA means: this is not just a hobby project, it's a business, and we want to retain the power to make business decisions as we see fit.
I don't like the term "rug-pull". It's misleading.
If you have an open source version of Zed today, you can keep it forever, even if future versions switch to closed source or some source-available only model.
- The API surface I propose only includes one function. No type needed.
It does not even require the target node to be created with a virtual dom in the first place. Just diff the node with the given tree structure efficiently.
Internally the browser might need to create a few accelerator data structures, but that's an implementation detail.
- The linked proposal has many "features" that would be "needed" if you frame the problem in terms of a "template api", centered around "binding" variables, and what not.
https://github.com/WICG/webcomponents/issues/1069
My proposal only adds one native function with nothing else: no new data types, no new apis.
- What we need is not templating. What we need is a native implementation of a virtual dom.
More specifically, a native implementation of the "patch" function:
Where `virtual_dom` is just a plain-data description of the DOM.patch(target_dom_node, virtual_dom)Most of the "slowness" of the DOM come from its requirement to be a 90's era Java style object hierarchy.
Don't call it "templating". Just call it "virtual dom". Everyone knows what that means.
I haven't tried it for coding. I'm just talking about regular chatting.
It's doing something different from prior models. It seems like it can maintain structural coherence even for very long chats.
Where as prior models felt like System 1 thinking, ChatGPT5.2 appears like it exhibits System 2 thinking.