Over the past few weeks I've been working on a small application to view trending repos on GitHub. I built the PWA[1] with React, Next.js and GraphQL .. but what's interesting is the application is only using React server side, meaning the client side javascript is only a few lines code adding some event listeners and registering a service worker for offline capability. This helped me achieve a perfect google chrome performance audit
I learned a ton working on it and would love to talk about it if anyone has any questions!
I'm super intrigued by the client-side/server-side rendering question. When I discovered single page apps I thought I'd seen the future - servers were just things that hosted web services, and all the presentation was a bundled, minimized blob served up by a static CDN. So simple, so clean, such clear separation of concerns. But now I'm seeing reports of faster first page rendering with React server than React client, and here I'm seeing a clearly very smart person articulating a completely different class of benefit of server-side rendering. Clearly I shouldn't be walking away from old style server side rendering so casually. My question is how do you think about that choice, now that we have the freedom to go either direction?
It's certainly interesting. This kind of development has gone full circle where the methodologies are back to where it was years ago.
The issues that really large JS bundles can cause are really hard to solve (bloated sizes, but also parse time of the bundles). There are a lot of tools to help mitigate those like code splitting, but it's really challenging once things get big.
When I wanted to achieve a 100 in my chrome performance audit, I simply couldn't include React.
I think React adds a tremendous amount of value from the ecosystem, the constant improvements and updates .. and the mindset that developers have when building out react applications. (component model, etc)
I think for any really large application with lots of client side interactions or async data / data management, my solution would become unwieldy.
But for smaller applications that maybe don't need to do as much, (in the above case we're simply registering some event listeners to submit a form) or landing pages or the like .. the above solution would work very well.
Does anyone know of a solution to the jank on firefox (perhaps others) when you have a hover scale effect? I figure animating all dimensions and text size instead of scale may do the trick, but that's a pain.
I'd even be okay with indefinitely deferring the re-render at the end of the animation if possible.
Horrifying to see my stupid side (joke) project manipulated the star rankings. https://www.gitstarred.com/. I guess it doesn't take many stars to do that.
I like to check the trending repos once a day, but Github keeps moving the link to it, this is fantastic. While I am sure others will be asking to add more languages, could there be a feature to check multiple languages at once with the language displayed with the repo? It is annoying on Github to have to check both Javascript and Typescript for similar trending projects.
A simple vertical list would also be nice, but that is personal preference.
Discontinued doesn't mean out of use. But I get your point. Maybe it doesn't work on ie7 either. I should just "get with the times" and move to android or iOS. But we're taking about text not rendering correctly on a PWA that otherwise works well. I don't see the harm in reporting it because maybe its one tiny change the author needs to make in order for it to be usable.
Changing the width or zooming in and out changes the number of columns (nice!), but the max seems to be 4. Is that a hard limit? Seems like a responsive UI should respect wider screens in landscape.
Nice work, btw.
Never used next, looks interesting. So with this setup, the browser doesn't do any work, all pages are loaded as if they were static, and rendered server side?
The way that is achieved is pretty neat, Next.js has a <Document />[1] component that you can extend. This Document is essentially your application shell that is used when server side rendering.
Here is the trends Document component[2] where you can see I'm simply omitting `NextScripts` which ends up being the frontend bundle with react + application code
I'd seen references to next before this but never really dug in deep enough to get a sense of whether it was worthwhile. Thanks for giving it enough context to show how cool and accessible next is.
If I understand correctly you could build something like that but I'm not currently persisting any data from github which is something I'd need to add first.
I'm simply getting this data from Github and then caching the rendered result on the cloudflare CDN layer, the rendered page data in memory in node, and additionally the GraphQL query in memory
