lewisl9029

I got this one from Acer's Ebay for $220: https://www.ebay.com/itm/266390922629

It's out of stock now unfortunately, but it does seem to pop up again from time to time according to Slickdeals: https://slickdeals.net/newsearch.php?q=a770&pp=20&sort=newes...

I would probably just watch the listing and/or set up a deal alert on Slickdeals and wait. If you're in a hurry though, you can probably find a used one on Ebay for not too much more.

This article is coming out at an interesting time for me.

We probably have different definitions for "budget", but I just ordered a super janky eGPU setup for my very dated 8th gen Intel NUC, with a m2->pcie adapter, a PSU, and a refurb Intel A770 for about 350 all-in, not bad considering that's about the cost of a proper Thunderbolt eGPU enclosure alone.

The overall idea: A770 seems like a really good budget LLM GPU since it has more memory (16GB) and more memory bandwidth (512GB/s) than a 4070, but costs a tiny fraction. The m2-pcie adapter should give it a bit more bandwidth to the rest of the system than Thunderbolt as well, so hopefully it'll make for a decent gaming experience too.

If the eGPU part of the setup doesn't work out for some reason, I'll probably just bite the bullet and order the rest of the PC for a couple hundred more, and return the m2-pcie adapter (I got it off of Amazon instead of Aliexpress specifically so I could do this), looking to end up somewhere around 600 bux total. I think that's probably a more reasonable price of entry for something like this for most people.

Curious if anyone else has experience with the A770 for LLM? Been looking at Intel's https://github.com/intel/ipex-llm project and it looked pretty promising, that's what made me pull the trigger in the end. Am I making a huge mistake?

I had a somewhat similar experience trying to use LLMs to do OCR.

All the models I've tried (Sonnet 3.5, GPT 4o, Llama 3.2, Qwen2 VL) have been pretty good at extracting text, but they failed miserably at finding bounding boxes, usually just making up random coordinates. I thought this might have been due to internal resizing of images so tried to get them to use relative % based coordinates, but no luck there either.

Eventually gave up and went back to good old PP-OCR models (are these still state of the art? would love to try out some better ones). The actual extraction feels a bit less accurate than the best LLMs, but bounding box detection is pretty much spot on all the time, and it's literally several orders of magnitude more efficient in terms of memory and overall energy use.

My conclusion was that current gen models still just aren't capable enough yet, but I can't help but feel like I might be missing something. How the heck did Anthropic and OpenAI manage to build computer use if their models can't give them accurate coordinates of objects in screenshots?

Congrats on the launch! :)

Apparently I signed up for Instant previously but completely forgot about it. Only realized I had an account when I went to the dashboard to find myself still logged in. I dug up the sign up email and apparently I signed up back in 2022, so some kind of default invalidation period on your auth tokens would definitely make me a bit more comfortable.

Regardless, I'm still as excited about the idea of a client-side, offline-first, realtime syncing db as ever, especially now that the space has really been picking up steam with new entrants showing up every few weeks.

One thing I was curious about is how well the system currently supports users with multiple emails? GitHub popularized this pattern, and these days it's pretty much table stakes in the dev tools space to be able to sign in once and use the same account across personal accounts and orgs associated with different emails.

Looking at the docs I'm getting the sense that there might be an assumption of 1 email per user in the user model currently. Is that correct? If so, any plans to evolve the model to become more flexible?

This is the only real problem I have with how they handled the situation. But it's a big problem.

Whether or not these folks on free plans are ever going to convert to paid, they trusted PlanetScale to serve as a critical building block for their project/business. I think the least they could do is ease the transition by offering them a reasonable amount of time to offboard.

I personally would never trust critical infra to a company that has ever abruptly terminated a product offering with only 1 month notice.

Have been looking forward to this release for quite a while! Huge props to the Cloudflare team for putting this out there!

I've been operating a cluster of NGINX nodes on Fly.io and using njs (NGINX's custom JS scripting engine) for all of my custom routing logic, and have been really feeling the limitations (had to spin up a separate companion app in nodejs to work around some of these). Having access to the entirety of the Rust language and ecosystem to customize routing behavior sounds incredibly compelling!

I did a quick scan over the codebase and couldn't see anything around disk caching like in NGINX, only memory caching. Curious if Cloudflare is operating all their production nodes with memory caching as opposed to disk caching at the moment?

I'd love to see an option for disk caching for use cases that are a bit more cost sensitive.

It's been a while, but last time I checked, write latency on R2 was pretty horrendous. Close to 1s compared to S3's <100ms, tested from my laptop in SF. Wouldn't be surprised if they made progress on this front, but definitely do dig deeper if your workload is sensitive to write latency.

Another (that probably contributes directly to the write latency issues) is region selection and replication. S3 just offers a ton more control here. I have a bunch of S3 buckets replicating async across regions around the world to enable fast writes everywhere (my use case can tolerate eventual consistency here). R2 still seems very light on region selection and replication options. Kinda disappointed since they're supposed to be _the_ edge company.

Vertical tabs in Edge seems to trigger false positives on this. Really hope that's not the only heuristic they're using.

Great list!

Related to your point on supporting 0-transpilation workflows as a first class citizen, is the fact that Flow was explicitly just type annotations & checking, and aimed to introduce 0 runtime constructs.

This is something Flow did from the beginning and TypeScript eventually established as a non-goal after already implementing several runtime constructs that they can no longer afford to remove for backwards compat [1].

Though interestingly enough, Flow themselves recently announced they're going to start introducing runtime constructs, which is an interesting plot twist [2].

[1] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

[2] https://medium.com/flow-type/clarity-on-flows-direction-and-...

In case you're open to something for JS instead of Python, my life has been much better since I switched from AHK to nutjs for my own automation scripts: https://nutjs.dev/

A real programming language, and support for multiple platforms!

Wow, and here I thought I was the only one to make this move from Firefox to Edge, precisely because of the excellent native vertical tabs functionality.

It's not perfect, but the level of UX polish and the first-class integration with other browser features is unmatched by any Firefox vertical tabs extension I've tried.

I still can't believe the other browsers haven't caught on to the fact that power users want vertical tabs and are willing to switch browsers for it after so many years of Firefox extensions showing the way...

Hi HN, author here. Happy to answer any questions about the post or Reflame. :)

Reflame's Show HN from a while back has a lot more technical details about how Reflame works under the hood if you're interested: https://news.ycombinator.com/item?id=33134059

Interestingly enough, the topic of the post is something I mentioned in this reply as the "achilles heel" of our instant deployment story: https://news.ycombinator.com/item?id=33135153

Much more work to be done, but I can now sleep a bit better knowing this one has been knocked off the bucket list.

Thank you for taking the time to respond! All very fair points.

The post was definitely written as a content marketing piece for Reflame, but I did also write it with the genuine intent to give an apples-to-apples comparison between the current popular deployment services in use by most people today, that could be useful even for someone who's completely disinterested in ever using Reflame (you're totally right that comparing Reflame to the others is apples-to-oranges, and I honestly did try to disemphasize those kinds of comparisons in the discussions). Hopefully that was true for you as well, but I apologize if the self-promotion was too in-your-face. Will try to do better next time.

Re: scale. Reflame is definitely playing on easy mode at the moment since the deployment service is sitting idle most of the time, and ready to process requests at a moment's notice. The real test will be when we have enough traffic to start saturating compute on individual nodes and require more sophisticated routing and scheduling.

That said, Reflame's intrinsic advantage is that individual deploys are fast and efficient enough that it's feasible to pool them onto a small handful of simple multitenant web servers sharing memory/compute without significantly impacting user experience, rather than requiring each deploy to spin up a new VM/container in a gigantic fleet using dedicated compute and over-provisioned memory. So I'm bullish on our longer term scaling prospects here.

Re: instant. I've definitely been making a conscious effort to avoid the term, but looks like I wasn't successful in that very prominent instance. That's embarrasing, appreciate you catching that. That said, I don't think my use of it is necessarily hypocritical since Reflame deploys fast enough to qualify as truly instant in a fairly rigorous definition of the word as seen in the results of the article.

Hi HN, author here. I set out to do a casual comparison of deploy speeds between Reflame (disclaimer, I built Reflame) and other popular services on a near-stock Vite React app, not expecting a whole lot of differences between the others (since most of them were just spinning up VMs/Containers and running the same CLI tools).

I ended up finding out that Netlify had some rather long queuing times that made it ~10s slower than the duration it reports, putting it well behind Vercel (which reports similar a similar duration), but still ahead of Cloudflare Pages (which suffers due to doing a bunch of things irrelevant to the simple Vite app I was deploying).

Meanwhile, Reflame consistently finishes deploying before I can even finish creating the PR. :)

If this piqued your interest for Reflame, I have a demo on https://reflame.app, and more technical details on my Show HN launch post (https://news.ycombinator.com/item?id=33134059). Give it a shot if you're building a client-rendered React web app, and tired of waiting for minute-long deploys that break your flow every time you want to share your work. :)

Developers know much more than other professions about how much SaaS products cost to run in terms of infra (i.e. very little for most products), so are much more likely to anchor on infra costs when considering whether a price is reasonable during purchasing decision than basically any other group.

Most SaaS are priced completely independently of infra costs (or any other costs really), but we are much less likely to accept products priced with high margins on top of obviously low infra costs, even though that doesn't represent nearly the full cost of running a SaaS (which consists mostly of payroll due to how high our salaries typically are haha...).

We also like to justify this line of thinking by the argument that "well, I can build this myself in an afternoon" (significantly underestimating the real ongoing time investment required to build and maintain a SaaS product, even seemingly trivial ones) or "I can write some bash scripts and put this on the VPS that I'm already running anyways" (undervaluing our own time).

Competition for developer tooling products is _fierce_, possibly more so than any other industry, precisely because we really seem to love spending our free time building slightly different versions of the tools we use that suit our preferences better, sometimes before we even try to Google if that slightly different version already exists.

Again, I'm totally guilty of this myself, since Reflame started as a side project initially to scratch my own itch, and I can't claim to have done an exhaustive search on the problem space before I started.

This results in a vicious cycle where every product, however innovative it might be at its inception, gets quickly commoditized by dozens of similar products immediately following any signs of traction, so they end up having to shift to competing on price eventually.

Combined with https://news.ycombinator.com/item?id=33691132 means any product that isn't available for free then eventually rots into obscurity due to the unfair distribution advantage of "free" in this market. Thus they are forced to offer a free version themselves and the cycle continues.

We get so many developer tooling products thrown at us, either for free or dirt cheap, that over the decades it's conditioned us to assign much less monetary value to developer tooling products compared to what a simple opportunity cost analysis would yield, given the high monetary value of our time.

I certainly suffered from this myself to a rather extreme degree in the past, having categorically refused to pay a single cent for anything I used to build side projects with, until I started to seriously think about pricing for my own product. Eventually I realized throwing money at almost any problem where it could buy me more free time should be a no-brainer considering how highly I value my free time.

Tangentially, I think there's an interesting analogue in here to what Steam did in the PC games market, but I digress...

Seeing a lot of comments trying to dispute the claim that "individual developers do not pay for tools". The claim does invite these kinds of disputes since it's so absolutist, but I do believe there is some truth to it, at least if we take it as a generalization (rather than a literal statement).

Anyone who's either worked at a developer tooling company or tried to sell to developers themselves (I personally did both, having worked at CircleCI in the past and now building my own developer tooling product at https://reflame.app, Show HN launch thread here: https://news.ycombinator.com/item?id=33134059) can probably back the observation that we individual developers are notoriously reluctant to open our wallets, even for products that we love and use daily, despite our high disposable income relative to professionals in other markets.

Gonna share a few of my own hypotheses for some of the contributing factors as comments below for discussion.

Would be fun to see folks share their own! Especially if you've seen successful strategies for how someone might be able to overcome these hurdles to selling products to individual developers at scale (a topic near and dear to my heart these days)!

Agreed, this is awesome! I've been using Cloudflare Tunnel for local dev, but the fact that it seems to be coupled to their CDN product with no way to permanently turn off the CDN functionality has caused quite a few headaches lately (though it's possible to turn off temporarily using "Development Mode").

Would love to give this a try, though from the post it's not clear if we could use our own custom domains instead of the provided ts.net ones? This is a necessity for my use case where I need to be able to handle wildcard subdomains.

Posted another more thorough update on the blog post: https://blog.reflame.app/i-compared-deploy-speeds-for-reflam...

Twitter thread for summary: https://twitter.com/lewisl9029/status/1592341968780001280

Update: Matt Kane on Twitter (https://twitter.com/ascorbic/status/1591728244323389440) replied to my thread explaining that:

1) Part of the issue here is my Netlify account having branch builds enabled, which resulted in two builds running for every commit. This resulted in longer queue times with a concurrency level of 1, which would explain about ~20s of the queuing time seen here to run a branch build of similar length.

2) The other part is Netlify's previews run on PR creation, not on every commit like on all the other services tested here. This explains another ~5s of delay between creating the branch and opening the PR.

That unfortunately still leaves ~30s of the total ~55s of queuing time above unaccounted for. Initial tests with branch builds turned off show results that are much more competitive, but it was performed on 4AM on a Sunday, so I can't conclusively rule out additional queuing delays during busier hours yet. Will be investigating further during PDT business hours. Stay tuned for another update!

Hi HN, author here. I set out to do a casual comparison of deploy speeds between Reflame and other popular services, not expecting a whole lot of differences between the others (since most of them were just spinning up VMs/Containers and running the same CLI tools).

I ended up finding out that Netlify had some _really_ long queuing times that made it 50s+ slower than it needed to be (and made it fall wayyy behind the others). This queuing was fairly consistent on weekdays, and I've tested dozens of times over the past few weeks with similar results.

Until they do something about this I'd recommend looking into one of the others tested here if you care about deployment speed: i.e. Vercel if you want something popular and works as a drop in replacement, Reflame if you want to never wait for a deploy ever again, even for a second, and don't mind doing putting in some upfront work (I'll be around to help you through the process ofc). :)

I also made a Twitter thread here if you want an abridged version: https://twitter.com/lewisl9029/status/1591530406909997056

Agree completely. It also makes interop between Node and Deno more painful. But there is hope on the horizon. :)

See https://github.com/microsoft/TypeScript/issues/37582 which is referenced in the 4.9 Iteration Plan as "Support .ts as a Module Specifier for Bundler/Loader Scenarios": https://github.com/microsoft/TypeScript/issues/50457

Curious to hear from people out there using Next.js, but without _any_ SSR, i.e. using the `next export` command mentioned in the article: https://nextjs.org/docs/advanced-features/static-html-export

(Seems like the folks in the article are beginning to use SSR, and have some great use cases with publicly available, SEO-friendly content, but a lot of apps don't, and can benefit from avoiding the operational complexity.)

Create React App is a bit long in the tooth these days, so I can imagine `next export` being a lot nicer to work with in a whole bunch of ways, but the only advantage of `next export` I can think of over something more modern like Vite is file-system routing.

For those using `next export` but have also evaluated Vite, is FS routing what made you choose `next export`? Or is it something else?

Disclaimer: Asking with ulterior motives. I'm building https://reflame.app, a Vercel competitor focused on client-rendered React apps, with millisecond deploy times to previews and production. We currently have decent compatibility with Vite and CRA, but considering if we should try to add support for apps using `next export` as well.

So if a user has the VSCode extension installed, we'd actually install them even earlier than a commit hook could, since we'd install packages as soon as they save the config file. :)

Really appreciate you taking the time to write this super thoughtful comment! There's definitely a lot of valuable feedback/advice for me to take away here.

Re: supporting new build systems. You're totally right that it's a lot of work, with tons of potential edge cases to cover. In my ideal world people would just use the dev workflow provided by Reflame out of the box, and not bother with Vite/CRA/anything else, and everything would be easy. But in the real world I do need to meet potential customers half way and make the product as easy and low risk as possible for them to adopt, and supporting existing local dev toolchains is a crucial part of that effort.

Luckily though, I think supporting just CRA and Vite-based React apps is enough for me to capture a good 50% of the kinds of apps I'm looking to target, and I don't have plans in the short term to add support for anything else without strong demand from customers.

Re: monetization, this is definitely still the big question mark hanging over my head and keeping me awake at night. Pretty much everybody I show Reflame to seem super excited about the idea of previewing and shipping instantly, but only a very tiny fraction of those people have actually ended up giving me their credit card.

I did end up getting quite a few more new users to talk to with this launch though, so I'm looking forward to chatting with them to figure out whether they are willing to pay for instant deployments, and if so, how much, and if not, what's missing.

It's going to take a while, but I'm personally convinced that engineers having to wait minutes to deploy is a valuable problem worth solving (companies are already spending tons of money, both on SaaS and entire teams of engineers just to _keep_ it in single/low-double digit minutes in the first place, after all), and can be turned into a great business. And even if I turn out to be wrong, at the end of the day, I've been building the deployment platform of my dreams that I always wanted to use, that I can continue to use to build new products going forward even if nobody else does. I don't think I'd ever regret a single moment spent doing that (in fact I've been deeply regretting not having started on it sooner).

Re: Bun. I'm a huge fan of Jarred and Bun too! Have been following his progress for quite a while, and it's been an amazing source of learning and inspiration, even though we're solving very orthogonal problems.

Re: same domain vs subdomain previews. Appreciate the feedback! I'm not dogmatic at all on _only_ having same-domain previews. But it was important for me to have it available as an option at the start, because I think it is valuable to have in many circumstances, even if not as a default. And I at least wanted to experiment with having it as a default, because at least in theory, more production parity should offer us more confidence, still TBD on how that works out in practice. Adding subdomain based previews will certainly be on the table if I get enough similar feedback. Should actually be a lot more straightforward to implement since I already have most of the pieces in place.

Ah got it. Yep SSR is definitely not something Reflame can support for now.

I do hope to figure something out for backend development eventually though, since I'm actually constantly feeling the pain of lacking a similar feedback loop for backend dev (Reflame is actually 90%+ backend by LOC and time spent haha...).

Thank you so much for the kind words!

Mind me asking what you're using to deploy web apps today? And what you feel Reflame is missing? Wanted to make sure I get those on my roadmap. :)

So JS has this really nice property where things really can be just deployed as independent modules, and they will just work together without any cross-module compilation or analysis needed. It's a big part of what makes Reflame's approach possible.

That said, Reflame does actually perform dependency analysis on the entire module graph, persists it, and then updates it in response to every change. We're mostly doing this for optimizations like preloading only modules reachable from the entry point to flatten the network waterfall, but we also use it to provide nice error messaging as well. Here's a quick PR showing the dependency analysis in action: https://github.com/reflame/example-typescript/pull/2

We do this by doing analysis on each module as they come in to generate metadata on what modules they depend on, so subsequent modules can build up the dependency graph using just that metadata for each module, without having to have download the full code or analyze them again.

Haha thanks, yep, that actually took quite a few takes to record, but couldn't help but smirk on every one. :)