I’ll clarify because many here don’t understand how next.js works
next.js does static site generation and server side rendering, while also supporting SPA paradigms.
The build process is pretty straightforward, run npm run build and you get a static build with an html page for every page in the website.
first load is pure html. after you load the website, client side routing takes over and you get instant navigation between pages
one more point to mention:
You need to have the following tools installed to build the current erlang.org site:
GNU make 4.1 or later
ruby 3.3.0 or later
bundler 2.5.6 or later
nodejs 20.11.1 or later
erlang 26 or later
xsltproc
You need to have the following tools installed to build the new erlang.org site:
You need to have the following tools installed to build the current erlang.org site:
This isn’t an apples to apples comparison, because node is not a tool, it’s a runtime environment with its own package manager, that can pull (tens of) thousands of dependencies.
The erlang website normally does not generate this much interest, let’s hope the interest also generates some improvements
There is (as far as I know), no static site generation framework in Erlang, so no matter what we do we will have to look elsewhere for the tools. Whether that is go, ruby, node or elsewhere is not very important as long as the long-term maintainers can handle the technology. At the moment, I am the only maintainer so I’ve chosen to use the tools I’m familiar with, which is why the current site uses make, xsltproc and Erlang. Had I been good at Ruby/JS, I imagine I would have written a lot of that using either of those languages.
As @hich has said, Next.js does provide SSG, so while it is mainly used for SPAs it can also be used for SSG. The proposed Next.js solution uses about as much client side JS as the current design.
Of the people in the Erlang/OTP team, I am probably the best at web design, and I am very very bad at it. So we will take all the help we can get. So if anyone is interested in helping out by either collaborating with @hich on a re-design using Next.js or just sending patches improving things more organically please do step forward and help out.
I don’t know where you got that number from but it’s wrong.
this is the dep lock for the project and it’s 11636 lines (actual size is smaller because of dev dependencies)
I’m also pretty sure the current website has way more deps since it relies on 6 different technologies
That doesn’t address any of the other points though:
it will still need maintenance to keep up with React & next.js churn;
although React et al are great when they work as expected, but when they don’t it’s a rabbit hole of dependency surfing
the React core teams change key components regularly and aren’t at all afraid to break backwards compatibility, so there really can be rewrites required just to keep things building with the latest version, which is always encouraged rather than backporting changes, as the whole momentum of the JS world is relentlessly forward regardless of breakage, “keep with the program”
it still requires a whole new set of skills that it seems none of the current maintainers have
it still involves writing a JS app to generate a static site using React/Next approach rather than just maintaining content using eg markdown.
Additionally, who would maintain this for years going forward? Are you going to guarantee that you will? What happens if you get too busy with other website projects, who’s going to pick it up then? Seems way better that people on the OTP team should spend their time on OTP than learning to even build Next & React, let alone structuring JS applications, even if their output is HTML.
And then there are all the other questions around an actual UX design/testing process etc, and whether any of this is actually needed based on any kind of actual metrics.
None of this addresses another point either - you claim the current site “has no identity”. This is hugely subjective; by what & whose metrics/standard? Personally I don’t agree, and what’s more I think the prototype has much less. It looks like any other site. I read your point about familiarity and, again just my opinion, but I just don’t buy it. As long as usability and accessibility are addressed - in a proper UX and design process! - following an exact formula is not necessary and certainly doesn’t constitute a rationale for throwing out the existing system in favour of a framework that no-one in the team knows.
My feeling based on quite a few projects built using React & React Native are that it does matter if the chosen technology means there’s more maintenance required than others. It makes things fast up front but there really is a long tail of work behind that.
I think a re-design should be a UX and design project independent of Next.js or Jekyll or anything else. It’s a separate task, Next.js and pals (including Jekyll) aren’t design tools. Once the design has been tested and agreed, then a decision should be made about what tools to use for the implementation, based on key factors including who will maintain it and how.
In an ideal world, yes that would be the way to go about it. However, as of right now, the only one that has done any work is @hich and his preferred tool of choice is Next.js. If there are enough people on that project so that I get satisfied that they can manage long-term maintainance, then I’m fine with using it. The same goes for basically any other tool used.
If there are not enough people interested (which so far is the case), then maybe we can at least get some design improvements in the current site, but it seems someone besided @hich will have to do that as so far he has not shown any interest in this.
Totally fair. It’s obviously not down to me but my suggestion would be not to go ahead with replacing a perfectly functional but potentially design-lacking site with another perfectly functional but demonstrably design-lacking site built using a technology that no-one on the core team knows or has time to get up to speed on - and which will require at least as much maintenance as the current one - until at the least that design has been done; because otherwise what has been gained? The site still hasn’t been designed, and it’s now built using a tool with a whole bunch of dependencies (not just tech, but skills and the other things I’ve outlined) that no-one in the core teams knows about.
The other question is, also totally fair that @hich is the only person who’s done any work on it, but … why? Where is it written that it needs doing? Hasn’t the current implementation in Jekyll worked well for several years? Who’s complaining about the site, and on what grounds? Why go through all the above and add all the above external dependencies otherwise?
I’ve heard many people complain about the current site, anything from it is hard to find the information they want to the coloring of links is wrong. Myself I’m not a big fan of how the blog posts look like: Erlang/OTP 27 Highlights - Erlang/OTP though I have no idea on how to make it nicer.
So if there are a couple of people that know how to make a website that has a nice design with the correct contrasts and color combinations and what not and they want to redesign + take ownership of the design of the site, then I’m more that happy to let them do that so that I can spend more time optimizing the JIT and less time fixing HTML stuff.
I asked @hich to gather more people behind his quest so that the chances of maintainance burden ending back on me was smaller, though it will of course never be zero as at the end of the day I need to make sure that the thing works as it should.
I noticed @garazdawi mentioned Hugo and it’s actually something I’ve heard quite a bit of and have been meaning to check out for a while (the PragProg site is built using Hugo and there’s even a book about it) so I had a quick look and found the same theme @hich appears to have used:
This is what they say on their about page which I think will resonate with a lot of the commenters in this thread:
Indeed it is very easy to set up and much faster than I recall Jekyll being, all I had to do was:
brew install Hugo
hugo new site test-for-erlang
cd test-for-erlang
# download the theme into the themes directory
git submodule add https://github.com/imfing/hextra.git themes/hextra
# set the theme in the config
echo "theme = 'hextra'" >> hugo.toml
# start the server
Hugo server
Alternatively, there is a starter template for Hextra, which you can install by:
# You'll need Go installed (I installed with: asdf install golang latest)
git clone https://github.com/imfing/hextra-starter-template.git
cd hextra-starter-template
# start the server
hugo mod tidy
hugo server --logLevel debug --disableFastRender -p 1313
Advantages to using Hugo and this theme
As seen in this thread people aren’t keen on Next.js and so may be more likely to use Hugo (and thus have more contributors to the site). People might also be more inclined to use Hugo because any skills they acquire may be useful for their own projects.
It looks like the same theme @hich was using so hopefully it will be just as easy for @hich to work with.
Thoughts on design
I think design can be incredibly important (and it seems this is more of an issue for @garazdawi than anything else) so I wonder if Ericsson or the EEF could be approached for a budget for a professional redesign?
I’m not sure if Marc’s team was responsible for these designs:
But they are excellent, so if his team was responsible maybe he could be approached for a quote?
As has been mentioned above, the decision makers for this proposal must be those who will maintain it. For making the existing site as useful as it currently is, I for one, and no doubt many others, ‘thank you for your efforts, Lukas!’
As a consumer of information from the Erlang web site, I don’t actually care how much software has to be installed for the build process to run. The bloat I care about is the number of bytes sent to my browser and the time it takes the browser to render the page and the memory it uses while doing so. You could be using server-side INTERCAL for all I care. But I would like Chromium on a 4GB Raspberry Pi 400 to render the pages fast while doing other work.
I understand the community’s desire to use Erlang tech for the website.
If eventually the decision is made to use Erlang tech then I’m willing to work with the team to make it happen.
Same applies for next.js and docusaurus. I’m willing to work on improving the site either way.
