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
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 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.
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.
I hope there is a better way to maintain open source projects without being overly cautious and suspicious of every PR someone makes. Maintaining open source projects is hard, and this is going to slow down development on many projects. And, rightly so, it's better to make a good code base, rather than one that is littered with backdoors.
I wonder what could make this situation better for the maintainers of open source projects?
On a side note, when I had my startup and was the CTO, a lot of advice I got and also what I ended up realising was that my priority and goal was to build an amazing `Tech Team`.
If you are building a search engine or a QA bot, the embedding of the query still needs to be calculated. The results do depend on the quality of the model, and if you are using a large on it does take time.