HN user
http://twitter.com/lmatteis
So? Economy is entertainment. When crypto was hype, billions were made and burned from building whatever entertaining thing around that. Now it's AI's turn. Billions will be made and burned. Economy is just a fun game. Let's have fun. The idea that everything needs to be "useful" is highly subjective. What is truly useful? Is it food? Shelter? Medicine?
You still care about end result though: in your case, the end result being the puzzled you solved.
AI can make that process still enjoyable. For instance I had to build a very intricate cache handler for Next.js from scratch that worked in a very specific way by serializing JSON in chunks (instead of JSON.parse it all in memory). I knew the theory, but the API details and the other annoyances always made it daunting for me.
With AI I was able to thinker more about the theory of the problem and less about the technical implementation which made the process much more fun and doable.
Perhaps we're just climbing the ladder of abstraction: in the early days people were building their own garbage collection mechanisms, their own binary search algorithms, etc. Once we started using libraries, we had to find the fun in some higher level.
Perhaps in the future the fun will be about solving puzzles within the realm of requirement definitions and all the intricacies that stem from that.
What about Call of Duty?
I've never personally used Bun. I use node.js I guess. What makes Bun fundamentally better at AI than, say, bundling a node.js app that can run anywhere?
If the answer is performance, how does Bun achieve things quicker than Node?
How's this different from... a database? Most modern dbs come with auth and some gui. I guess if you need real-time updates this is cool
I'll try to review the article with comments to make this a more critical discussion instead of just hates on Next.js (I'm just a Next.js developers for years now and am quite happy with it - but I do agree it requires some deeper understanding)
React is now using the words "server" and "client" to refer to a very specific things, ignoring their existing definitions. This would be fine, except Client components can run on the backend too
It was hard discussions to come up for naming of these things in the beginning. Even calling them "backend" and "frontend" (as they suggest in article) wasn't clear about their behavior semantics. I understand the naming annoyances but it's a complex issue that requires lots more thought than just "ah we should've called it like this"
…This results in awkwardly small server components that only do data fetching and then have a client component that contains a mostly-static version of the page.
// HydrationBoundary is a client component that passes JSON // data from the React server to the client component. return <HydrationBoundary state={dehydrate(queryClient)}> <ClientPage /> </HydrationBoundary>;
It seems they're combining Next's native hydration mechanism with TenStacks (another framework) in order to more easily fetch in the browser?
To follow on their WebSocket example where they need to update data of a user card state when a Websocket connection sends data. I don't see what would be the issue here to just use a WebSocket library inside a client component. I imagine it's something you'd have to do to in any other framework, so I don't understand what problem Next.js caused here.
What they're doing screams like a hack and probably the source their issues in this section.
Being logged in affects the homepage, which is infuriating because the client literally has everything needed to display the page instantly
I'm not sure I understand this part. They mention their app is not static but instead is fully dynamic. Then, how would they avoid NOT showing a loading state in between pages?
One form of loading state that cannot be represented with the App Router is having a page such as a page like a git project's issue page, and clicking on a user name to navigate to their profile page. With loading.tsx, the entire page is a skeleton, but when modeling these queries with TanStack Query it is possible to show the username and avatar instantly while the user's bio and repositories are fetched in. Server components don't support this form of navigation because the data is only available in rendered components, so it must be re-fetched.
You can use third-party libs to achieve this idea of reusing information from page to another. Example of this is motion's AnimatePresence which allows smooth transitions between 2 react states. Another possibility (of reusing data from an earlier page) is to integrate directly into Next.js new view transitions api: https://view-transition-example.vercel.app/blog <- notice how clicking on a post shows the title immediately
At work, we just make our loading.tsx files contain the useQuery calls and show a skeleton. This is because when Next.js loads the actual Server Component, no matter what, the entire page re-mounts. No VDOM diffing here, meaning all hooks (useState) will reset slightly after the request completes. I tried to reproduce a simple case where I was begging Next.js to just update the existing DOM and preserve state, but it just doesn't. Thankfully, the time the blank RSC call takes is short enough.
This seems like an artefact of the first issue: trying to combing two different hydration systems that are not really meant to work together?
Fetching layouts in isolation is a cute idea, but it ends up being silly because it also means that any data fetching has to be re-done per layout. You can't share a QueryClient; instead, you must rely on their monkey-patched fetch to cache the same GET request like they promise.
Perhaps the author is missing how React cache works (https://react.dev/reference/react/cache) and how it can be used within next.js to cache fetches _PER TREE RENDER_ to avoid entirely this problem
This solution doubles the size of the initial HTML payload. Except it's worse, because the RSC payload includes JSON quoted in JS string literals, which format is much less efficient than HTML. While it seems to compress fine with brotli and render fast in the browser, this is wasteful. With the hydration pattern, at least the data locally could be re-used for interactivity and other pages.
Yes sending data twice is an architecture hurdle required for hydration to work. The idea of reusing that data in other pages was discussed before via things like AnimatePresence.
What's important to note here is that the RSC payload exists at the bottom of the HTML. Since HTML is streamed by default this won't impact Time-to-first-Render. Again, other frameworks need to do this as well (in other ways but still, it needs to happen)
I totally understand the author's frustrations. Next.js isn't perfect, and I also have lots of issues with it. Namely I dislike their intercept/parallel mechanism and setting up ISR/PPR is a nightmare. I just felt like the need to address some of their comments so maybe it can help them?
As a first I would get rid of tanstack since it's fighting against Next.js architecture.
Or yeah just move entirely elsewhere :)
I mean, if you want to be an artist, you really can. I've lived off a van for almost a year... just for adventure. Traveled close to beach where I could shower. I spent literally close to nothing day-to-day. I could remake my weekly expenses just working at a few restaurants in the weekend, and enjoy the beach the rest of the week surfing.
Now that I'm back to my normal office coding job, I feel like I'm actually saving less money because I have rent, and general city life to spend money on. It's all about the comforts one is used to.
The story of artists not having enough money is probably about people that are used to too many comforts. I've seen people complain they didn't have money to go by, whilst living in an apartment close to a densely populated city and having a car... get rid of those comforts if you want to make it!
then why am I paying for a senior ?
Because they know how to talk to the AI. That's literally the skill that differentiates seniors from juniors at this point. And a skill that you gain only by knowing about the problem space and having banged your head at it multiple times.
Cool but how does it compare to something like subreddits? There are still biased moderators behind the scene just like subreddits. Seems to not have the upvoting/downvoting side of it which imo is crucial to democratize the entire thing.
I think upvoting/downvoting is a crucial aspect to news/information/knowledge. But we've been doing it with just numbers all along. Why not experiment with weights or more complex voting methods? Ex: my reputation is divided in categories - I'm more an expert in history then politics hence my vote towards historical subjects have more weights. Feels like that's the next big step for news. Instead of just another centralized aggregator?
No offense to the cool system and website though
Next.js hydrates only client components - so effectively it's doing island architecture. And it's react end to end. How's that different from Astro? Stating things like "Components without the complexity" doesn't really mean anything unless you do some comparisons?
I was inspired by Bret's articles at a young age. Made be think of software more from a visual perspective. Even re-reading this article now, after many years, inspires me to think of possible ways we can improve building visual systems - thinking more from a designer's perspective; rather than an engineering one. And how far ahead his thinking was.
Even his imaginary "snapshot/example driven design tool" (described at the end of the article) seems quite intriguing and thought provoking. I wonder if with AI being so easily accessible nowadays, a retake on this tool can provide something that is actually usable and useful to people?
Will this whole idea of writing more server-side logic pay off?
I'm not sure. It felt like we were moving towards dumb backends that sync automatically towards frontends that would contain most logic. Things like https://localfirstweb.dev/ or https://electric-sql.com/ felt like the future
Writing more server code (as quoting/react-server-components are suggesting) will increase the surface area where errors can occur. Limiting that to either just the server/client feels like a much saner approach
I've been a webdev for 20 years, and I didn't understand what any of that post meant.
How did they get a hold of the enron.com domain?
To me this is what all AI feels like. People want "hard to make things" because they feel special and unordinary. If anybody with a prompt can do it, it ain't gonna sell
I agree with many of the points, but how do they relate with the article at hand?
Apart from food packaging, one great way to easily ingest plastic is to use synthetic clothing. Just a basic rubbing of a synthetic sleeve on your nose causes thousands of polyester particles to release in thin air, readily breathable.
Not just clothing, but also bedding is a huge issue. With pillows, mattresses and towels mostly made of synthetic fibers.
My usual instinct is: try rubbing the synthetic material; if it releases thousands of particles in thin air, stay away from it
My biggest beef with this is: why humanly shaped? Our shape is the outcome of evolutionary survival in an environment that is very much different from... a household?
I’d trust way more that group of experts to make a decision for me.
Otherwise we’d get Walmarts all over the place
Isn’t it simple economics? There’s no incentives
Perhaps entertainment might fund it? Like a reality show on the moon? Still doubt it will finance billions
If out of all the species that ever existed, we're the only ones that understand our own mortality, it makes me wonder what else, by sheer probability, we have yet to understand.
Cool but doesn't the Apple Watch have all kinds of sensors to make it work against your wrist? Putting in this case will kind of remove the point of all those nifty hardware gadgets.
I think a large benefit to "DB in browser" is about the whole "local-first" software movement. A good overview is written here https://sqlsync.dev/posts/stop-building-databases/
The essence of the approach is that a large majority of FE apps have constructed quite complex caching layers to improve performance over "querying backend data" - take a look at things like Next.js or React Query <- as the post above mentions, they're essentially rebuilding databases. So instead this approach just moves the db to the browser, along with a powerful syncing layer.
I think it's an approach that deserves more attention, especially to improve DX where we end up writing a whole lot of database-related logic on clients. Mind as well then just use a database on the client as well
What do you all think all this comes from? To me personally it always baffles me with wonder. I think of the analogy of a mouse living in a cage. Do they actually even realize they are inside a cage? Inside a world constructed by some other being?
What baffles me is that the explanation of reality is too complex for our brains to grasp. Same as to how the mouse will never be able to understand they live in a cage (or even the concept of a cage?) no matter the knowledge we throw at them.
Such an incredible concept.
Just read through the article, not sure I get what's the novel thing here. Any insights?
Or even better store data as an sqlite file that is full-text-search indexed. Then you can full-text search the torrent on demand: https://github.com/bittorrent/sqltorrent
Hold up. The first example in their intro video is a snippet of ancient React code. How old is this?
You're seriously driving around Amsterdam in a car? But why when a bicycle is 10x faster and easier?
Where do you get this data from? I've been living in Amsterdam for 5 years now and all of my friends or people that I know of that live somewhat in the city don't have a car... because (1) they can't afford it and (2) they don't need it. Biking infra is so freaking amazing that it makes me want to bike all the time instead of getting the car (even if I had one). Driving around with a car in Amsterdam is just madness. I did it a few times for moving heavy stuff around and it's a mess because you're redirected across streets making it 5x longer to get to where you have to.
I think your experience comes more from people living outside the dutch cities, in more rural areas? Then it makes sense to own a car. It doesn't make sense in a densely populated area.
But anyway the Netherlands has really figured it out when it comes to public transport. No other place comes close in my experience. People who grew up here perhaps don't realize how lucky they area... and how shit it is in other places.