Hacker Newsnew | past | comments | ask | show | jobs | submit | kinlan's commentslogin

Here's the OSS repo for Google Opal: https://github.com/breadboard-ai/breadboard

As one of the owners of the GoogleChromeLabs org. Technically anything in this org is not officially supported as it is intended for prototypes and things that might graduate to more fully supported products if there is a fit in the market.

That all being said, I believe this particular change to this particular repo was 5 years ago.


Yes, this was not another "Look what Google killed" post. It's just a kind of HN-interest-hook for a very cool repository. Carlo is a very interesting idea. X-platform GUI render in JS/HTML/CSS is a hot idea, and you guys made something cool. Irish's comment "hopefully it lives on in a community fork" was touching, and I hope so too!. It would be good to see the optimum expression of this idea.


The title of the submission does not tell the same story.


Hello, operator? I'd like to report a case of title mania...Yes, 555 -


Got it :)


I used it as an example because I felt the data was pretty clear. I also felt that it follows a very human pattern (generative tools need customers, like other tools before, so they go with what the industry is demanding).... but now we seen an acceleration.


Huh - that's actually pretty interesting and I hadn't thought of that as an option.. I know Preact was built as a faster alternative while being broadly compatible, but what you are describing is maybe even blending the technologies as that short circuit. neat.


Fwiw - I'm hoping it can break out too. But one of the biggest challenges is that last bit "asking it to use vanilla JS" - unsee this all the time in developer relations: getting developers to ask for a specific thing or even have it on their mind to think about using it is one of the biggest hurdles.

My actual long term hope is that in the future we won't need to think about frameworks at all: https://paul.kinlan.me/will-we-care-about-frameworks-in-the-...


> Frameworks are abstractions over a platform designed for people and teams to accelerate their teams new work and maintenance while improving the consistency and quality of the projects. [...] I was just left wondering if there will be a need for frameworks in the future? Do the architecture patterns we've learnt over the years matter? Will new patterns for software architecture appear that favour LLM management?

Yes! That's exactly what I was trying to get at.


Are you saying that frameworks might become less important because LLMs can just generate boilerplate code instead? Or do I misunderstand? Personally, if the vibe-engineering future that some executives are trying to foist on us means that I'll be reading more code than I write directly, then I want that code to be _doubly_ succinct.


Maybe in a distant future, but why are so obsessed with the anti-framework sentiment? We don't shy away from a framework when coding in Node, PHP, Java…

Is there something about the web — with its eternal backwards compatibility, crazy array of implementations, and 3 programming languages — that seems like it's the ideal platform for a framework-free existence?

Maybe if we bake all of the ideas into JavaScript itself, but then where does it stop? Is PHP done evolving? Does Java, by itself, do everything as well as you want out of Spring?


Just to push back on this a tad. Yes there's growth React, it's popular, but it was consistent up until the introduction of some of the more popular code generation tools where there is a clear acceleration (if you believe builtwith.com data) in the last 9 months or so.


Author here. This is a fair comment. If you have a corpus that can be used as context already it's not like the LLMs will be forcing you in to React, there's probably enough bias (in a good way) to ensure the tool continues to be useful.

What I was trying to get at in the post is that net new experiences is where I see a massive delta


Yeah for sure but I think frameworks will adapt. It's like going back to 2002 and saying that it's better to program in Java because of all the IDEs available and all the corporate money being poured into having the best developer experience there can be. But since LSP arrived, developers choosing a smaller language suffer much less.

The 'LSP' that would allow new frameworks or languages to shine with coding agents is already mostly here, and it's things like hooks, MCPs, ACP, etc. They keep the code generation aligned with the final intent, and syntactically correct from the get go, with the help of very advanced compilers/linters that explain to the LLM the context it's missing.

That's without hypothesising on future model upgrades where fine-tuning becomes simple and cheap, local, framework-specific models become the norm. Then, React's advantage (its presence in the training data) becomes a toll (conflicting versions, fragmented ecosystem).

I also have a huge bias against the javascript/typescript ecosystem, it gives me headaches. So I could be wrong.


Author here. Fwiw this is my hope too. I wrote about something similar in the past https://paul.kinlan.me/will-we-care-about-frameworks-in-the-...


We had very few products that use the fugu apis., and I don't believe we were the first to ship them either in a production website.

If you're looking at fugu in particular (especially in the latter stages) we had external developers or businesses wanting the features.

Note: there are some apis that a Google customer wanted to use first.


But the other browsers objected yet Chrome still shipped them


Years ago I was invovled in getting something similar built for Google IO and Chrome - https://youtu.be/KOCM9_qGccY


This is really cool. The soundtrack is especially fitting:

https://www.youtube.com/watch?v=YT0k99hCY5I


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: