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

I don't understand what kind of evidence you expect to receive.

There are plenty of examples from talented individuals, like Antirez or Simonw, and an ocean of examples from random individuals online.

I can say to you that some tasks that would take me a day to complete are done in 2h of agentic coding and 1h of code review, with the additional feature that during the 2h of agenti coding I can do something else. Is this the kind of evidence you are looking for?


Yes, the model runs in C, you just provide the model weights to the program.

The main advantage is that you don't need the python interpreter to run the program.

While not revolutionary, it is definitely not trivial and its main purpose is to demonstrate Claude code abilities in a low level, non trivial task.


The problem with jQuery is that, being imperative, it quickly becomes complex when you need to handle more than one thing because you need to cover imperatively all cases.

Yeah, that's the other HN koan about "You probably don't need React if..." But if you are using jquery/vanilla to shove state into your HTML, you probably actually do need something like react.

It's not really about state but dom updates.

After having some time to think about it, I've seen some really perverse DOM stuff in jquery. Like $(el).next().children(3) type stuff. So I think this stuff really fell-over when there was 'too much state' for the DOM.

I think if you want to go high-dom manipulation a la jQuery, and want some form of complex state, storing the state _on_ the DOM might make sense? Things like data attributes and such, but I also feel like that’s itching for something more like htmx or maybe svelte (I’ve not looked into either enough, so I may be completely off base).

I do agree with the notion that jQuery is easy to mishandle when logic grows beyond a pretty narrow (mostly stateless) scope. It’s fantastic up until that point, and incredibly easy to footgun beyond it.


Part of me feels the same way, and ~2015 me was full on SPA believer, but nowadays I sigh a little sigh of relief when I land on a site with the aesthetic markers of PHP and jQuery and not whatever Facebook Marketplace is made out of. Not saying I’d personally want to code in either of them, but I appreciate that they work (or fail) predictably, and usually don’t grind my browser tab to a halt. Maybe it’s because sites that used jQuery and survived, survived because they didn’t exceed a very low threshold of complexity.

Facebook is PHP ironically.

It was once upon a time, hence them moving to HHVM to interpret it, but it’s been all but replaced with a PHP spinoff named Hacklang now.

I think in 2026 Facebook is a conglomeration of a bunch of things... Definitely not just PHP anymore.

European companies are fined all the time as well, you just don't see the news about it, there definitely no ill-intent vs american companies as you are trying to imply


It's not about being beautiful or ugly, it's about being simple.

Python is simple to read / write and easier to reason about, especially for people that need a programming language to solve a problem but are not software engineers.

The reason it won, especially in data analysis, is because most data analyst are/were not software engineer and Python feels more natural to people.

The indentation is not a big problem when a decent text editor is used


> As long as revenue rises faster than training costs

And this is definitely not happening. They are covering training costs with investors money, and they can't really stop it without their competitors catching up


Youtube didn't have a significant competitor, once the quality started declining and the ads started creeping up, there were no alternatives to switch to (as a user) because the content creators were in on the profit.

The same isn't true about ChatGPT.

Anthropic and Google provides a similar product, and switching to a better/cheaper platform is fairly easy as it only depends on you and not on others (content creators or friends) doing the same.


I agree with everything, but just to be clear:

> This is what web developers want

I don't think it is what web developers want, it is what customers expect.

Of course there are plenty of situation where the page is totally bloated and could be much leaner, but the overall trend to build web applications instead of web pages is dictated by user expectations and, as a consequence, requirements.


Users say "the page shall not load in less than 15 seconds and shall not use less than 5% of my monthly dataplan"?

Odd… are these people with us?


> because you're getting AI editing / writing features in Gmail, Docs, Office 365, etc.

To me it is exactly why this move doesn't make sense.

Why would I use Grammarly/Superhuman for writing with LLM assistance, when I have an out-of-box alternative that, at worst, is equal?

They can't even compete with pricing, because they need to use their competitor models


> Why would I use Grammarly/Superhuman for writing with LLM assistance, when I have an out-of-box alternative that, at worst, is equal?

I think the answer is basically that they have brand recognition and they're trying to ride it. Right now, they have two bad choices: become irrelevant more quickly by having a product that's inferior to built-in LLM tools, or become irrelevant more slowly by having a tool that's comparable (and also works anywhere on the internet, not just on specific websites).


Brand recognition that they're throwing away with a rebrand.


It's not about being closed to other languages, it's about being economically pragmatic in many, many cases.

As shown in the article, you can build ONCE an app that loads in milliseconds by just providing an url to any potential customer. It works on mobile and on desktop, on any operating system.

The native alternative requires:

- Multiple development for any platform you target (to be widely used you need *at least* ios, android, macOS and windows.) - Customers are required to download and install something before using your platform, creating additional friction.

And all of this to obtain at most 20-30ms better loading times?

There are plenty of cases where native makes sense and is necessary, but most apps have very little to gain at the cost of a massive increase in development resources.


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

Search: