I hate it with passion. It won't respect pinned versions in package.json. I have to explicitly exclude stuff. Be better.

Could you elaborate a little? Are you saying it should ignore vulnerable packages simply because you pinned it to a specific version? Or does it warn even if your specific version isn't vulnerable?

Any release will definitely not restore Webpack as the "first choice". That ship has sailed and Webpack has accumulated a lot of bad rep.

Maybe for a few people who used to run Webpacker in Rails, and migrated to shakapacker instead of Vite, it will be good news.

When a tool like this (which was never pleasant to work with) loses the lead, it never restores it.

According to your view, is Webpack becoming "the next jQuery" merely a matter of time?

Nothing wrong with jQuery. If a dev dependency irks me, I have no reason to revisit it no matter how better it got. We moved on.

Noob question, but why no use ints for PK, and UUIDs for a public_id field?

If you put an index on the UUID field (because you have an API where you can retrieve objects with UUID) you have kind of the same problem, at least in Postgres where a primary key index or a secondary index are more or less the same (to the point is perfectly valid in pgsql to not have any primary key defined for the table, because storage on disk is done trough an internal ID and the indexes, being primary or not, just reference to the rowId in memory). Plus the waste of space of having 2 indexes for the same table.

Of course this is not always the case that is bad, for example if you have a lot of relations you can have only one table where you have the UUID field (and thus expensive index), and then the relations could use the more efficient int key for relations (for example you have an user entity with both int and uuid keys, and user attribute references the user with the int key, of course at the expense of a join if you need to retrieve one user attribute when retrieving the user is not needed).

You can create hash indexes in Postgres, so the secondary index uuid seems workable:

https://www.postgresql.org/docs/current/hash-index.html

*edit: sorry, misread that. My answer is not valid to your question.

original answer: because if you dont come up with these ints randomly they are sequential which can cause many unwanted situations where people can guess valid IDs and deduce things from that data. See https://en.wikipedia.org/wiki/German_tank_problem

Hence the presumed implication behind the public_id field in GP's comment: anywhere identifiers are exposed, you use the public_id field, thereby preventing ID guessing while still retaining the benefits of ordered IDs where internal lookups are concerned.

Edit: just saw your edit, sounds like we're on the same page!

Decades of security vulnerabilities and compromises because of sequential/guessable PKs is (only!) part of the reason we're here. Miss an authorization check anywhere in the application and you're spoon-feeding entire tables to anyone with the inclination to ask for it.

I also think we can use a combination of a PID - persistent ID (I always thought it was public) and an auto-increment integer ID. Having a unique key helps when migrating data between systems or referencing a piece of data in a different system. Also, using serial IDs in URLs and APIs can reveal sensitive information, e.g. how many items there are in the database.

One of the benefits of UUIDs is that you can easily merge data coming from multiple databases. Auto-increments cause collisions.

The article mentions microservices, which can increase the likelihood of collisions in sequential incremental keys.

One more reason to stay away from microservices, if possible.

Always try to avoid having two services using the same DB. Only way I'd ever consider sharing a DB is if only one service will ever modify it and all others only read.

Good luck enforcing that :)

The 'collision' is two service classes both trying to use one db.

If you separate them (i.e. microservices) the they no longer try to use one db.

There is nothing stopping multiple microservices from using the same DB, so of course this will happen in practice.

Sometimes it might even be for a good reason.

They haven't implemented RSC yet.

The post is mostly about Phoenix LiveView, while the title makes it about the framework.

To be honest one of the reasons I don't like Phoenix is that even if I opt-out of LV in the generators, I still get a lot of LV code.

Yup - an important distinction that wasn't obvious to me when I first jumped in. LiveViews are very opinionated and generate a ton of boilerplate. Not always a bad thing, but Elixir is elegant because of how spartan and expressive the code is - LiveView is kind of the opposite IMO.

what a timing

I have only good things to say about TanStack start. I know there's some fatigue when it comes to full-stack JS/TS frameworks, since they re-invent ways to do data fetching, but are not in any way batteries-included.

I prefer it over Next.js and the whole RSC story, and it has sensible features that I missed in Remix (server functions from everywhere [1], middleware, type safety)

I wouldn't pick it as a full-stack framework, I will always keep my backend separate, but for a SSR-capable TypeScript framework it's amazing.

[1]: https://tanstack.com/start/latest/docs/framework/react/serve...

Any good book recommendations?

Robin Williams - any of her books with "For non-Designers" in the title, even if it is old, it is gold

Chess, I play on Lichess[1]. I started about a year and a half ago.

[1]: https://lichess.org/

Try having a healthy relationship, kids, responsibilities, work, and some form of hobbies. If I don't write my thoughts, ideas, whatever, I lose the ball.

So, a bit like separating the grain from the chaff or, organizing all these different life experiences into an understandable and meaningful whole?