Not sure about that, works for me just fine on many (even old) computers. But even if it was true, I prefer keeping the number of open tabs below 100 if that means not running browser made by an advertising agency. Talk about conflict of interests...
Part of the difference is that the modern web is built for Chrome. Even checking ones site or service with Firefox for functionality is a bridge too far, much less performance.
thanks, I've been looking at all the spreadsheet-over-a-database projects i can find, and hadn't discovered APITable yet! I have a very specific requirement (app where I want a few views to be collaborative spreadsheets and the rest more freeform html based pages reading from the same tables) and so far none of the popular projects has been quite suitable. (basetool might have but it's dead :()
We agree! The UI can be really helpful to make quick changes to schema, data, etc. You can’t run the UI without a Retool account though. We have a self-hosted Retool that works with your own Postgres database that you connect to Retool. Docs here: https://docs.retool.com/docs/retool-database-self-hosted
async (the keyword) is doing fantastic because it’s better than all of the available alternatives. Those alternatives:
- ad hoc callbacks, which had a great Result-ish type signature but really do warrant the “hell” in “callback hell”
- Promise APIs, which are semantically equivalent to async the keyword, unless you care about call stacks, and have a lot of the same hellish problems as the ad hoc callbacks they were meant to address (less nesting! same everything else!)
- Um fibers? Good luck making sense out of whatever that’s doing. It’s a good idea, but it’s also all opaque magic when you try using it.
- Actual threads and child processes… there are valid use cases, and they’re worth pursuing if you have a valid use case, but the facilities for development with them are basically “here’s a bunch of low level concepts that closely mirror their system level counterparts, hope you know/figure out what you’re doing!”
By async I was referring to node's asynchronous event-driven runtime abstraction which the GP refers to as an ugly hack. I'm not sure if this abstraction is better than all of the available alternatives if you compare it to high-level features multi-threaded runtimes offer like thread-safe collections, atomic updates, concurrent hash maps, immutability, structured concurrency, etc... as in Java/Clojure. Most Java programmers don't work with the low-level thread primitives.
The author of esbuild gave up trying to code esbuild with nodejs/worker threads and switched to Go for a less limited/restricted concurrency environment.
> By async I was referring to node's asynchronous event-driven runtime abstraction which the GP refers to as an ugly hack.
Okay with that clarification I can agree it’s a good model, given its constraints. The event loop with async IO in the abstract is a good way to model a single process/thread workload for many use cases that fit it.
> I'm not sure if this abstraction is better than all of the available alternatives if you compare it to high-level features multi-threaded runtimes offer like thread-safe collections, atomic updates, concurrent hash maps, immutability, structured concurrency, etc... as in Java/Clojure.
Clojure’s solution to concurrency is a breath of fresh air, regardless of your execution environment, because its state transactional semantics are great whether your concurrency is in one process/thread or spread across many. I can’t speak to typical Java solutions, but my general sense is they’re higher level and more powerful than Node’s for actually crossing process/thread boundaries, but subject to most of the shared state problems Java has even in a single process/thread.
> The author of esbuild gave up trying to code esbuild with nodejs/worker threads and switched to Go for a less limited/restricted concurrency environment.
After a lot of exploration of Node worker threads, I’d probably similarly look elsewhere if I had a workload suited to it. You can do a lot with Node worker threads with a lot of special tuning for a use case, and I even have some proof of concept code demonstrating that it can be much better than common usage. But I put it on hold because the complexity of making it perform well is very high compared to optimizing the single thread default.
You can buy this combo for $450, maybe for $400, but I don't see how you can get it for $300. The processor alone seems to go for >$240, and I don't see how you can hope to get a compatible motherboard for <$60.
Solution 1: You can give a classname to your component and prefix every CSS rule with this classname. e.g. <CustomSelect>, which translates to <div className="custom-select">, which you can style by prefixing every rule with .custom-select. You put that in the index.css inside your folder CustomSelect to be easily editable when you need it.
Solution 2: Otherwise you could try to use CSS modules (Vite supports them out-of-the-box I think).
Solution 3: Otherwise you could try one of the many "CSS-in-JS" libraries like styled-components.
Personally I'm using the solution 1, did for more than a decade, works fine, scales well, nothing to install and learn, just old straightforward CSS.
In practice, I find keeping your CSS separate from the JSX tends to be cleanest (your solution 1).
Separation of concerns with what are essentially totally different markup languages is best when you can. We tolerate it with JSX because there isn't a fantastic first-class declarative way to express an object, a list of objects, or filtering in HTML. (I have seen WebComponents and the MDN tutorial seemed like taking a step back.)
There was a specific feature in the .Net Framework version of EF called “database first” that would analyze your existing database and generate an xml file describing it that EF would use to generate models on the fly. It was pretty horrible and thankfully isn’t supported by modern EF Core. However the term database first stuck and it’s really come to refer to any any scenario where you manage your database using a tool other than Entity Framework migrations. Could be a dedicated migration tool, Sql Server database project, whatever. Then you either create EF models to match the tables or use a tool to generate them.
