tomnipotent

Every SPA I come across, especially when using React, uses persistent state so that in-memory changes are synced to cookie/localStorage/server so they survive refreshes. Every popular state management library even supports this natively. And all of that state combined still requires less memory than any of the images loaded, or the JS bundles themselves.

You have to be comfortable with the ORM in every layer - it lives inside your domain models, rather than in another layer shuffling DTO's to presentation/rendering. It also makes it easy to avoid separation of concerns and stuff all your logic in a controller method and call it a day.

The upsides is that by not trying to hide the database and pretend it doesn't exist you can avoid a whole class of work (and the safety abstractions provided) and be incredibly productive if the requirements align.

You absolutely did. It was common practice to stuff things in cookies or query strings to retain state between trips to the server so that some JS could do its job.

Every form also normally ends up duplicating validation logic both in JS for client-side pre-submit UX and server-side with whatever errors it returns for the JS to then also need to support and show to the user.

I think maybe you have unrealistic expectations.

Yesterday I needed to import a 1GB CSV into ClickHouse. I copied the first 500 lines into Claude and asked it for a CREATE TABLE and CLI to import the file. Previous day I was running into a bug with some throw-away code so I pasted the error and code into Claude and it found the non-obvious mistake instantly. Week prior it saved me hours converting some early prototype code from React to Vue.

I do this probably half a dozen times a day, maybe more if I'm working on something unfamiliar. It saves at a minimum an hour a day by pointing me in the right direction - an answer I would have reached myself, but slower.

Over a month, a quarter, a year... this adds up. I don't need "big wins" from my LLM to feel happy and productive with the many little wins it's giving me today. And this is the worst it's ever going to be.

I see this a lot in hero shooters, like Overwatch and Marvel Rivals. A hero you're great at but is bad for the job is worse than a hero you're bad at but is good for the job. It's funny to watch people complain "But I'm not good with X!" then they switch and are at the top of the leaderboard.

I'd much rather have "unlimited" bandwidth with restrictions and the current ambiguous enforcement than clearly defined limits and strict enforcement which penalizes all customers. The current model benefits considerably more people than the alternative.

Can you point to a single example of CF doing this to a legitimate entity that wasn't obviously abusing their plan? Every time this comes up it's always some shady website that's getting the limited treatment.

And it's not "unlimited bandwidth", it's "unlimited bandwidth with restrictions". That's an important and critical distinction. I'm not sure I understand the position that somehow CF needs to subsidize every customer.

Publisher's should be allowed to price their product differently based on the distribution fee of the platform. Steam does not allow you to do this.

For example a publisher could price a new title at $69.99 on Steam or $59.99 on Epic and make the same gross margin, given the platform fees.

That Epic is a sub-par distribution platform does not change this, and Steam's agreement precludes the possibility that competitors can compete on price. Amazon was forced to remove price parity after regulatory pressure.

So like Microsoft of the 90's, Valve is using their market dominance to force publishers into agreements that limit competition. It's only different because we generally like Valve. Epic and GOG cannot compete on price and use that as a mechanism to grow their business because Steam could threaten to remove your product. It just so happens that Steam is so good that even with price discounts it's unlikely that competitors could use that as a major advantage.

Valve used its influence over game publishers to stifle their competition in the digital distribution market.

I'm a happy Valve customer, and I'd still likely buy with them even if other platform's offered lower prices, but that doesn't change that they've leveraged their market domination to force concessions from publishers that benefit their business at the cost of competitors and customers.

Steam's Input system is great, and many people will launch non-Steam games through Steam specifically for the controller mapping. Any game with controller support (console) works flawlessly with the Deck, or any PC using a controller. I don't think I've come across a game that doesn't work out of the box.

My gut is that Framework shipping a desktop with soldered RAM was simply a compromise of opportunity, given the LLM boom and interest in AMD Strix Halo. I can only guess, but I'm betting the Intel desktop will not have soldered parts. I'm further hopeful that if folks need to upgrade this specific device that there will be a healthy second hand market hungry for them like there is for used Nvidia GPU's.

But I do agree that the trend of soldered SoC-like will grow, seeing that less than 1 in 10 consumers ever upgrade a computer. Apple silicon has been out for four years and I don't really come across a lot of grumbling about their integrated components which gives me hope that it's a tenable option and we're worried about nothing.

By weight that would make them the 3rd most consumed fruit in the US after apples and bananas, that has to be worth something.

> one of the groups that was motivated was MS

I remember Microsoft being a huge marketing proponent of the 3-tier architecture in the late 90's, particularly after the release of ASP. The model was promoted everywhere - MSDN, books, blogs, conferences. At this point COM was out of the picture and ASP served as both front-end (serving HTML) and back-end (handling server responses).

The Percona founders worked at MySQL AB previously.

I think it's a perfectly fine approach in 2025 now that that CI/CD have proliferated and you're less likely to run into a human DBA arbitrarily blocking deployments. It was always the feudal lord mentality of DB operations that made relying so much on stored procedures undesirable.

The author works on Cody at Sourcegraph so I'll give him the benefit of the doubt that he's tried all the major players in the game.

Electron apps were popular, not Electron itself. Even now there are only 4-5 dozen popular apps using it, while I probably run across that number of Qt/GTK apps a month. It's a sort of weird dichotomy it finds itself it.

It was released in 2016, only two years after Atom and Slack and a year after VSCode. Not sure I'd call that late.

Mozilla Positron, their attempt at an Electron-compatible runtime on top of Gecko, did not pick up any traction and was cancelled.

Index-backed point look-ups are not the problem for analytical queries, but rather minimizing disk I/O for large scans with high column or predicate selectivity.

Once you've optimized for the more obvious filters like timestamp and primary key, like using partitions to avoid using indexes in the first place, you're left with the situation where you need to aggregate over many gigabytes of data and an index doesn't help since your query is probably going to touch every page within the filtered partitions.

You can solve some of these problems in Postgres, like partitioning, but now you're stuck with random I/O within each page to perform non-SIMD aggregations in a loop. This approach has a ceiling that other implementations like ClickHouse do not.

Cedar uses a PAX storage layout (hybrid row/column) so I imagine 64KB optimizes well for OLAP workloads while keeping excess disk I/O for point look-ups manageable. Depending on your OLAP load that "excess" I/O could either be a rounding error or a bottleneck.

> You are paying enormous ingress/egress fees to do this.

It looks like their offering runs on the same cloud provider as the client, so no bandwidth fees. Right now it looks to be AWS, but mentions Azure/GCP/self-hosted.

As I pointed out the 10000x speed up claim is smoke and mirrors, and any of your team could have spent 10 minutes and figured that out by profiling the code. It's a silly claim that doesn't hold up to scrutiny and detracts from your project by setting off the bullshit detector that most programmers have on marketing hyperbole. It's not the flex you think it is.

This "10,000x" faster claim is specific to how long it takes to instantiate a client object, before actually interacting with it.

Turns out the LangGraph code uses the official OpenAPI library which eagerly instantiates an HTTPS transport and 65% of runtime was dominated by ssl.create_default_context (SSLContext.load_verify_locations) when I tested using pyinstrument. This overhead is further exasperated by the fact that it's happening twice - once for the sync client, and a second time for the async client. Rest of the overhead seems to be Pydantic and setting up the initial state/graph.

Agno wrote their own OpenAPI wrapper and defers setting up the HTTPS transport during agent creation, so that cost still exists it's just not accounted for in this "benchmark". Agno still seems to be slightly faster when you control for this, but amortized over a couple of requests it's not even a rounding error.

I hope the developers get rid of this "claim" and focus on other merits.

The function argument defaults to polars, but the actual benchmark code sets duckdb by default.

https://github.com/deepseek-ai/smallpond/blob/ed112db42af4d0...

Have you ever read a quarterly 10-Q/K? Flipped through a board deck? We even routinely make fun of MBA culture because of this stuff. This is just the finance side of things.

The NTSYNC driver lands this month with Linux 6.14. I've been following the Wine MR the last few weeks eagerly waiting for it. Especially for Nvidia users this should help close some of the performance gap between Windows/Linux while the GPU drivers catch up.

https://gitlab.winehq.org/wine/wine/-/merge_requests/7226

> A data-driven approach can optimize for the wrong thing

So does firing from the hip, so what? And I'd wager firing from the hip has a higher failure rate. At least by using data I have an actual argument for my position, other than "but muh feelings!" My CEO doesn't give two shits about how I "felt" the project would go, and I can't imagine how poorly that discussion will go when we meet to review what happened.

At the end of the day the companies that are succeeding and growing are using data to inform their decisions.

It's possible they have a higher percentage of AMD users than other communities, but I highly doubt given the market share that it's statistically possible for AMD to outnumber Nvidia.

> and console gamers outnumber PC gamers

It's my understanding that there are 2-3x more PC gamers than console gamers, but the console gaming market generates more revenue when you include hardware. In fact there are probably more PC gamers today than total consoles ever sold.