tomlagier

> Why is it catching on? In the best light because it actually is a tremendous productivity accelerator. In the worst light, because we live in a world that incentivizes "fake it til you make it".

It's great at a few things and pretty good at a lot of things. In my view, the thing that it's the absolute best at is churning out low value, rarely-read communication. There is a massive amount of that type of communication - spam, student essays, procedural documents for compliance. There are loads of jobs that need to do that sort of thing regularly and it's a godsend for them.

Honestly, I've had a great experience because I've read a lot of experiences like yours and stuck with pages router & Next 12, which works nicely for everything I've needed it to do.

There might be a point where app router is stable & smooth but it's pretty clearly not right now, so havn't really seen the need to upgrade. I think there was a pretty decent comms issue with the stability of it from both the Next and React teams, but I have a hard time faulting an otherwise fairly stable and useful framework for adding features when they're not breaking the existing stable path.

Hooks was a bit of a bumpy transition as well, but I do think that I prefer the code written with them to the code before them. I think it's OK to wait a year or two to let the rough edges get filed down when these types of frameworks release big new feature sets.

Edit: I'll note that we don't use next/image or API routes either, both of which I've seen some churn / pain with. Possible I just hit on the framework when it was in a pretty happy place and most of the new features or suggested defaults have had pain points that I havn't experienced.

My counterpoint to this is just that DDB is not a super usable piece of software (it's slow, buggy, and expensive). It's got the massive advantage of having the rights to sell D&D content, but there's definitely room for disruption in that market.

For me, the reason I prefer Google to GPT is that it's much easier for me to assess the credibility of a Google answer vs a GPT one. There are so many signals in any primary source. Some obvious ones are things like number of upvotes, site reputability, presence of (working) examples, when was the answer written? More intangible things are like how closely does this solution match my problem statement, does the author write in a trustworthy manner are also easy for me to pick up at a glance.

With GPT, I don't have any of that (or maybe I just need to re-learn it?)

Also, I get a useful answer from most Google queries. GPT performs at a significantly lower bar (at least right now) - it works well for some stuff but not others, and the time it takes to figure out whether it's going to do a good job (and maybe do a couple of rounds of prompt refinement) is much more than just Googling.

I wonder if there's something that you can do as you're nearing the end of the context window to summarize the "state" of the world so far and put it into context so that the model always has context on the most important details. I'd imagine that you'd lose some of the minor stuff by compressing context this way, but, hey, humans forget minor details too.

It doesn't even "understand" basic math - trivial to test if you give it a sufficiently unique expression (e.g. 43829583 * 5373271).

Not a dumb question!

They cover different needs - Tailwind is a low-level CSS library that provides a different (and some claim better) way of styling HTML. It doesn't provide markup, interactivity, etc.

AntD is a high-level component library that provides components with pre-built markup, JS interactivity, accessibility, etc. Any of the component libraries in this thread are a good point of comparison.

You might use Tailwind if you're building out your own components, or styling a page that doesn't need much interactivity. It is fast, lightweight, and easy to integrate. You can compare it to any CSS-in-JS tool, SASS, and other styling solutions.

You'd typically turn towards a component library (like MaterialUI, Ant Design, or Tailwind UI) if you're looking to quickly build a webapp that needs a lot of interactivity out of the gate. These solutions are larger and heavier, but provide a lot more functionality (interactivity, accessibility).

I wonder if AWS will make more or less money from these outages?

Will large players flee because of excessive instability? Or will smaller players go from single-AZ to more expensive multi-AZ?

My guess is that no-one will leave and lots of single-AZ tenants who should be multi-AZ will use this as the impetus to do it.

Honestly, having events like this is probably good for the overall resilience of distributed systems. It's like an immune system, you don't usually fail in the same way repeatedly.

Morally, I'm very pro-high density housing. Just like I'm pro-public transit. But in reality, my expressed preference is a single-family house with a yard and the convenience a car brings. I'm not sure how to square these things.

The issue I have with these automatic "backend from your DB" service is:

* For the simple case, they seem like they are as good as a simple backend service, albeit easier to set up.

* For more complex cases (e.g. external dependencies, complex business logic), they seem so much more difficult to make work that I can't imagine anyone _not_ setting up a separate service to handle those scenarios. Maybe you can do everything with stored procedures, but Hasura, Postgraphile, et al. all seem to suggest that you should stand up a separate service for this.

* Once you've got a separate service where your complexity lives, that's going to be the meat of your project.

* Is it really worth it to introduce a separate dependency & pattern just to scaffold the easy parts more quickly? The consistency of having a single data access pattern between the client and all parts of your service seems like it would outweigh not needing to write a little code to proxy queries through your backend by far.

I guess it really depends on the app - if it's really just a view layer, or if the RUD* has very little logic to it and it's expected that the complexity of the backend logic really won't grow over time (never seen this...) then sure, it could be a fit.

Until then it seems like yet another MVP optimization that gets thrown away as soon as the app needs to grow up.

Maybe not quite the answer you're looking for, but I'll throw it in anyway.

- I planned on quitting my FAANG job in February 2020 to go travel the world for 9 months (midlife crisis, sabbatical, whatever you want to call it).

- COVID hit, we came back March 2020.

- Decided to take the opportunity to leave the Bay Area and try our hand at freelance / contracting for time flexibility so we could go travel again once lockdown ended and international travel became a possibility.

- We thought we might come back to the Bay Area once "it was over" and we'd travelled.

- Lockdown stretched on, borders stayed closed.

- Contracting picked up, was able to negotiate part-time hours making enough to live on.

- My partner switched careers successfully, starting a new business.

- Fast forward to now, I'm still contracting. We've put down roots in the small town we moved to. My partner's business is thriving. We're saving up for a house.

Overall life is good. We've traded the stresses of the Bay Area for a different set of stresses - it's equally difficult finding housing here, starting a new business has been hard, and figuring out what I want out of a freelance career has been a struggle as well. We've got a lot more free time, and the flexible hours have been a huge blessing.

The US seems to struggle with a balance between security of property and police violence against minorities. I can't believe that we can't have a save and secure society without extreme police violence. It seems like many other countries manage this, why can't we?

Very cool! We use Postman collections extensively to internally document our APIs and make handoff between frontend and backend easier. We're waffling a bit on backend schema (currently using Yup & Typescript to export request/response types, but no formal definition), but seeing this makes me think it might be worth investing in a migration to OpenAPI, just to ease documentation.