Totally! The feeling of using AI to create something not fully productive is similar to the "just one more turn..." effect when playing a Civilization game. Even when you realize it's a waste, it's hard to stop, because the next dopamine hit is just around the corner.
I see Bun’s Rust rewrite (esp the style how it was done) as a form of massive internet trolling for PR reasons. By making a bigger fuss about it, we’re feeding the troll
My programming career literally started in a dumpster in the ’90s, when I found a Turbo Vision book someone had thrown away. I picked it up and immediately fell in love with the bluish TUIs that anyone could make.
Thanks! But I meant JS based virtual scrolling in web pages. E.g. dynamic data tables that only render the part of the table that fits in the viewport.
> So it's effectively a net+DOM+script-only browser with no style/layout/paint.
> ---
> Definitely fun for me to watch as someone who is making a lightweight browser engine with a different set of trade-offs (net+DOM+style/layout/paint-only with no script)
Both projects (Lightpanda, DioxusLabs/blitz) sound very interesting to me. What do you think about rendering patterns that require both script+layout for rendering, e.g. virtual scrolling of large tables?
What would be a good pattern to make virtual scrolling work with Lightpanda or Blitz?
I love this. We need more experimenting with UX status quo. Especially with drag and drop, which, I think all many would agree, is one of the not ideal UX patterns espacialy with scrolling involved.
The research is never over. Good ideas, bad ideas, doesn't matter as long as they continue to inspire.
I hope yes! Some people are interested in this field. I think, we would need more mor flexible, adaptive scrapers based on content not the HTML structure. This week alone, I had interactions about "AI assisted web scraping" with two people:
GitHub is a great example of mostly server-side generated HTML. Their output HTML is very stable: the structure rarely changes, is semantic, logical, and self-documenting. This has helped hundreds of browser extensions (e.g. Refined GitHub, ZenHub) and userscripts, including dozens of my own.
Of course, treating HTML as API/data exchange format is fragile and might be seen as hindering progress by some of the GitHub staff. However, it has been like that for many years and was beneficial for the community. Perhaps not that beneficial for GitHub, who would prefer integrations over the official API.
If GitHub's HTML changes to a dynamic React-powered div-soup, that might be the end of browser extensions and userscripts. And another reason for power users to flock to other platforms.
Edit: React does not necessarily mean div-soup, but I have seen too many React-powered div-soups to expect GitHub's HTML to stay the same.
Tracking this as a task helps my digital hygiene, and at the same prevents me from doing it more often than needed.