Should we move this portal to Next.js?

[Pablo]

The lighthouse score for the Solidity portal is not that good. You can measure its performance at web.dev/measure.

I made a better and faster replica of the solidity portal, but I did it using Next.js and tailwindcss. Since the source code is completely different, I thought I asked for your thoughts about it making any pull requests.

I think it's better to use Next.js because most front-end developers are familiarized with React.js. You can see a preview on solidity-portal.vercel.app and here is the source code. The difference in the lighthouse score is clear. I like using it because it gives me a perspective on how people with poor internet connections might see the website.

Please, note that the "Try Solidity" portion with the Ace editor and Solidity compiler is not done. I had never dealt with either of those before.

This version of the website can be hosted on Vercel for free with any DNS provider.

[chriseth]

Thanks for opening this issue! Why do you think next.js improves the website? I'm pretty sure that most of the performance drawbacks lie in the "Try Solidity" part, since it loads a full compiler into the browser, but it is true that we could mabye add some tweaks also elsewhere. The benefit of using jekyll is that the page input files are not javascript, which is a big win IMO.

I saw that next.js loads .js files after the page has loaded, this is not the case currently, and I think it's good to leave it like that.

[Diego Ramos]

I think it improves the website because it already loads a whole lot faster and it improves SEO by following lighthouse standards, which are used by the Google search engine to rank websites.

The biggest performance drawback right now is the YouTube Embedded video. I'm considering simply using the thumbnail as a link.

Regardless of those .js files loaded by Next.js this example I created is a static website. Every time you deploy with Next.js you can see which routes are static and which are not:

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)
●  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)
(ISR)     incremental static regeneration (uses revalidate in getStaticProps)

I saw that soliditylang.org only has the index / route and the /about route. The complexity of creating new pages can be abstracted as much as one likes. We could make it so that pages can be added with an .md or .mdx file, as seen in nextra.

My main concern is attracting more developers and contributors in the future by using something they are knowledgeable of and it is actively maintained.