Thats just… weird? Why would you want to use somebody else’s fridge? Like I get its a few hundred dollars but they last decades. The Samsung fridge I still have was the very first appliance I ever purchased when I moved out at 18. Added to the fact that basically no free-standing appliances are included with rentals here, other than clothes dryers which I also hate and swap for my own.
We just bought a new fridge yesterday. We lugged our old one around between 5 different properties - 20 years old, still going strong.
The big problem is that fridges are not a standard size, and hence the spaces in kitchens are not a standard size. So there's a good chance when you move it won't fit (ours only worked because it's so small - which also made moving it not too onerous). It's a much better result for everyone if the apartment/house has a fridge that perfectly fits the space.
Also:
>Why would you want to use somebody else’s fridge?
This is a weird question. You're ok with using "someone else's" apartment, someone else's toilet even. But you draw the line at a fridge?
I've not rented in LA county, but everywhere I've rented and the three houses I've bought all came with a fridge. They're large and awkward to move, and they typically last a long time. Why would I want to move one?
Might be nice to have a new one with no one else's mess, but they do clean up pretty fully when you take out all the shelves.
Why would you ever want the hassle of moving a refrigerator around if you’re only going to be somewhere for a couple of years? Not to mention the potential damage to the apartment you can accidentally cause by moving such a large appliance around.
>Thats just… weird? Why would you want to use somebody else’s fridge? Like I get its a few hundred dollars but they last decades.
Citation needed on the longevity of new/fancy refrigerators past warranty. Heard too many horror stories. Even our basic LG had a recall on the compressor that we thankfully weren't affected by (yet) and has an issue with the gaskets not sealing very well all the time.
Alas, it's one of the few models that will fit into our tight space and still give us enough space (it has the handles built into the door, rather than sticking out another ~2 inches).
My experience with eSIM has so far been quite negative. I’ve upgraded phone twice since being forced to use one by my carrier and it’s been a pain both times. The initial setup of scanning a QR code was nice, why is every subsequent SIM change a 10 step dance in an app (or worse a support call) rather than one phone showing the QR and the other scanning it?
Once this phone needs updating, I’ll be swapping carrier to one that has regular SIM cards.
This reads like more overworked salaried employees mentally justifying spending their own time on work. Once you start setting the expectation that you’ll spend your own time doing work that couldn’t be finished during the week, that’s what your employer is going to expect. And may also expect of your colleagues. I’m sure they’ll appreciate that…
Personally, I log off at 5pm friday and don’t think about anything work related until after at least one coffee somewhere in the vicinity of 9am the next monday.
Rather than improving testing for fallible accessibility assists, why not leverage AI to eliminate the need for them? An agent on your device can interpret the same page a sighted or otherwise unimpaired person would giving you as a disabled user the same experience they would have. Why would that not be preferable? It also puts you in control of how you want that agent to interpret pages.
I'm optimistic that modern AI will lead to future improvements in accessibility tech, but for the moment I want to meet existing screenreader users where they are and ensure the products I build are as widely accessible as possible.
It adds loads of latency for one. If you watch someone who is a competent screen reader user you'll notice they have the speech rate set very high, to you it'll be hard to understand anything. Adding an LLM in the middle of this will add, at least, hundreds of milliseconds of latency to interactions.
The golden rule of LLMs is that they can make mistakes and you need to check their work. You're describing a situation where the intended user cannot check the LLM output for mistakes. That violates a safety constraint and is not a good use case for LLMs.
I, myself, as a singular blind person, would absolutely love this. But we ain't there yet. On-device AI isn't finetuned for this, and neither Apple nor Google have shown indications of working on this in release software, so I'm sure we're a good 3 years away from the first version of this.
While not a complete rebuttal, allow me the following. I manage a team of 4 scrum masters each with 5-6 engineers. We provide services via a user interface we'll call the console, as would be fairly familiar to any B2B or B2C service provider. The backends of this portal are split up by functional area, so we have a compute management service providing CRUD apis for dealing with our compute offerings, a storage service for CRUD on our storage offerings, a network service for interacting with networks etc. all sharing a single, albeit sharded, underlying data store.
My teams pick up a piece of work, check out the code, run the equivalent of docker compose up, and build their feature. They commit to git, merge to dev, then to main, and it runs through a pipeline to deploy. We do this multiple times a day. Doing that with a large monolith that combines all these endpoints into one app wouldn't be hard, but it adds no benefits, and the overhead that now we have 4 teams frequently working on the same code and needing to rebase and pull in change, rather than driving simple atomic changes. Each service gets packaged as a container and deployed to ECS fargate, on a couple of EC2 instances that are realistically a bit oversubscribed if all the containers suddenly got hammered, but 90% of the time they don't, so its incredibly cost effective.
When I see the frequent discussions around microservices, I always want to comment that if you have a disfunctional org, no architecture will save you, and if you have a functional org, basically any architecture is fine, but for my cases, I find that miniservices if you will, domain driven and sharing a persistence layer, is often a good way to go for a couple of small teams.
> we have 4 teams frequently working on the same code and needing to rebase and pull in change, rather than driving simple atomic changes.
You have to pull in changes either way. Either there are contract changes between teams or there aren't. If there aren't, you don't need to rebase just do squash and merge. If there are, then you're going to either find out about the changes now or you're going to find out about them in production when your container starts throwing errors.
Just as I’m sure producers would love Australia to stop labelling produce for use of hormones and pesticides. But in both cases, there is a consumer interest in buying high quality products free of polluting elements, and in many cases, supporting actual humans doing work.
He seems to be intentionally missing the point of most of the complaints in order to direct away from his core area. The many legitimate criticisms of windows poor user experience lately will eventually drive change, but long will that take?
Not to mention, I can find AI perfectly impressive and still have absolutely no day-to-day use for it… certainly not enough to justify it taking over my operating system experience.
Heck, I Do have day-to-day use for it, and I still don't want it to completely take over how I use and interact with my OS.
Nor do I ever want to have a voice conversation with my computer to where it responds in an uncanny valley voice. If I do want to use voice, it's to give a command. No response needed. "Hey computer, call John" that's it. Do the thing, don't talk back. A glorified voice assistant is all the further it needs to go.
Possibly too little too late. Even my uninterested family and friends are moving over to MacBooks just due to not enjoying windows 11 or not wanting to upgrade hardware to get a minor OS change. Between that and valve looking to move on the casual / console gaming space with the new steam hardware and devs already being split between macs and linux, they’re going to have a hard time coming back if they fumble this for much longer.
I have yet to reach the limits of doing a Vite create and installing react router myself for the several entirely client side apps we manage. It has sane build defaults and for whatever definition of ‘works’ is possible in JS, ‘just works’. If it becomes too complex for that basic setup it usually means we’ve over-complicated something.
Where we have a need for server side, nodejs just never felt natural for us so we stuck with java springboot or flask/fastapi as appropriate.
I'd love to hear more about what motivated the switch. All the additions to react-router are, afaict, opt-in. React-router has 3 "modes"[0] and the declarative mode seems pretty much exactly what the classic library is like with some extra components/features you don't have to use
Thought I've enjoyed the code-splitting and access to SPA/SSR/SSG/etc strategies that come with the "framework" mode
I'm using the React Router v7 in framework mode, fetching data directly from the database in server-side components. So far, it works reasonably well as long as we avoid mixing server code with client components. However, although it offers the convenience of writing frontend and backend code together, the mental burden added by this approach makes me feel it is not worth it more and more often.
I’ve been using Wouter on multiple medium sized projects for 3-4 years now. I’m never going back to react-router if I can avoid it: a hellhole of API churn and self promotion
Dang, looks like wouter does the same thing as react router v6+ and nested routes don't get all params / paths of the route. ~~Also doesn't have react router v5's route-string typescript parsing.~~
> Also doesn't have react router v5's route-string typescript parsing.
It does, assuming you're talking about automatically parsing "/foo/:id" and getting a typed "{ id: string? }" route params object out of it? Wouter does that when using typescript.
Yep! That's the type. It used to be a lot more complicated if I remember correctly, but looks like the author is importing a type from that "regexparam" package to do it now.
I’m kind of agreed on this but — many times now I’ve also wanted static site components in my app too, and in a standard express+react app that gets awkward.
I think there must be a better way. I don’t think it’s next.js and I’m not convinced it’s Astro either. There’s still room for new ideas here, surprisingly
I had a play with this and you’re right, it does have a style, but first: this is awesome, and good fun, well done!
I think the system prompt or training data probably focuses on marketing websites, it didnt manage to make a settings page or a canvas game, but did make a site telling me how to make a canvas game :)
How does it interpolate the path to make the prompt? (Havent checked the code yet…)
Interpolation happens in two steps. First, there's a prompt for an outline (below). Then, a prompt with the same construction rules but says like "given the outline..." and puts the outline into the context.
You are a professional web designer. Create a concise outline in markdown format of a site for the topic "{{slug}}".
Construction rules:
- Do **not** reference any external resources (fonts, CDNs, embeds, etc.).
- No JavaScript or SVG.
- All images must be JPG.
- All <img> tags must have a width and height.
- In CSS any image use must include object-fit: cover.
- All links must be relative to the root and be a long, descriptive slug of the content (like company-owner-with-hat.jpg
or goat-facts-continued.html).
- The site must display well on both desktop and mobile devices.
- Never use position: sticky;
The outline should include the following sections:
- **Site Name And Paragraph Summary** - a short description of the site and its purpose
- **Style guide** – typography (built-in font classes only), spacing, imagery tone, theme
- **Color scheme** – primary, secondary, accent, neutrals (name + hex)
- **Layout** – grid/flex description, breakpoints, reusable components
- **Site map** – unordered list of important pages with slug filenames
- **Key features** – bullet list
- **Reusable CSS/HTML snippet** – fenced code blocks showing the skeleton for nav, hero, article, and footer
Write clearly enough that different teammates could each build a page and the finished site will remain cohesive and
on-brand.Make sure you capture the essence of the topic in the design, be creative!
reply