Unless I’m missing something this is exactly how eBay works. You set a max bid and then it auto bids up to that amount so you can’t get sniped unless they bid higher than your max.
Not that this is perfect either, often it means you can push other people’s bids up to their max even though you have no intention of buying the item. I’ve seen it as a seller and felt bad for the buyers
Yes, almost all online auction sites (or even offline absentee bidding) work this way. You set your maximum price and the auction house bids for you. However, in any case, bidding early gives other bidders information on how much you're willing to bid and allows them to nibble their way up to your max. So bidding late is always advantageous, even when you're setting a max bid.
I've never quite understood why people get so upset about sniping on eBay. Anybody can snipe. That's just the best play. Any time I want to bid on something on eBay, I just set my max bid on the sniping tool instead of on eBay, and then forget about it.
That's what I keep thinking about when I see those "once I started taking Claude, I lost 95% of my developement time" posts. Are they really making 20x the software, or are they and their customers simply believing that, watching all those endless streams of green checkmark and rocket emojis?
Good idea, but you're several years too late to the web3 market.
I know you're probably hoping for the non-crypto businesses to use it, but there's little incentive. The hiring company holds the cards when it comes to payments most of the time anyway – when you hire a remote worker, they often deliver 100% of the work before getting paid
Even in higher end contracts it's rare to find a company that is willing to pay a deposit.
We are looking for web3 natives who are using blockchain in their daily work and I think nowadays there are more than ever before. It's going to prove difficult without a strong marketing campaign though
To be fair, vite does a lot of the heavy lifting when it comes to supporting extra frameworks. If you look at the code required for astro to integrate with a new technology you'll see it's relatively straightforward.
On inter-island communication, I actually think less is more – I find a lot of the recent big features like this they have added unnecessarily constrain you to doing things a certain way, while the reason I liked Astro in the first place was the simplicity.
You can easily add any global store library to your project to communicate between islands from the very simple (nanostores) to more complex stuff (are people still using mobx, redux, etc?)
I actually would prefer if Astro kept the core more simple, I never understood the point of Astro components for example; always thought their game plan would be to build their own client-side framework like what remix v3 is doing, but currently their components are too limited to make them worth using over just doing everything in react, svelte, or whatever floats your boat.
Astro component is your page's entry point. It's similar to React server component. The typical flow is to fetch data in it, and pass the data to client component written in React or whatever. You can also have pages that are Astro only, without any front-end framework.
Yeah, I know, but since by default the front-end islands are server-rendered with no hydration the lines are blurred between what you would use an .astro component for, and just using for example react.
Personally I only ever use .astro components if I'm 100% sure I will never need any client side interactivity, otherwise it's just easier to ignore them.
I mean, you have to have an .astro file if you want your route to be picked up, and then import and use React components in that file. IIRC, you cannot just directly use React.
Oh right, yeah I get what you're saying now. Indeed I think .astro templates make sense at the page level say to define a layout, and I actually like the syntax of stuffing the server js into a frontmatter style block, it's pretty nice.
The key difference between islands and what we used to do back in the day (js on a static page) is that with an islands approach you architect your site with a components-driven approach where everything encapsulates the js/css/html it needs, then you mark it as an "interactive" island if you actually need client-side js to run – the code is the same, but it either runs only in the server (default) or in both server and client.
I know this sounds similar, but, compared to the more traditional approach, there is a certain simplicity to having everything just be javascript. You can often run the same libraries on both server and client depending on your needs, plus it fulfills the promise of web components in a way that is easier to work with (though WCs have also come a long way!)
I will also say encapsulating everything you just said in a single term, "islands," is a lot simpler and prettier to discuss. At least from my perspective, the naming also makes a lot of sense. Literal islands of interactivity surrounded by an ocean of static.
Islands is just a catchy name I guess. I always thought the markojs terms for it made sense, but are more technical / less catchy: they called it “full page hydration” -> everything needs to be delivered as js and “component level hydration” -> islands, only specific component sub-trees need to be hydrated.
Then “sub-component level hydration” would be resumability like in qwik where only events and their dependencies get serialised as client js.
Yeah. Well to their defense, it is probably to be understood as islands of interactivity lost in a sea of static elements.
The term is definitely more evocative.
You can do this with just about any programming language or scripting language that can render HTML on the server + plain HTML and JS. You could do this with PHP 30 years ago.
Yes and no, php didn’t give you any tools to manage this, most people writing php sites back in the day (including myself) were writing js that was coupled to a specific markup yet was maintained separately. This didn’t scale well.
Then along came libraries like mootools, knockout, etc all the precursors of react, then react changed the game around encapsulation of markup and code into one place, and straightforward data flow.
SPAs were inefficient so server side rendering of js became ubiquitous, islands are a further optimisation of ssr.
This hasn’t happened in a vacuum, if you look at modern php frameworks like inertia they have a lot more in common with Astro than they do the good old 90s php
Same reason vercel buys open source... it makes cloudflare always a great deployment option for all Astro sites, which in turn helps cloudflare's core business.
For example, Cloudflare released their vite plugin which makes it effortless for frameworks that use the vite env API to run inside workerd (meaning you get to use cloudflare service bindings in dev) back in April and only React Router had support for it. Nextjs has no support, the draft PR to add support for Sveltekit has been parked until the next major version, Astro only just added support in their beta 6.0 release 3 days ago
With this acquisition, Astro will probably be first to future updates that increase compatibility with cloudflare. It's smart, and was probably not very expensive (more of an acqui-hire)
So when folks say they want to see big companies invest in open source, this is what that looks like. CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
Well, hopefully more like Go's relationship with Google? The company that pays the bills is their first and most important customer, but as far as I can tell from the outside, the Go team makes its own plans and management doesn't pull rank.
> CF could have kept coasting on what Astro was building, but instead they are paying for it. But in return they get a lot of control.
Supabase pioneered the modern implementation of this model. Probably, RedHat before it? Google also tend to "acquihire" maintainers of popular FOSS projects, like Ben Goodger (Firefox), Scott Remnant (Upstart), Junio Hamano (Git), Guido von Rossum (Python).
So, cloudification: lock the customer into a complex cloud dependent solution they can't easily migrate to some other commodity infrastructure provider.
I essentially do a 1 click deployment for my personal site with Cloudflare.
I don't want to deal with the cloud infra for my personal site.
I could, I've done it in corporate, I've done it for my startup 2 years ago.
But I'm rusty, I don't know what the latest people are using for configuration, etc.
Because there is 1 click with CF or Vercel and I don't have to think about it—I don't.
If they increase their price it likely wouldn't be enough friction for me dust off the rust.
I think this is the relation.
I'm not locked in, it's just HTML pages, but I am through my own habit energy, tech changing, and what I want to put effort into, which is not infra and serving my site.
They can stay open source, but stop putting any effort into supporting deploying to cloudflare's competitors, including accepting PRs for such improvements.
Or they could add features that only work if you deploy via cloudflare.
I also take anything said in an acquisition announcement with a grain of salt. It is pretty common for companies to make changes they said they wouldn't a few years after an acquisition.
Vercel does not make Next.js hard to deploy elsewhere. Next.js runs fine on serverful platforms like Railway, Render, and Heroku. I have run a production Next.js SaaS on Railway for years with no issues.
What Vercel really did was make Next.js work well in serverless environments, which involves a lot of custom infrastructure [0]. Cloudflare wanted that same behavior on CF Workers, but Vercel never open-sourced how they do it, and that is not really their responsibility.
Next.js is not locked to Vercel. The friction shows up when trying to run it in a serverless model without building the same kind of platform Vercel has.
Can you describe what you mean here? Because I have heard this about 100 times and never understood what people mean when they say this. I am hosting a NextJS site without Vercel and I had no special consideration for it.
Did YOU even bother to look at their site? They support more than static generation, including SSR and even API endpoints. That means Astro has a server that can run server-side (or serverless) to do more than static site generation, so it's not just a static site generator either.
And yes I can see you're posting the same lie all over the comments here.
They can say whatever they want, and then do whatever they want. They have no contractual or legal obligation.
Almost every (it seems) acquisition begins with saying, 'nothing will change and the former management will stay on'. A year later, the former managment leaves and things change dramatically.
That's always been true. Perhaps even more so as Astro constantly faced an existential battle for a working business. Now they don't have to do that and Cloudflare makes their money on their infra business. Locking Astro up now or in the future gains them very little compared to how much they make with hosted upsell services. [edit: clarity]
It's a static site builder. It creates a static site. HTML, CSS, and JS. That you can then upload literally anywhere.
Once again, what lock in? There is literally nothing to lock in. Explain exactly how they are going to lock somebody in, moreso than the lazy "for now" which you seem to constantly repeat.
No? It's still the same Astro that you can move to any other provider that supports it - and it's just Javascript, so pretty much everyone supports it.
Yes, that's part of the problem, deploying nextjs to cloudflare in the first place used to be an absolute nightmare, let alone the dev experience (I think it's better now)
That doesn't sound too preposterous; I wouldn't assume you'd be able to run a React Router project on Turbopack or Webpack either, and Next.js I think has a way more intricate dependence on the bundler to power a significant chunk of its features.
Definitely irrational. There are lots of logical reasons to dislike Next (like the fact that they pile new shiny bit on top of new shiny bit without caring about the regular user experience) ... but being mad that it can't run on Vite is silly.
It's like being mad that Rails can't run on Python, or that React can't run on jQuery. Next already has its own build system, so of course it doesn't work with another build system.
Luckily DX is much better now with Turbopack as a bundler. First they improved the dev server, now with Turbo builds the production builds are faster as well. Still not fully stable in my opinion, but they will get there.
It's also wise to use monorepo orchestration with build caching like Turborepo.
They did well on the turbo stuff, no doubt about it.
The main bottleneck with big projects in my experience is Typescript. Looking forward to the Go rewrite. :)
I have a question. Why can't Whatsapp or Meta make a markdown INFO only website for small business owners (e.g. technicians, shopkeepers, handyman, etc) using their immense reach and clout. The method of using whatsapp groups to keep users updated of the latest updates is not scalable or open.
too big to deliver simple solutions? youre making way too much sense and this would die in committee or be replaced when someone new needs to justify themselves by launching a new product to supplant an existing one.
It does not read like marketing copy to me, what part of talking about draft PRs and framrworks sounds like marketing speak? They're right that CloudFlare having priority access to new Astro features is beneficial for them.
Not sure how to feel about this! I’ve been known to use em dashes every now and then, but I am indeed a fellow human.
I’m close to the vite plugin in particular and have contributed to multiple frameworks around cf integration (simply because I use cf), that’s why I chose it as an example (and it’s one of Astro 6’s biggest features)
This is cool, I use astro when I just want to spin up a quick site without having to fight the framework (looking at you, Nextjs) and the main thing I disliked was the initiatives around paid extras they had going
Astro and Tanstack are probably the best full-stack routers these days, and Astro wins in terms of the wide support for almost any client-side tech
This element has an autolocate attribute that will request permission automatically, plus it doesn't supersede the JS api, it simply provides a declarative alternative to it, so sites that follow this negative pattern will keep doing so.
At the same time, there is no reason to not implement this pattern today and require user intent prior to requesting the permission
According to the post, autolocate only does something after a user initiated permission has been granted.
So on the first vist you still need to click the button. On the second visit the callback will be triggered directly.
But, well, nothing prevents a big fat html modal on the page pointing to the button, now does it? If you want to annoy your product^H^H^H^H^H^H^Husers then you can always find ways to do so.
reply