Hacker Newsnew | past | comments | ask | show | jobs | submit | heldrida's commentslogin

I agree, it’s hard to believe. Hopefully the original comment author can share one of those questions.

Fear of missing out, network effect, etc.

I personally never opened an account, do remember seeing ex-colleagues exaggerating their job descriptions, titles, etc It looks quite fake to me. But I wonder what could have happened to me if I had an account 10, 15 and 18 years ago.


No, it's different. A "toast" is a floating element, a "push notification" which is detached from the panel, e.g. can disappear quite quickly. The banner is placed closest to the context where the action is triggered, e.g. might require the user to close it. If you have some disability, e.g. cognitive, visual or motor, it's likely to be easier to perceive the information. When a user creates an "issue", the "issue item" is displayed in the list, meaning that you won't need a secondary notification process.


Do you really need React Server Conponents or even Server Side Rendering?


Before SSR (unless you were using PHP I guess) you had to ship a shell of a site with all the conditionals being decided only AFTER the browser has gotten all the HTML + JS pulled down. If you need to make any API calls, you've delayed rendering by hundreds of milliseconds or worse (round trip to your server)

With SSR, those round trips to the server could be down to single-digit milliseconds assuming your frontend server is in the same datacenter as your backend. Plus you send HTML that has actual content to be rendered right away.

A truly functional pageload can go from seconds to milliseconds, and you're transferring less data over the wire. Better all around at the expense of running a React Server instead of a static file host.


Thank you. It's disappointing that you have to say this on a website full of supposedly technically proficient people.


It's very use-case dependent.

SSR can be a game-changer in domains like e-commerce. But completely useless for some other use case.

RSC advantages are a bit more complex to explain, because even a simple portfolio website would benefit from it. Contrary to the common belief created by long-term ReactJS dev, RSC simplifies a lot of the logic. Adapting existing code to RSC can be quite a mess and RSC is a big change of mindset for anybody used to ReactJS.


Yes. Web applications were impossible before these libraries.


If you truly believe that than we must really be moving backwards


I think they have a point, before cgi-bin it was almost impossible to have a real web application. It took a decade for server-side rendering to fall out of favour. Flash websites and Gmail starting to become seriously interactive in the mid 2000s were the start of frontend-first web applications, but even those relied on the backend to provide them with an initial data set to make performance usable.


No, they were not. They required a lot more round-trips to the server though, and rendering the results was a lot harder. But if you think of a browser as an intelligent terminal there is no reason why you couldn't run the application server side and display the UI locally, that's just a matter of defining some extra primitives. Graphical terminals were made first in the 60's or so.


Of course you do, in certain cases making less round-trips to the server is just straight more efficient


I agree, they seem to have never tried it at all! Bun DX is the best, and Bun is the trend setter. Others are just catching up!


Yeah, just switch to a non-NPM compatible and inexistant ecosystem just because you need to specify a few parameters in a config.

Anthropic is trying to IPO at a valuation of $300B so if their engineers nor their AI can be bothered to do this then maybe they're not as good as they think they are.


>Yeah, just switch to a non-NPM compatible and inexistant ecosystem just because you need to specify a few parameters in a config.

Yeah.. you do not know what you are talking about.

I run my test suites on both node and bun because I prefer to maintain compatibility with node and it works just fine. I use some of bun's APIs, like stringWidth and have a polyfill module that detects if it's not bun and loads an alternative library through a dynamic import.

Not NPM compatible? Bun is literally a drop in for NPM, in fact you could use it solely as a replacement for NPM and only use node for actual execution if that's your thing. It's much faster to run bun install than npm install and it uses less disk space if you have many projects.

The developer experience on bun is so much better it isn't funny. It remains prudent, I would agree, to not depend too heavily on it, but Bun is many things: a runtime, a set of additional APIs, a replacement for the dogslow npm, a bundler etc. Pick the parts that are easily discarded if you fear Bun's gonna go away, and when using their APIs for their better performance write polyfills.

>Anthropic is trying to IPO at a valuation of $300B so if their engineers nor their AI can be bothered to do this then maybe they're not as good as they think they are.

Or maybe you should have a cold hard look in front of the mirror first and think twice before opening your mouth because the more you write the more the ignorance is shown.


I just can’t…

Welcome to 2025!


Any project repository where I'm the original author, the default branch is the "develop" branch. Let's move on!


This is hilarious!


Maybe there are people higher up with a lot of money who force these features. At the end of the day, the builders have the obey.


Film is magical. We should preserve and incentivise it.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: