Would this make cloud providers running low volume fine-tuned models more economically viable?

I think lit is great but the reddit site is the perfect example of why the framework you chose is not the reason your site is slow.

I think lit should distance itself from that mess if possible

Site seems fine to me on mobile and desktop (only use the web app in Firefox). Their main issues are with data fetching, not rendering.

This is for transpilation only. it does not actually validate the typescript or perform any checks during runtime.

esm actually caused errors so there should not be any issues here

Looks like there is two ongoing vitess for postgres projects. Hopefully this competition leads to a better postgres ecosystem.

https://supabase.com/blog/multigres-vitess-for-postgres

It gets more spicy when you realize the founder of vitess, also the founder of planet scale, left planet scale to build this at supabase

he left PlanetScale 4 years ago.

There is also pgdog by the author of pgcat: https://pgdog.dev

Supabase also working on OrioleDB

OrioleDB is not about sharding, it's about the storage layer.

I did not claim OrioleDB is about sharding. It was just an observation that Supabase is contributing to Postgres ecosystem through multiple projects.

they likely said that because the context is "vitess for postgres projects" and OrioleDB is not "vitess for postgres"

Ironically the most performant part of the app, marketplace is written in react native

Because create-react-app was awful

They took two days and used react components and all sorts of shit and we nearly missed the deadline due to it.

The page I did was less than 4K with all content and css embedded and took me 10 minutes.

There's doing the job and there's costing the company a boat load of money doing the job.

"You see, I have this hammer."

"I need a screw driven."

"Hammer! I have a hammer. Just one. This one."

Ok fair enough, but I think you just have incompetent devs

That is precisely my point.

There should be no context change from not using React, unless one is a very junior programmer

o_O

Not sure what you were intending to say, but here's what I parsed when reading that post:

"There should be no context change from <changing the context>".

I think this should be handled by a type assisted linter not typechecker.

Imo a type checker in a dynamic language should is primarily there to avoid runtime errors. In a list with multiple types the typechecker should instead force you to check the type before using an element in that list.

If you want static types python is the wrong language

I would argue the web has remained more stable than any other development space. You can still build something with jQuery code from 2007, and it's still supported by modern browsers. You can even start using modern browser APIs without even upgrading jQuery. You could add any modern library as long as it doesn't depend on jQuery.

If you had a python 2 codebase from the same year, you would basically have to scorch it and do a rewrite.