krishadi

I use a Logitech MX Ergo that has a trackball, and it's helped me a lot with wrist pain. Using a trackball felt a bit weird initially.

I commute by bike daily, and I got some ergonomic handlebar ends and they've drastically improved by experience.

Some of my best purchases were outdoor clothing I bought some 7 years ago on a whim. I constantly regret not getting some 10 of them, and sadly they don't make these anymore.

- Thermal inner pants from Berghaus - Knitted thermal jacket from Salewa

How do I point it to follow up or zoom into a particular part of the answer?

The UI is brilliant !

1. I like the way sources are listed on the right panel, that makes them easily visible as i scroll through the answer. 2. The rendering of the answers using rich visual components is nice to look at. I personally hate information dense reports that ChatGPT spews, which isn't easy to consume quickly.

What I miss though is iterations on the answer, as in, how do I specifically zoom into one aspect of the answer, and then easily zoom out and continue.

It was mainly for SEO, and to some extent protecting against website scrapers and crawlers.

It is exactly what I am talking about. Rendering the component on the server, takes up resources, as opposed to just sending that data to the client, and the client rendering it.

In Nextjs, "use client" is used to force the rendering to take place in the client, because many components cannot me rendered in the server. For example maps. In this case, it's unnecessary to use an SSR framework.

I could imagine that the cash cow part of a product gets all the attention in the beginning. Does that stay the same through the life cycle? Or do you see that it takes a back seat while feature development on top of that takes the center stage at alter stages of the product?

[edited to add this] I also see that it's sometimes easier to build something new, than to go on maintaining something.

Just curious to know if you see the following trend:

As a codebase matures, the amount of time spent of code maintenance increases and with bug fixes, it gets harder to spot them and the amount of code that is required to solve them is little.

> But I was equally surprised by how little this was being discussed, or (as far as I could tell) practiced in the real world. While there seemed to be endless threads on Twitter about server-side React (to get the UI generation closer to the data), no-one was talking about the opposite: moving the data to be closer to the UI, and onto the client!

This, I've wondered for a while. There is plenty of talk about server side rendering, which I don't think is useful for many apps out there. SSR is quite wasteful of the resources on the client side that can be made useful. And, I've seen many apps being developed with "use cliënt" littered all over, and that begs to wonder why do you even want SSR in your app.

This is exciting news!

There aren't many smart watches out there. I've loved what Garmin has done. I had always hoped something which would open up an ecosystem to build on. This looks promising on that front.