Well done.
311 karma · joined February 18, 2019
And correct me if I'm wrong, nothing worse than an incorrect pedant.
Lord knows I still do that most of the time though...
New paradigm (container queries): You make layout changes based on the width / height of the containing element.
This lets you layout a component so that it looks good in any sized container. Picture a component that might be in the main section or in the sidebar - you can now just style directly based on width of the container instead of having to know the total width of sidebar + main section and do the calculation using viewport width.
Frustrating as a developer that is already slammed, but good for the business overall. But how many times have we all built extremely complex features that never ever get used.
If you're getting Figmas with inconsistent padding / margins everywhere, no CSS framework is going to save you.
I lived through every CSS fad for writing "maintainable" css, and have settled on Tailwind. It doesn't limit you, you can always add normal old css files to your project if you need / want to.
But what it means is I don't end up with a `utilities.scss` of `.flex` `.block` etc etc etc, which you always do on any project. I get a full catalogue of utility classes that only get included in the generated css if I use them in my project, I don't have to think about class names, and I don't have to open a separate css file.
The only con is sometimes an absolutely ridiculous amount of utility classes on an element, but frankly scarlet...
Should've been a different product.
If only this had been brought to their attention recently with a bunch of good-faith discussion.
And how about that dev rel... no response since August of last year.
Cause you're inevitably gonna want to track loading state, error state, refetch on error, revalidate etc etc.
swr or tanstack-query are great and remove the need for useEffects for API requests. For sure they come with their own overhead, but there isn't getting away from the complexity of handling API requests and all the possible paths that can happen.
When I read complaints about hooks I'm either missing something fundamental about why they're bad, or the people complaining are missing it.
On the other hand, their marketing and hype machine has gotten the industry at large to buy into their product. So when you promise enough to get companies to move to your (free, open source) tech stack, but then are MIA when there are issues... I am of two minds.
But yes at the end of the day you're right.
As someone in that discussion rightfully says: "We are grown-ups with access to the same tracing and profiling tools as you. There is nothing dangerous about us using Node.js as far as I’m concerned."
Additionally, your comment just reeks of PR to me. I don't know if you do it on purpose or what, but to read my comment and then come back with "Middleware works when self hosting"... it has to be intentional on your part to misunderstand my comment that badly.
Infuriating. The longer I do this, the more that issue management responsiveness becomes a real consideration when choosing a dependency.
They are optimizing for deploying to the edge, which when self hosting you don't need to.
So whether malicious or not, their guard rails conveniently make it frustrating to self host once you need to do anything outside of their garden.
Let us take control when self-hosting, please!
It's not an option for large next.js projects, and certainly does not convey what you're saying here.