I wonder if it will do any better than past versions when one begs and pleads for it to get a job done using a concise, modest amount of code (as an expert human developer might), rather than responding to all prompts by shoveling in a large amount of code.
For years we've been seeing the hype about how axial flux electric motors will save 100 or even a couple of hundred pounds per car. Does this announcement mean we're finally starting to see the first increment of that actually happening?
(The motor is less important than the battery in terms of total weight, long term durability, etc. But nonetheless, any improvement helps!)
I remember thinking that they were making great software, but finding revenue to make the investment payoff could be quite challenging. Looks like that's been solved.
Very clever to mention Bun in the title here - probably increases the clicks notably.
(We have a couple apps that use BullMQ, and I keep wondering if we could drop Redis and use a PG-backed queue instead, for fewer single points of failure. Maybe this is the one.)
We have an app on Heroku and obviously the writing is on the wall there. We looked around a bit and picked Digital Ocean as our next host:
* their app hosting product is similar to Heroku.
* very easy onboarding and controls for modest complexity apps. Unlike the extreme hoop-jumping required to do anything on one of the major cloud providers.
* everything looks reasonably up to date.
* it's an actual operating profitable company that's been around a while and probably will be for a long time... not a startup burning capital.
That said, this magic containers thing looks more analogous to Google Cloud Run, which I think is an absolutely fantastic offering. Unlike almost everything else out there, Cloud Run and presumably Magic Containers can do things like have a whole bunch of versions of your app up and running ready to come to life when a request arrives, but scaled to zero in the meantime. This category of hosting should be far more popular than it is, and it is wonderful to see another company offer it.
"Verifying age undermines everyone's data protection"
That's the whole point, right? A pretense to remove any remaining anonymity from communications?
Governments are endlessly infested with the worst people. They look back at historical attempts at totalitarianism and think to themselves, "Let's facilitate something like that, but worse".
That seems like a good bit of psychology as it accommodates both people with the mental fortitude to type in their genuine max bid in the first place, and also people who don't really know what they're willing to bid until they see somebody else bid higher.
Auction site design where most every transaction is a very material amount of money for buyer and seller probably have different trade-offs from something like eBay where most items are rounding errors compared to the income or wealth of the participants.
For example, think about "sniping" from the seller side. Sellers are rightly concerned about any wrinkle of the bidding process that might leave money on the table. Automatically extending the time so that every potential buyer has time to "answer" a new bid soothes the concern that buyers were willing to pay higher, but they didn't have the technological prowess to post their bid in the last 0.3 seconds.
Obviously anybody can post gross things by running an image generation/editing tool locally and publishing the results. People then mostly blame the poster whose name it then appears under.
Seems like a pointless and foolish product design error for X/grok to publish arbitrary image generation results under its own name. How could you expect that to go anything but poorly?
These tools always fall short, not because the teams making them are bad, but because the underlying chat tools they build on are adversarial to the idea of a third-party UI replacing their UI. A new entrant might escape their ire for a while, of course.
Sure, you can have your LLM code with any JavaScript framework you want, as long as you don't mind it randomly dropping React code and React-isms in the middle of your app.
c appears to be the speed limit of the propagation of information in the universe - never say never, but so far it appears quite unlikely any new physics will overturn this.
I'm always thrilled to see eCharts mentioned anywhere. It is a highly featureful, complete solution for making sophisticated data-intense charts. Various commercial alternatives pale in comparison.
Likely so, but you have probably listed a bunch of organizations already utterly swamped with eager and qualified job candidates relative to their hiring numbers.
Historically, the way to standardize how a component appears with Tailwind is to use component abstraction in whatever tool you are building with to accomplish that. Define a button once somewhere and then throw on whatever classes it needs.
If you were copy-pasting long strings of Tailwind classes all over, you were already doing it wrong before you even heard of Daisy.
A challenge with TSX, and as I understand other similar tools, is that it doesn't support TypeScript decorator metadata. A few years ago, libraries using that started to get popular, so many older projects have a significant obstacle to moving away from running the TypeScript compiler JS output.
Starting a new project today, I think the right move is to use TSX or Bun or whatever. You want a roadblock at the very first moment you start trying one of these limited compatibility libraries, Because it won't work and then you'll pick a different library that doesn't rely on non-erasable TypeScript syntax.
Seems like insurers should be rating based on your worst health markers, including weight, over the last N years rather than just a current point-in-time snapshot. Someone who somehow has no medical records over the last few years at all that would capture any of that data would be priced on the assumption the past was possibly worse than current.
https://kylecordes.com
kyle at kylecordes dot com