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.

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.

Edit: See https://foundryvtt.wiki/en/development/guides/pixi

Edit2: For an example of why gamedev toolkits don't necessarily produce performant, highly usable software, check out Dungeondraft (https://dungeondraft.net/). It's built with Godot and gets the job done, but as an application it's a total mess. I'm working on an alternative but (surprise!) it's a challenge.

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.

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).

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.

* 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.

- 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.

Some people seem to have a natural ability to break complex topics down into comprehensible pieces. That's something I'd love to learn more thoroughly.

Comments URL: https://news.ycombinator.com/item?id=29281647

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=27574395

Points: 1

# Comments: 0

Podcast: https://blog.simonsays.ai/the-basement-tapes-with-malcolm-gl...

(Somewhat biased, but still a good summary of the research) article on linoleic acid: https://theecologist.org/2014/feb/24/linoleic-acid-overwhelm...