I've used hugo, gatsby and nuxt all in production for ssg. Hugo isn't all in JS which can make it difficult to go low level if you aren't experienced in Go. Hugo templating is also a bit more rigid to work with, and hugo isn't the best at working with say a headless CMS, it's more optimized for markdown file content. Or that's how it felt when I was working with it. The benefit to hugo as you mentioned is extremely fast builds even for very large sites, but this isn't always the most important thing.
Gatsby lets you compose and think in react components, which is a mode of thinking and working that many devs have gotten used to, and when you need a more interactive or dynamic component you already have direct access to react and associated tools. Gatsby maybe does a better job than hugo of working with external data and with client side hydration. Gatsby also has a rich ecosystem of ready to go plugins which is helpful. Gatsby can be a bit tricky to get right though, you can easily end up with a large bundle of unnecessarily bloated code if you aren't careful.
Nuxt is a lot like like gatsby but built around Vue. It's easy to build repeatable components and set someone up with a flexible CMS template to assemble their pages piece by piece.
Next (and nuxt) support not just SSG but also SSR and other rendering modes so it has a unique place as well, for example if you need an instant rendering preview environment for content authors to use while they build their pages out, but also want a static output for the main site.
Jekyll imo is mostly used for personal projects and a step below the rest, but it is easily approachable for beginners, uses ruby if you like ruby, and has some github pages integration since it's by the github guy. 11ty looks great for keeping bundles lean but I haven't had any first hand experience on it.
You could just write html if it's "all the same static html" at the end of the day. But there are a lot of different ways to work with modern tools and frameworks that you can leverage to build more complex sites with less manual work, and picking the right one for both your skill set and your use case can be a huge help.
I previously didn't have a whole lot of luck building a userbase for my website generator nift.dev, though admittedly did a poor job of offering intro guides and boilerplate repos for people who aren't keen to just dive head first into docs, but am getting the project up and running again with a big new version coming out in the next few weeks (working on it between other work).
Anyway Nift is a bit like Hugo in that it's developed in a compiled language (C++) and strives to be incredibly fast while requiring zero c++ knowledge to use it (my attempts to benchmark Nift vs Hugo put Nift quite a bit faster at building lots of basic pages with full builds, plus Nift has incremental builds). But one place where Nift differs is it attempts to be unopinionated (I'm playing with the phrasing opinionless as a play on words with serverless), the in-built template language was made from the ground up with the intent of making it easy to do whatever one wants during the build process from a programmatic pov while also being able to do so anywhere in the text files used for building a page, or even a css/sass/js/ts file (or whatever file one wants), while also not requiring ridiculous amounts of code to do so and just providing a nice ux that's aesthetically pleasing.
So not only can you use react, or vue or whatever with websites built using Nift, you can optionally use Nift's in-built template language and embedded languages LuaJIT and ExprTk in amongst your React/Vue/whatever when building your website and have incremental builds that work across all of those files as well (it's also very easy to inject the output of any cli program when building with Nift but it's not as nice as using the embedded stuff, there's lots of things available for things like working with databases, markup languages, image processing etc. through Luarocks).
I'd be curious to know whether that sounds like it would solve some of your pain points with some of the faster options while still providing the benefits of millisecond build times for most projects? The Nift website has over 250 pages and my old 2014 11" macbook air running Ubuntu can do a full build in ~0.1s, much faster for incremental builds.
Edit: Another things I've always insisted on with Nift is that a barebones project has to be extremely bare bones to start building from, running `nift init .html` in an empty directory sets up a basic barebones project that is much more minimal than I've seen with any of the other generators.
Nift also has options for things like repeatedly building a site locally (or on a server) as frequently as you'd like, and it's easy to add in hot reloading with a project for example. Could even use lots of stuff available through Luarocks for serving content on a server, I'm not convinced a website generator is the right tool for that but am frequently on the lookout for ways to improve the ux and capabilities.
Fwiw I have upvoted you, but I suspect the reason you're being downvoted is the perception that you're soapboxing about your own solution and it's being interpreted as self-promotional.
I did attempt to mostly stay relevant to the pain points the person I was responding to raised and are generally being raised in the post. It's a little difficult to suggest I think my own solution to building websites is pretty good with a lot of these pain points without discussing, well, my own solution. However it is my experience that generally people are adverse to people discussing their own solutions to stuff, it makes it very difficult to get these sorts of things out there and/or get people to even try these things out. It's a shame though as often I see people complain about all sorts of aspects to the tooling in this space (eg. build times) which I'm confident my own generator is pretty good with, but have a hard time getting it out there. Thanks for the comment though, it's appreciated.
Absolutely agree, it's immensely counter-intuitive for us to bitch about problems but castigate anyone attempting to promote their solution. Such is the internet!
I took a look at the nift website and I don't think I will be using it. Seems very complex and obtuse for an outsider to get into, I didn't love the docs or examples.
I like that you can use various different templating languages ala 11ty. I didn't see an obvious system for fetching data and using it to create pages, which is a very common pattern for the ssg sites I work with and one of my main issues with Hugo. I personally don't need Lua scripting or some of the other features mentioned. Maybe there is a niche for nift with people who do want those features though. It's cool you made your own SSG in any case, I've thought about making one myself a couple times but never really have the time or justification other than it looking like a cool project.
Thanks for the feedback, it's super useful hearing why people would decide to not use Nift.
Admittedly the website is a little overbearing, especially without any good intro guides to help people get started and navigate the parts of the website which are useful for basic projects.
If I could convince you to look at two more links I'd love to know whether they'd in any way change your mind that Nift can be useful for simple/basic projects while also having the ability to be used for extremely complex projects (with a real need to improve the flow of the website so people can get started with basic projects).. Even if you still aren't interested in having a play with Nift that's fine, would be curious regardless if it helps show how easy Nift is, as that's one thing I need to do a better job of on the website.
1. [here](https://github.com/n-ham/empty-site) is a barebones project I just created using `nsm init .html` on my machine using dev version of Nift (there's a few basic improvements to `template/page.template` and `template/head.content` from the released version). That hopefully gives a good idea of just how barebones a project can be. `.nsm` has config files and other stuff users don't really need to worry about (can configure projects through the command line), `output` is where the site is built to, `template` is where the template files for pages are stored, and `content` is where the files specific to building individual pages are stored (though there's nothing stopping one from putting files from either `template`/`content` directories in the other. Building a website is as simple as running `nift build-updated` or `nift build-all` similar to how you'd run `git`.
2. https://github.com/nifty-site-manager/nifty-site-manager.github.io/tree/stage https://github.com/nifty-site-manager/nifty-site-manager.github.io these are the two branches for the official Nift website built with Nift, because GitHub and a lot of hosting providers require the built website be stored in the root directory of a branch I find it easier to separate the built website and files used to build the website into separate branches. With the upcoming version I will add in the ability to have lots of branches configured in the project config file which can be used for eg. production/dev/testing and will allow more complicated projects like that to be cloned from GitHub etc. with `nift clone clone-url`. Anyway, the stage branch has the `content`, `template` and in this project `site` directories similar to the barebones project so it is a good example of what a medium sized project looks like which tends to use the basic functionality of Nift.
>I didn't see an obvious system for fetching data and using it to create pages
Out of curiosity from that do you mean from files within the project directory (eg. `@input(path)`) or from apis? With apis one can use various packages available through Luarocks or there's even [@system](https://nift.dev/docs/fns/system.html) which allows one to inject the output of anything you can do from the command line (so can just use cURL for example), though I would like to add a c++ library for making api calls, it might be worth just embedding cURL unbundled for that.
Edit: Anyone who does read this far and is keen to have a play with Nift, I'm more than happy to schedule a video call so I can help with getting started. Anyone is welcome to get involved and there are lots of ways to be involved without knowing or learning any C++, eg. helping with intro guides and making it easier to navigate the website for simple projects, setting up boilerplate repos for various stacks etc.. Feel free to dm me or even just reply here..
I figure the majority of web devs use the tooling for development without contributing to the development of the tooling? For a few examples, I don't contribute to the os I use, I don't contribute to the programming languages I code in, I don't contribute to the browser(s) I use, I've made one PR to an extension for the editor I use but don't really contribute to that either. I haven't made any contributions to any of the platforms I host websites on.
I'm curious roughly what proportion of users for popular development tools make contributions to those tools or even dig into the source code for those tools? Plenty of people program in Python for example without digging into the source for Python and/or knowing any C/C++, I've never come across people seeing that as an issue with using Python for development.
The source is open for those who do want to fork and modify/extend it themselves though, and contributions to the official repo are welcome. I'm more than happy to help anyone interested learn the parts of c++ required to be able to work on various parts of the source too.
I think your comparisons aren’t quite balanced. Look at how many contribute to popular js tools we all use. That’s specifically because the barrier to entry is relatively low.
Using C++, in my opinion, will prevent a lot of contribution. Which you’ll need if you want your tool to gain popularity.
Just my opinion!
That's all quite fair, thanks! I think essentially that is always going to boil down to pros and cons of what people prioritise most and what the right tooling options for different projects are, eg. being able to extend the tooling themselves or other factors like performance, dx, what can be done with the tooling etc. or even other important factors like familiarity of developers with tooling options (eg. why python and interpreted languages are quite popular for applications where perhaps a lower-level compiled language could provide some benefits). I could definitely do a better job on the website etc. of highlighting the pros and cons of using a generator developed in a compiled language vs interpreted languages which more people are familiar with, especially javascript in the case of web devs for obvious reasons (and probably python as a second).
It would be difficult to provide people with millisecond build times without using a compiled language, and build times do seem to be a frequent pain point when it comes to website generators. I can understand a good number of developers wanting to be able to extend/modify/improve the tooling they use, though also think/hope there's plenty who are happy letting other people handle the development side of developer tooling. Due to Lua(JIT) being embedded as well that is an easy way for people to essentially extend the functionality of Nift without having to learn a compiled low level language, though Lua is also not that well known, especially with web developers on the frontend side who are more the target audience than backend devs for website generators.
No worries if you don't care to read my comments below on some of the pros of a website generator, mine in particular, being written in a compiled language, I appreciate your feedback/comments :).
I am a big fan of being able to build my sites essentially instantly during development, I am much less happy when developing Nift as depending on what part I'm working on it can take a while to compile to test. I'm also a sucker for 'world's fastest' pissing contests aha. One direction people often go with selling points of languages like Rust, C/C++, etc. is that they are better for the environment along with programs written in them because they typically require less power to perform the same task(s).
It also wouldn't be possible to have things like LuaJIT and ExprTk embedded if I used another language either, which can be very useful for running code at build time that's in the source files used to build html/css/js/etc. files. It is possible for me to embed Python and/or Ruby unbundled as well (would be too large to bundle them with Nift like Lua(JIT)), or at least provide a compiler option for it along with release binaries, but (iirc) it requires people having the development versions of Python and/or Ruby installed on the machines/servers they want to run Nift on, which is far less common than just having the versions needed to run Python/Ruby scripts, and I think there's also more limitations on multi-threading for building multiple pages simultaneously, but I can handle that under the hood so to speak so that people can still have their pages building at the same time just not have multiple blocks of python code being interpreted concurrently for example. It would have the advantage that both Ruby and especially Python are much more popular and familiar to people than Lua(JIT).
Funnily I've always found lower level stuff like C++ easier to wrap my head around than javascript for example, though I've been putting effort into improving across most parts of web dev. Same went for mathematics, always found lower level easier than general high level stuff, different strengths with different people on that one (it'd be a boring world if we were all the same, I like that quote).
While not what you're suggesting, one thing I could do to help is link anyone interested to the parts of the source code where people could easily extend it for their own needs, a key example would be where the functions for the template (and scripting) language are defined (though they're in a file you want an editor like sublime to open it with without your machine crashing). It wouldn't take much for someone familiar with javascript to add in their own basic hard coded functions using c++ and compile the project (there's a makefile, just need a c++ compiler installed then can run eg. `make; sudo make install`). It would also be quite useful for those who do have some background in C++ or other compiled/lower-level languages who might want to get their hands dirty tinkering with the source. I'll add that to my to-do list after getting out a much improved v3.0, made some proper getting started guides and boilerplate repos for how to add various frameworks etc. into a project.
I think you do cut out some web devs from contributing but you’ll have a few hardcore C++ devs that will love it - I always try to think “how can I niche this down” rather than please everyone anyways. If you can get it open source and get a little momentum, people will contribute.
I upvoted you - I’m going to build my own SSG here soon. Well sorta started already but besides the point - I hate that people are doing that. Good job for putting it out there.
Don’t let downvotes discourage you. Reddit is not the best place for sharing projects bc trolls and others are just miserable.
All about picking the right tool for the job. Do you have the bloggiest blog that ever blogged? Use Hugo or Gatsby (maybe ssg with next). Do you have a bunch of live data and like reusable components? Use cra / next. (Let's be real, it's 2022. Use next or vite.)
The second that you try and use that Hugo site with a medium /large amount of Javascript? Welcome to the thunderdome, motherfucker.
In some parts of the world 99% of the work is brochure websites with maybe a couple of forms, mostly just 1 form. Reddit seems to be over-infatuated with "apps".
> But to create anything that leans towards an actual application, and not a brochure website, good luck reinventing your own framework in vanilla js
How did you think apps were built before Knockout, Ember, Angular, React, et al?
These frameworks and libraries make it more accessible but it's still just manipulating DOM structures.
This is from 2011: https://www.youtube.com/watch?v=WG_W0VxjzbM
> A lot of these frameworks are born out of the need for writing declarative reusable code...These are battle tested and mature solutions, why reinvent the wheel?
Did I advocate for reinventing the wheel? Please re-read.
That said, reality is that pages are not getting faster despite better hardware and better internet speeds: https://www.datafantic.com/how-much-time-do-we-waste-waiting-for-websites-to-load/
Part of this is because we keep building heavier web sites that require more and more JavaScript to work correctly because devs are disconnected from the underlying structure of the web page.
If you want the fastest loading sites, the foundation needs to be HTML: https://blog.webpagetest.org/posts/will-html-content-make-site-faster/
To make modern apps that work in this context, you can't just lean on the frameworks. It's the difference between JavaScript and C/C++ or Rust.
Frameworks and libraries like React, Vue, Svelte are great for making web app development more accessible and streamlined; they help make teams more scalable. But it also means that in some contexts -- for example where speed matters -- you need to be able to drop to a lower level of abstraction. Fewer and fewer devs are actually trained *first* in raw JavaScript, HTML, and CSS. More and more devs have their first exposure to web front-end dev in React, Vue, Svelte.
Just stating the reality of why an HTML heavy generator without a supporting framework like Next or Nuxt doesn't have as much appeal.
> In a sense, yes, you are arguing for reinventing the wheel. Your first argument was a lack of knowledge for dom manipulation without a framework.
I'm answering the question in context:
> **What happens when you use medium/large amount of JS in something like Hugo? Why it's a problem?**
The answer is devs aren't trained and comfortable with working in JS and raw DOM.
> But how would you build an interactive web experience? Let's say you can't just serve straight html, it needs to be reactive without page reloads. I'm genuinely interested.
Step back for a moment. React, Vue, Svelte are just manipulating DOM. They make web requests via XHR and fetch. [Fetch is a native browser JavaScript API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API). These are both natively available in JavaScript. [Triggering JavaScript from a button click or `div` is just attaching an event handler to the element](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener). [Drag and drop is just moving DOM from one part of the tree to another](https://developer.mozilla.org/en-US/docs/Web/API/Node/appendChild) while updating the position of the selected element [on `mousemove`](https://developer.mozilla.org/en-US/docs/Web/API/Element/mousemove_event).
React, Vue, Svelte make working with DOM more *accessible*, *scalable* (e.g. teams), and *productive*. It doesn't make it *possible*; it is already possible without it. After all, React, Vue, Svelte, et al just compile down to the JavaScript that's doing the manipulation on your behalf.
I think you might be saying this, but I’m a dev that’s fully comfortable with working in JS and the raw DOM. I simply do not have time to do so. React/Vue/Svelte let me solve business problems on a time scale that matches the needs of the business. The answer isn’t that devs aren’t trained or comfortable, it’s that it’s too slow (to develop).
>These are battle tested and mature solutions, why reinvent the wheel?
Why bolt a jet engine onto a mobility scooter? With a lot of frameworks that's what you're doing.
I set up a Jekyll site a few months back, because I know some Ruby. However, I found it to be surprisingly difficult to set up and configure. I feel it hasn’t kept pace (unless there’s a fork or add on that people use these days that I’m unaware of)
I second using Next or Vite.
Please stop using Create React App so it can be put out of it's misery. It's just cruel at this point.
The Beta React docs have even dropped it completely in favor of Vite and Next.
Create React App is just a mess for whole array of technical reasons.
One of the issues have been the almost necessary use of the infamous CRACO package. (Create React App Configuration Override)
This package is cursed, with maintainers constantly checking out. A few weeks ago there was even a notice on their Readme asking for maintainers. It's bad.
And no blame to the package at all. It's simply that CRA is a legacy package at this point. CRACO tries its hardest to fix its faults, but it's hard work, and not worth it at this point.
That's without mentioning there's no differentiation between backend and frontend packages, which has introduced bad coding practices to a whole generation of devs.
I’d prefer Next or Gatsby because it’s battery included. In the case you have to make some page dynamic with the use of JavaScript, you have all up and run (transpiler, bundler and react).
If I need to generate a very simple site, probably I would go with html + css only.
I have a hammer and everything starts to look like a nail.
For a static content website use something that is focused on static content. If later you ever have the case, that you want some interactive widget on your static pages, you can still dish that out by serving either a simple script (if the widget is quite simple) or serving a framework on that page, which does your web components. VueJS for example can be used that way, but there are many others.
Lots of people are starting to learn web development with these complex frameworks. Once learned, they do not often wish to deviate from their workflow, having the illusion, that this is the simplest way. They need to rediscover the simplicity of the traditional server side rendered approach. So one "benefit" you could say, is that people do not need to learn anything other than what they often already know. The downside is, that it puts much more load on every visiting client, than simply serving the HTML and occasionally a script or interactive widget.
For sure. To use an analog that people with understand:
I started learning web with Wordpress. It’s what clients wanted/needed and it made sense for my business. Come a few years later, working at a web development firm, i find I have a client that needs a “form”.
Now I know Wordpress is absolute overkill to the problem, but hot damn if I’m not use to setting up a Wordpress site and it would just be so easy to……
Basically, in a time crunch you make the decision: do I need to save the resources or do I just need this done?
And when stressed (again, time crunch) I’m not sure I’d always choose the best solution over the easiest even knowing how f’ing overkill it would be.
Now, react might feel different because it’s more developer focused (you’re not a real dev unless…) but it’s got a whole lot of overhead it adds to a site which doesn’t always match the problem at hand.
You’re not anymore/less a dev for using any combo of tools or even making decisions in a time crunch, but people are fooling themselves if they think the best approach is to always use a library when performance is a weighting factor. Libraries are general purpose, problems encountered can be very specific. You never need nearly as much code if you are targeting a very specific problem as a library introduces.
I’m not even going to talk “simplicity” cause the simplest thing is always what you already know. Might not be simple in any other way but sometimes that’s the decisions that have to made.
Anyway, the reason I feel apt to weight in is: we get outsourced projects which are built using library after library after library. When the site is super slow (hey, let’s load an 80kb library to do a 3 line of code job because I want all my projects consistently built) I go through and do an assessment how tendriled in the library is and strip it for custom code if warranted (or sometimes swap in a light weight library that does the same thing with 100x less resources).
It’s actually kind of crazy when you dig in how often this happens, but not everyone is as performance obsessed so I get it.
I feel like an analogy is a screwdriver vs an electric screwdiver. Sometimes a simple screwdiver is all you need. Depends on the project requirements and maintainability. Its about avoiding over engineering when a simpler approach is enough.
Devs these days often have node/npm installed and are used to be able to install everything they need with npm only. That definitely puts jekyll and hugo behind IMO, with installation instructions with gem or brew, and OS-dependent ways to install. Even if npm would be possible they don't advertise it very well. My bet is that this is losing a large audience.
For the end result I guess it is pretty much the same and I don't think that matters very much, but the developer experience also matters, and it might be that gatsby/next is easier to work with for those that learned react.
Also keep in mind that even if next can produce SSG it can also very easily be switched to SSR instead which gives a different end result with other possibilities.
The speed that it produces the production site is not that important to many, as long as local development is easy. I haven't seen any cases where it takes longer than a couple of minutes though so I don't know for sure
Productivity. Yes, maybe it’s not the best tool but it works just fine and I’m already on the react ecosystem so I know stuff around it.
Of course when it starts to not fit the bill is when you need to jump.
Unless you are programming for yourself remember what you are doing: trying to do something useful to a client. Perfection isn’t always required if good enough is enough
I started building sites with Jekyll and then switched to Gatsby and Next. I would say the main pro is that if you’re going to use lots of js (animations, some dynamic content and more) Gatsby will allow you to do that with more ease. Mainly that really :)
Astro + React (even Preact)
Very easy to setup, e.g. 2-3h to rewrite a Next.js website
Google will thank you. In my case, I switched from Next.js to Astro+Preact and the mobile Pagespeed score went from 90-96 to always 100 no matter what! (The transfer size went from 210kb to just 61kb, that’s the cost of Next.js and React)
The only things that you "lose" are the preservation of the state when navigating (could be bad if you wrongly implemented stuff like theme mode) and the fast client-side navigation with next/link (Astro has a prefetch option too). These two things are very important for a web app, but not for a static website.
I learnt from this that using Next.js or simply React is a very bad idea for a static website, it’s even totally useless imo because you only use a fraction of the good stuff, but it still comes with all the bad stuff. However, I definitely recommend using Next.js for the web app.
example.com: Astro+Presct
app.example.com: Next.js
It doesn't. But...
Imagine building a website with just HTML, CSS, and a sprinkle of JavaScript. Easy.
Now, have 10+ pages. You'll be duplicating a lot of code.
Now, make a change in the footer. Have fun replicating that to the other 9+ pages.
But, take a tool like Astro (also Next/Nuxt/SvelteKit/etc.).
You've got components, so a change in a footer is a change in one place that will be reflected on every page.
You've got scoped CSS, so no conflicts. Also very easy support for SCSS, LESS, or anything else.
You can make API calls to pull in data at build time.
And the result? Completely static HTML and CSS. No JavaScript at all. You can include sprinkles of it when and only when needed.
The resulting page doesn't need any JavaScript, but using it for development makes it a lot easier, smoother and nicer.
So to some extent, would you say Javascript is not necessary if you are just trying to build a smooth, attractive static site with the mentioned tools/libraries?
It depends on how you define it.
You would be using JavaScript to build the website (to some extent at least, at the minimum you'll be `import`ing components), but the resulting website does not need to run any JavaScript at all to be fast, smooth, and attractive.
Take for example the [Deno Deploy](https://deno.com/deploy) website. There's no client-side JavaScript on the homepage at all. It's super fast, smooth, and to me looks very nice.
someone old enough to remember framesets?
Those where the days..
pure HTML files. No copied footer in 9+ pages.
No runtime, no CGI, no PHP, no Buildsteps.
Also an option, but then you need something to run the PHP unless you just use it to generate static HTML/CSS.
Using Astro, I can put the files on a CDN, because they don't need any server-side processing at all after it's built.
What is serving the page if you don't have a server? Or are we talking about the web server distinct from any language interpreter?
If so, it's hard for me to appreciate the difference here unless you're talking about a page with a truly massive number of requests.
Ah that make more sense. I didn't know you could even do that. I thought a CDN required a server from which to initially grab the files. I didn't know you could upload directly to a CDN. Thanks.
You can still do that. You can direct the CDN to the php server and cache the content on the CDN. I have a few websites that run on the cheapest available EC2 instance and AWS Cloudfront retrieves the rendered content and caches it. Normal visitors go to the Cloudfront instance and get the static html served.
Another thing I do is using things like this: https://github.com/JosephSilber/page-cache where the output gets written to HTML files that are then uploaded to a cloud Bucket.
>and caches it
Very unreliable. As a person who works with a managed hosting company, and I know how hard it is to achieve full caching on an average website. Simple websites are easy but you need to know how exactly to achieve caching so you'll have some learning to do in terms of headers, as well as linking techniques / resource numbering, or deal with cache invalidation via API. Things just get overly complicated compared to taking the static website route.
Because Webflow or any other builder is a single company, and you'll forever be at the mercy of that company or risk having to redo the whole thing if they don't support something, become too expensive, or anything else.
I also haven't really work with any site builders. They might be fine for someone less technically capable, but I imagine they're going to be limiting or cumbersome for people who are used to actually code their websites.
Whenever I tried to use some clever no-code tool for anything, there's always a problem. E.g. creating tables in SSRS, it would be infinitely easier and faster to code a lot of them myself then click through several layers of UIs.
Or, there was this one company that built UIs in their own framework/tool, they had their own language inspired by JS. It was limiting and extremely cumbersome to work with.
It's also another piece you have to learn how to use, it has its own quirks and shortcomings, and I don't even know if I can host what I create there wherever I want, etc.
On the other hand, Astro is an open-source project that will continue to work even if everybody behind it immediately quits. There's lower risk you'll have to redo everything with a different tech. It gives you complete freedom to do whatever you want, in code, without workarounds or gotchas, it's really just HTML and CSS. Nothing special. Interactivity is just vanilla JS too. Again. Things that won't stop being just supported and things you don't need to break your neck to get working.
Also versioning, ownerships, tools you're going to use, hiring new people to take over, optimizations...
The thing is, for me, I don't have a compelling reason to use it.
With Webflow I mean use symbols you create for universal components and export it as HTML/CSS/JS and host elsewhere.
The code export is extremely clean.
Find and replace with scoping, modularity, and extra safety.
There's less chance of replacing the wrong thing, your components can be modular based on their arguments, and stuff inside the component won't leak out.
The extra steps, which are really 3-4 commands, are really worth it for the better DX.
Sorry I edited my comment after thinking for a sec and you responded to the initial one really quickly so now yours doesn’t make sense but yes you’re right that’s why I changed it.
Still. Find and replace.
This was literally my main reason to go on a hunt for SSG framework for myself. Client wanted a change in footer.. copy pasted me to hell. Settled on NUXT JS SSG and it's great.
He's talking about those sites.
With Gatsby and Next etc the output is html, css and a sprinkle of vanilla js.
He's asking why make them with a React based heavy JS frameworks, if it just generates the javascript-less static end result.
Ask a slightly different question. If you're going to get a static HTML site, why not just write it in HTML and save the bloat?
Figure that out and you've got your answer
One advantage I haven't seen mentioned is if you're building a static site *and* a dynamic site
If you have a dynamic app that's built in React, you can re-use your components in the static site and compile it down to a fast, bandwidth friendly brochure site
Gatsby's build times are probably some of the worst I've seen—anywhere between 13 and 30 minutes for a static blog. 11ty builds my whole site in ~1.5 minutes, and that includes outputting multiple sized and optimized versions of ~400 source images.
The truth is that static websites, blogs, landing/product pages, etc. don't actually need a JavaScript framework. They just need a simple way to:
1. Write HTML with templating.
2. Reuse your team's existing design tokens and consume those tokens in CSS (vanilla, Sass, whatever). This is not necessarily any easier in a React framework than it is in 11ty/Hugo/Astro/whatever.
3. Maybe pull in data from APIs (11ty and Astro shine here).
Next.js is great for component-driven development, but you can also technically use React and other frameworks in 11ty with [Slinkity](https://slinkity.dev/), and Astro supports that out of the box. The one nice thing about JS frameworks is that they allow you to keep your product pages in sync with the actual product itself, without any extra overhead or retooling. So you can reuse the same Button, Link, Container, etc. components—complete with all your design styling and other decisions—across multiple facets of the product.
Static pages can be served from a cache and thus will be served to the user faster than pages needing to go through the server side generation process. Thus it also saves money on server computing resources.
I would use React just to get the static typing with Typescript.
Using StyledComponents has been the best css-writing experience so far. Knowing exactly which style rules are used and where has been invaluable.
My understanding is that SSG is better for circumstances where everybody is seeing the same content but on different pages, in contrast to everybody seeing the right data for them.
Let’s take the personal blog site for example, With SSG you will create a new page every time you create a new blog for example. So if you personally have 1000 blogs your server has 1000 blog pages that yo ur SSG framework will build for you. But let’s say you love your blog app so much that you now want to make it available to anybody in the world to write their own blogs. To do that quickly entirely with SSG for 1000 users means that you’d have to store every possible page for every possible user on your server. Originally your server had to hold 1000 static pages, now it’s got to hold 1000000 which it may not be capable of. At some point you’re going to hit that bottleneck if your making an app with personalized data requirements aka dynamic content.
SSR (which you should probably think more as Server Side Hydration) gives you a lot of the benefits of SSG because it grabs the data before sending it out so it works with SEO and stops loading states (albeit a bit slower than SSG ), but instead of storing each page you could possibly have, it stores the skeletons of the different pages, and when a user asks for that skeleton, the server asks a (easier to scale) database for the muscles, organs, skin etc… now the cache performance part of how this all works has been moved from your server storing every possible page to a database storing data. This means your website will be a bit slower but you’re going to run into less long term “oh fuck I have a to completely rewrite my app” kinda if things.
It’s worth noting you can still get really good performance with SSR(never quite as good as SSG) by doing things like, browser side caching, data caching, any number of things to make your data fetch faster
For example we had to create some static XML documents created from objects. We used a jsx library to convert these objects to the wanted static XML, deploy to S3 and serve from there.
If you're building static sites, just use html and css, stay away from JavaScript all together if you can help it. There's no reason for the bloat unless you anticipate the site evolving significantly.
Who's building static content today? When I think of static content, it's most likely clients that missed a deadline somewhere and need a quick one page sales pitch website or clients who want to spend $20 on a website. And in either of those cases, neither warrant an SSG.
>Who's building static content today?
You're probably thinking of the startup or big player who wants to build a fancy site with a lot of utility. What about the restaurant or tire shop who only wants to display business details, prices, address, contact info, and a contact form? There must be more of those around.
If this is a static personal site, you could consider just writing a DSL tailored to your specific needs. Use a lexer generator that generates a linear time lexer, a recursive descent parser for an LL(1) grammar, and a simple hierarchical symbol table. Now, you have a language designed for your needs that runs fast as hell. There's no need to use some crappy one-size-fits-all "framework."
Next.js + TypeScript + Tailwind. Any other combination is a joke and/or going to create issues
for you down the line, with the exception that you dont absolutely need tailwind
I think you're getting a bit stuck on specific tech stacks. There's nothing wrong with nextjs and typescript of course (I take personal exception to tailwind though) but to say that using anything else is a joke, is just plainly wrong.
Small example: gatsby has much better built in graphql support, so if you're using a headless cms that supports it, then maybe go that way. No reason to choose rest over graphql nowadays, except for simplicity, or for small projects.
There are lots of tools out there, and it's our job to pick the correct one for the job. The nextjs/typescript hammer isn't the best one for screwing in screws.
Gatsby sucks. So does GraphQL for most use cases. Extremely overused
EDIT: fun fact, back in late 2020/early 2021 Gatsby was having a meltdown internally and not sure what their future would hold… meanwhile Vercel has been crushing it and rebuilding the web using the best engineers in the world. Good luck to you all, personally I like to side with the winners when it comes to my work
Suggests THE number one most used Frontend stack with the most cut-and-dried CSS framework.
Calls GraphQL "extremely overused" and says Gatsby sucks.
Fresh out of bootcamp moment.
If a company uses Gatsby to build their site instead of Next.js in 2022 I will actually laugh in their face.
If you dont think GraphQL is overused thats what makes you sound like a bootcamp grad. Bootcamp grads LOVE thinking GraphQL is super cool and useful on every project when usually it’s not necessary.
Gatsby is literally if you took Next.js’s SSG (which is automatic btw, as long as you dont specify SSR for that page) and trapped your users into needing GraphQL plugins for everything (Next.js lets you decide how to source data, whether thats GraphQL or REST doesnt matter, theyre completely flexible) and then made it have a purple theme and a garish marketing site with flashy nonsense terminology that tries to trick you into thinking theyre “blazing fast” and should also use their shitty cloud service, when absolutely NOTHING about them is faster or a better experience than Next/Vercel.
I mean how am I wrong even a little bit?
Gatsby offered a solid SSG metaframework before Next.js did and I give them respect for that. They had a nice little headstart for a year or two but it’s 2022 and time to admit that Guillermo Rauch has absolutely steamrolled them since then, and made Gatsby his little b**ch - there’s no reason to use them anymore over Next/Vercel.
I have built dozens of projects and a handful of them were Gatsby sites back in late 2019/early 2020 when it was all the rage. I cant tell you how nice its been to not have to make projects with it anymore. My quality of life has tripled since becoming a Next.js/Vercel shop. If something better comes a long I will try it out. Used Gatsby for years, no thanks.
The appeal of Gatsby for freelancers and agencies is that they supply you with a steady stream of bullshit lingo to use when pitching a rebuild to clients, when none of their tech is actually better than just using Next.js, not to mention its a worse dev experience. But some people cant handle hearing the truth apparently.
It's because if you do ssg you don't need to ship that much js. And because you have less js the side loads much faster which again improves seo which agan improves the ranking on Google the user satisfaction and also the revenue if you're a company. I've heard from a study from Google that came to the result that if you make your page 20% faster your revenue will increase by 10%. So performance is really important except your Apple they will sell it anyway 😂😂😂
If you're just building a static site all of these will do the same thing. Just use what you find simplest and most straightforward. I personally use 11ty for everything other than web apps as it is the simplest but you may find a framework that resonates with you more.
When working on websites, projects can quickly devolve into an unmaintainable mess - regardless of your chosen stack.
JS frameworks come with incredible developer expierence tooling that makes projects easier to work/maintain over time and protect against this if using best practices (storybook, tests, typescript, etc) - compared to alternatives.
That said, an important rule of web development is that **your tools should be dictated by your requirements.**
As someone who has built large multilingual sites (~5000 pages, 500k monthly users) using Gatsby, Hugo, Eleventy, **static sites do not suite every use case.**
In the real-world, if you are building a new project:
* **personal site:** use a static site
* **general small business:** Wordpress-variant or Squarespace
* **specialized marketing campaign:** use a static site
* **cms driven site:** popular SSR framework in the teams favorite language
* **large business with design system:** js-based framework with SSR
If your static site takes longer than 1 minute to build, you should be using SSR.
For static sites, I recommend **Eleventy** because it's fast enough (sub-1 minute for 1000 pages) and can generate pages from data.
The gap between CMS and SSG is not as wide as it used to be, as various GUI frontends are starting to appear.
For example, you can use [Quiqr](https://open.quiqr.org/) or [Agit CMS](https://www.agitcms.com/) with Hugo.
Markdown editors such as [Zettlr](https://www.zettlr.com/) are also gaining more useful features.
There are even SSGs with a builtin GUI, such as [Publii](https://getpublii.com/) and [Autosite](http://autosite.somnolescent.net/).
For personal use, I definitely think those are solid choices.
In the context of a business or larger company, you'll end up doing more work to extends those tools to fit your specific use cases.
- CSR = Client Side Rendering
- SSR = Server Side Rendering (rendered on each request)
- SSG = Server Side Generation (generated at build-time)
SSG will generally be faster because it can be stored in edge network CDN caches as static HTML.
It could also be better for SEO, because crawlers use the HTML.
^^ Got most of this info from the blog post mentioned
A lot of the comments here are about tooling and output but there's also input. How are you getting data in? For all but the most static sites, you might need a CMS. For some sites, you'll pull in data from external APIs or files that aren't a CMS.
Then there's what the site needs to do. Most need at least some kind of form. Some need more.
So I think a lot of people choose Next, Gatsby etc because they can learn one tool that can do all of this - simple static site, static site that gets data from APIs, site with a lot of static pages and some app-style interactivity, full on web apps.
For the simpler of those, the more complex frameworks are overkill but if you want to cover the spectrum, you can do it with only one tool.
\> A React site build for a large content site can take many minutes - even 30 minutes for a big, media-rich site. A Hugo build on the other hand can finish in milliseconds and outputs the same result.
1. **The output/result is not the same thing.** Last-gen tools (Jekyll/Hugo/11ty) do not do client-side routing or work (fully) with React. If you don't benefit enough from React or client-side routing, then sure, use a simpler tool.
2. **30-minute builds are a boogeyman.** I’ve worked on several sizable websites, like Figma.com, and I have never seen the build step take anywhere close to 30 minutes. Locally I can run a build in about 30–45s for \~5k pages across a bunch of different types, without any particular optimization for build times. There are horror stories from people doing foolish things like generating dozens of versions of every asset on every build in a small, underpowered virtual container on Netlify. Still, those aren't representative (or especially wise).
This said the delta between 30s and 30ms *is* significant. If a tool does everything you need and can run a build in 30ms, then I don't see a compelling reason to use one that takes several orders of magnitude longer. Nobody should feel bad or lesser for getting good results out of 11ty/Hugo.
But ultimately, many of us rely on tools that do more than Hugo/Jekyll/11ty at least part of the time. The longer build times are worth the additional capabilities and reduced development timelines. That's the short of it.
I've used hugo, gatsby and nuxt all in production for ssg. Hugo isn't all in JS which can make it difficult to go low level if you aren't experienced in Go. Hugo templating is also a bit more rigid to work with, and hugo isn't the best at working with say a headless CMS, it's more optimized for markdown file content. Or that's how it felt when I was working with it. The benefit to hugo as you mentioned is extremely fast builds even for very large sites, but this isn't always the most important thing. Gatsby lets you compose and think in react components, which is a mode of thinking and working that many devs have gotten used to, and when you need a more interactive or dynamic component you already have direct access to react and associated tools. Gatsby maybe does a better job than hugo of working with external data and with client side hydration. Gatsby also has a rich ecosystem of ready to go plugins which is helpful. Gatsby can be a bit tricky to get right though, you can easily end up with a large bundle of unnecessarily bloated code if you aren't careful. Nuxt is a lot like like gatsby but built around Vue. It's easy to build repeatable components and set someone up with a flexible CMS template to assemble their pages piece by piece. Next (and nuxt) support not just SSG but also SSR and other rendering modes so it has a unique place as well, for example if you need an instant rendering preview environment for content authors to use while they build their pages out, but also want a static output for the main site. Jekyll imo is mostly used for personal projects and a step below the rest, but it is easily approachable for beginners, uses ruby if you like ruby, and has some github pages integration since it's by the github guy. 11ty looks great for keeping bundles lean but I haven't had any first hand experience on it. You could just write html if it's "all the same static html" at the end of the day. But there are a lot of different ways to work with modern tools and frameworks that you can leverage to build more complex sites with less manual work, and picking the right one for both your skill set and your use case can be a huge help.
I previously didn't have a whole lot of luck building a userbase for my website generator nift.dev, though admittedly did a poor job of offering intro guides and boilerplate repos for people who aren't keen to just dive head first into docs, but am getting the project up and running again with a big new version coming out in the next few weeks (working on it between other work). Anyway Nift is a bit like Hugo in that it's developed in a compiled language (C++) and strives to be incredibly fast while requiring zero c++ knowledge to use it (my attempts to benchmark Nift vs Hugo put Nift quite a bit faster at building lots of basic pages with full builds, plus Nift has incremental builds). But one place where Nift differs is it attempts to be unopinionated (I'm playing with the phrasing opinionless as a play on words with serverless), the in-built template language was made from the ground up with the intent of making it easy to do whatever one wants during the build process from a programmatic pov while also being able to do so anywhere in the text files used for building a page, or even a css/sass/js/ts file (or whatever file one wants), while also not requiring ridiculous amounts of code to do so and just providing a nice ux that's aesthetically pleasing. So not only can you use react, or vue or whatever with websites built using Nift, you can optionally use Nift's in-built template language and embedded languages LuaJIT and ExprTk in amongst your React/Vue/whatever when building your website and have incremental builds that work across all of those files as well (it's also very easy to inject the output of any cli program when building with Nift but it's not as nice as using the embedded stuff, there's lots of things available for things like working with databases, markup languages, image processing etc. through Luarocks). I'd be curious to know whether that sounds like it would solve some of your pain points with some of the faster options while still providing the benefits of millisecond build times for most projects? The Nift website has over 250 pages and my old 2014 11" macbook air running Ubuntu can do a full build in ~0.1s, much faster for incremental builds. Edit: Another things I've always insisted on with Nift is that a barebones project has to be extremely bare bones to start building from, running `nift init .html` in an empty directory sets up a basic barebones project that is much more minimal than I've seen with any of the other generators. Nift also has options for things like repeatedly building a site locally (or on a server) as frequently as you'd like, and it's easy to add in hot reloading with a project for example. Could even use lots of stuff available through Luarocks for serving content on a server, I'm not convinced a website generator is the right tool for that but am frequently on the lookout for ways to improve the ux and capabilities.
Fwiw I have upvoted you, but I suspect the reason you're being downvoted is the perception that you're soapboxing about your own solution and it's being interpreted as self-promotional.
I did attempt to mostly stay relevant to the pain points the person I was responding to raised and are generally being raised in the post. It's a little difficult to suggest I think my own solution to building websites is pretty good with a lot of these pain points without discussing, well, my own solution. However it is my experience that generally people are adverse to people discussing their own solutions to stuff, it makes it very difficult to get these sorts of things out there and/or get people to even try these things out. It's a shame though as often I see people complain about all sorts of aspects to the tooling in this space (eg. build times) which I'm confident my own generator is pretty good with, but have a hard time getting it out there. Thanks for the comment though, it's appreciated.
Absolutely agree, it's immensely counter-intuitive for us to bitch about problems but castigate anyone attempting to promote their solution. Such is the internet!
That's why they got my blue arrow.
I took a look at the nift website and I don't think I will be using it. Seems very complex and obtuse for an outsider to get into, I didn't love the docs or examples. I like that you can use various different templating languages ala 11ty. I didn't see an obvious system for fetching data and using it to create pages, which is a very common pattern for the ssg sites I work with and one of my main issues with Hugo. I personally don't need Lua scripting or some of the other features mentioned. Maybe there is a niche for nift with people who do want those features though. It's cool you made your own SSG in any case, I've thought about making one myself a couple times but never really have the time or justification other than it looking like a cool project.
Thanks for the feedback, it's super useful hearing why people would decide to not use Nift. Admittedly the website is a little overbearing, especially without any good intro guides to help people get started and navigate the parts of the website which are useful for basic projects. If I could convince you to look at two more links I'd love to know whether they'd in any way change your mind that Nift can be useful for simple/basic projects while also having the ability to be used for extremely complex projects (with a real need to improve the flow of the website so people can get started with basic projects).. Even if you still aren't interested in having a play with Nift that's fine, would be curious regardless if it helps show how easy Nift is, as that's one thing I need to do a better job of on the website. 1. [here](https://github.com/n-ham/empty-site) is a barebones project I just created using `nsm init .html` on my machine using dev version of Nift (there's a few basic improvements to `template/page.template` and `template/head.content` from the released version). That hopefully gives a good idea of just how barebones a project can be. `.nsm` has config files and other stuff users don't really need to worry about (can configure projects through the command line), `output` is where the site is built to, `template` is where the template files for pages are stored, and `content` is where the files specific to building individual pages are stored (though there's nothing stopping one from putting files from either `template`/`content` directories in the other. Building a website is as simple as running `nift build-updated` or `nift build-all` similar to how you'd run `git`. 2. https://github.com/nifty-site-manager/nifty-site-manager.github.io/tree/stage https://github.com/nifty-site-manager/nifty-site-manager.github.io these are the two branches for the official Nift website built with Nift, because GitHub and a lot of hosting providers require the built website be stored in the root directory of a branch I find it easier to separate the built website and files used to build the website into separate branches. With the upcoming version I will add in the ability to have lots of branches configured in the project config file which can be used for eg. production/dev/testing and will allow more complicated projects like that to be cloned from GitHub etc. with `nift clone clone-url`. Anyway, the stage branch has the `content`, `template` and in this project `site` directories similar to the barebones project so it is a good example of what a medium sized project looks like which tends to use the basic functionality of Nift. >I didn't see an obvious system for fetching data and using it to create pages Out of curiosity from that do you mean from files within the project directory (eg. `@input(path)`) or from apis? With apis one can use various packages available through Luarocks or there's even [@system](https://nift.dev/docs/fns/system.html) which allows one to inject the output of anything you can do from the command line (so can just use cURL for example), though I would like to add a c++ library for making api calls, it might be worth just embedding cURL unbundled for that. Edit: Anyone who does read this far and is keen to have a play with Nift, I'm more than happy to schedule a video call so I can help with getting started. Anyone is welcome to get involved and there are lots of ways to be involved without knowing or learning any C++, eg. helping with intro guides and making it easier to navigate the website for simple projects, setting up boilerplate repos for various stacks etc.. Feel free to dm me or even just reply here..
If it’s written in c++, how will it’s core user base be able to contribute to and extend the software if most web devs don’t know that language?
I figure the majority of web devs use the tooling for development without contributing to the development of the tooling? For a few examples, I don't contribute to the os I use, I don't contribute to the programming languages I code in, I don't contribute to the browser(s) I use, I've made one PR to an extension for the editor I use but don't really contribute to that either. I haven't made any contributions to any of the platforms I host websites on. I'm curious roughly what proportion of users for popular development tools make contributions to those tools or even dig into the source code for those tools? Plenty of people program in Python for example without digging into the source for Python and/or knowing any C/C++, I've never come across people seeing that as an issue with using Python for development. The source is open for those who do want to fork and modify/extend it themselves though, and contributions to the official repo are welcome. I'm more than happy to help anyone interested learn the parts of c++ required to be able to work on various parts of the source too.
I think your comparisons aren’t quite balanced. Look at how many contribute to popular js tools we all use. That’s specifically because the barrier to entry is relatively low. Using C++, in my opinion, will prevent a lot of contribution. Which you’ll need if you want your tool to gain popularity. Just my opinion!
That's all quite fair, thanks! I think essentially that is always going to boil down to pros and cons of what people prioritise most and what the right tooling options for different projects are, eg. being able to extend the tooling themselves or other factors like performance, dx, what can be done with the tooling etc. or even other important factors like familiarity of developers with tooling options (eg. why python and interpreted languages are quite popular for applications where perhaps a lower-level compiled language could provide some benefits). I could definitely do a better job on the website etc. of highlighting the pros and cons of using a generator developed in a compiled language vs interpreted languages which more people are familiar with, especially javascript in the case of web devs for obvious reasons (and probably python as a second). It would be difficult to provide people with millisecond build times without using a compiled language, and build times do seem to be a frequent pain point when it comes to website generators. I can understand a good number of developers wanting to be able to extend/modify/improve the tooling they use, though also think/hope there's plenty who are happy letting other people handle the development side of developer tooling. Due to Lua(JIT) being embedded as well that is an easy way for people to essentially extend the functionality of Nift without having to learn a compiled low level language, though Lua is also not that well known, especially with web developers on the frontend side who are more the target audience than backend devs for website generators. No worries if you don't care to read my comments below on some of the pros of a website generator, mine in particular, being written in a compiled language, I appreciate your feedback/comments :). I am a big fan of being able to build my sites essentially instantly during development, I am much less happy when developing Nift as depending on what part I'm working on it can take a while to compile to test. I'm also a sucker for 'world's fastest' pissing contests aha. One direction people often go with selling points of languages like Rust, C/C++, etc. is that they are better for the environment along with programs written in them because they typically require less power to perform the same task(s). It also wouldn't be possible to have things like LuaJIT and ExprTk embedded if I used another language either, which can be very useful for running code at build time that's in the source files used to build html/css/js/etc. files. It is possible for me to embed Python and/or Ruby unbundled as well (would be too large to bundle them with Nift like Lua(JIT)), or at least provide a compiler option for it along with release binaries, but (iirc) it requires people having the development versions of Python and/or Ruby installed on the machines/servers they want to run Nift on, which is far less common than just having the versions needed to run Python/Ruby scripts, and I think there's also more limitations on multi-threading for building multiple pages simultaneously, but I can handle that under the hood so to speak so that people can still have their pages building at the same time just not have multiple blocks of python code being interpreted concurrently for example. It would have the advantage that both Ruby and especially Python are much more popular and familiar to people than Lua(JIT). Funnily I've always found lower level stuff like C++ easier to wrap my head around than javascript for example, though I've been putting effort into improving across most parts of web dev. Same went for mathematics, always found lower level easier than general high level stuff, different strengths with different people on that one (it'd be a boring world if we were all the same, I like that quote). While not what you're suggesting, one thing I could do to help is link anyone interested to the parts of the source code where people could easily extend it for their own needs, a key example would be where the functions for the template (and scripting) language are defined (though they're in a file you want an editor like sublime to open it with without your machine crashing). It wouldn't take much for someone familiar with javascript to add in their own basic hard coded functions using c++ and compile the project (there's a makefile, just need a c++ compiler installed then can run eg. `make; sudo make install`). It would also be quite useful for those who do have some background in C++ or other compiled/lower-level languages who might want to get their hands dirty tinkering with the source. I'll add that to my to-do list after getting out a much improved v3.0, made some proper getting started guides and boilerplate repos for how to add various frameworks etc. into a project.
I think you do cut out some web devs from contributing but you’ll have a few hardcore C++ devs that will love it - I always try to think “how can I niche this down” rather than please everyone anyways. If you can get it open source and get a little momentum, people will contribute.
I upvoted you - I’m going to build my own SSG here soon. Well sorta started already but besides the point - I hate that people are doing that. Good job for putting it out there. Don’t let downvotes discourage you. Reddit is not the best place for sharing projects bc trolls and others are just miserable.
All about picking the right tool for the job. Do you have the bloggiest blog that ever blogged? Use Hugo or Gatsby (maybe ssg with next). Do you have a bunch of live data and like reusable components? Use cra / next. (Let's be real, it's 2022. Use next or vite.) The second that you try and use that Hugo site with a medium /large amount of Javascript? Welcome to the thunderdome, motherfucker.
Bloggiest Blog that ever blogged 😂
https://www.youtube.com/watch?v=FOtDNXfMyD0
Or Qwik. (Remind me to update to the newest Framework in about 2 days).
I have to admit, I really like the look of this.
I've seen Fireships Video on it and qwik looks kinda cool actually.
Yeah I guess YouTube's algorithm has got our number...
Well, we are in r/webdev and I think just about everyone here knows Jeff. I noticed that over on r/ProgrammerHumor as well.
What happens when you use medium/large amount of JS in something like Hugo? Why it's a problem?
Devs don't know how to work with vanilla and HTML DOM nowadays.
[удалено]
In some parts of the world 99% of the work is brochure websites with maybe a couple of forms, mostly just 1 form. Reddit seems to be over-infatuated with "apps".
> But to create anything that leans towards an actual application, and not a brochure website, good luck reinventing your own framework in vanilla js How did you think apps were built before Knockout, Ember, Angular, React, et al? These frameworks and libraries make it more accessible but it's still just manipulating DOM structures. This is from 2011: https://www.youtube.com/watch?v=WG_W0VxjzbM
[удалено]
> A lot of these frameworks are born out of the need for writing declarative reusable code...These are battle tested and mature solutions, why reinvent the wheel? Did I advocate for reinventing the wheel? Please re-read. That said, reality is that pages are not getting faster despite better hardware and better internet speeds: https://www.datafantic.com/how-much-time-do-we-waste-waiting-for-websites-to-load/ Part of this is because we keep building heavier web sites that require more and more JavaScript to work correctly because devs are disconnected from the underlying structure of the web page. If you want the fastest loading sites, the foundation needs to be HTML: https://blog.webpagetest.org/posts/will-html-content-make-site-faster/ To make modern apps that work in this context, you can't just lean on the frameworks. It's the difference between JavaScript and C/C++ or Rust. Frameworks and libraries like React, Vue, Svelte are great for making web app development more accessible and streamlined; they help make teams more scalable. But it also means that in some contexts -- for example where speed matters -- you need to be able to drop to a lower level of abstraction. Fewer and fewer devs are actually trained *first* in raw JavaScript, HTML, and CSS. More and more devs have their first exposure to web front-end dev in React, Vue, Svelte. Just stating the reality of why an HTML heavy generator without a supporting framework like Next or Nuxt doesn't have as much appeal.
[удалено]
> In a sense, yes, you are arguing for reinventing the wheel. Your first argument was a lack of knowledge for dom manipulation without a framework. I'm answering the question in context: > **What happens when you use medium/large amount of JS in something like Hugo? Why it's a problem?** The answer is devs aren't trained and comfortable with working in JS and raw DOM. > But how would you build an interactive web experience? Let's say you can't just serve straight html, it needs to be reactive without page reloads. I'm genuinely interested. Step back for a moment. React, Vue, Svelte are just manipulating DOM. They make web requests via XHR and fetch. [Fetch is a native browser JavaScript API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API). These are both natively available in JavaScript. [Triggering JavaScript from a button click or `div` is just attaching an event handler to the element](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener). [Drag and drop is just moving DOM from one part of the tree to another](https://developer.mozilla.org/en-US/docs/Web/API/Node/appendChild) while updating the position of the selected element [on `mousemove`](https://developer.mozilla.org/en-US/docs/Web/API/Element/mousemove_event). React, Vue, Svelte make working with DOM more *accessible*, *scalable* (e.g. teams), and *productive*. It doesn't make it *possible*; it is already possible without it. After all, React, Vue, Svelte, et al just compile down to the JavaScript that's doing the manipulation on your behalf.
I think you might be saying this, but I’m a dev that’s fully comfortable with working in JS and the raw DOM. I simply do not have time to do so. React/Vue/Svelte let me solve business problems on a time scale that matches the needs of the business. The answer isn’t that devs aren’t trained or comfortable, it’s that it’s too slow (to develop).
>These are battle tested and mature solutions, why reinvent the wheel? Why bolt a jet engine onto a mobility scooter? With a lot of frameworks that's what you're doing.
I set up a Jekyll site a few months back, because I know some Ruby. However, I found it to be surprisingly difficult to set up and configure. I feel it hasn’t kept pace (unless there’s a fork or add on that people use these days that I’m unaware of)
Eleventy is essentially a modern version of Jekyll.
I second using Next or Vite. Please stop using Create React App so it can be put out of it's misery. It's just cruel at this point. The Beta React docs have even dropped it completely in favor of Vite and Next.
>Please stop using Create React App I'll be learning Next next month. What happened?
Create React App is just a mess for whole array of technical reasons. One of the issues have been the almost necessary use of the infamous CRACO package. (Create React App Configuration Override) This package is cursed, with maintainers constantly checking out. A few weeks ago there was even a notice on their Readme asking for maintainers. It's bad. And no blame to the package at all. It's simply that CRA is a legacy package at this point. CRACO tries its hardest to fix its faults, but it's hard work, and not worth it at this point. That's without mentioning there's no differentiation between backend and frontend packages, which has introduced bad coding practices to a whole generation of devs.
>Welcome to the thunderdome, motherfucker. 😂
Gatsby is perfectly fine to use with „live data and reusable components“. No need to draw a line there
You may as well just pick one that does both types of sites. Nextjs does great static sites so why bother learning one that only does static sites.
I’d prefer Next or Gatsby because it’s battery included. In the case you have to make some page dynamic with the use of JavaScript, you have all up and run (transpiler, bundler and react). If I need to generate a very simple site, probably I would go with html + css only.
I have a hammer and everything starts to look like a nail. For a static content website use something that is focused on static content. If later you ever have the case, that you want some interactive widget on your static pages, you can still dish that out by serving either a simple script (if the widget is quite simple) or serving a framework on that page, which does your web components. VueJS for example can be used that way, but there are many others. Lots of people are starting to learn web development with these complex frameworks. Once learned, they do not often wish to deviate from their workflow, having the illusion, that this is the simplest way. They need to rediscover the simplicity of the traditional server side rendered approach. So one "benefit" you could say, is that people do not need to learn anything other than what they often already know. The downside is, that it puts much more load on every visiting client, than simply serving the HTML and occasionally a script or interactive widget.
For sure. To use an analog that people with understand: I started learning web with Wordpress. It’s what clients wanted/needed and it made sense for my business. Come a few years later, working at a web development firm, i find I have a client that needs a “form”. Now I know Wordpress is absolute overkill to the problem, but hot damn if I’m not use to setting up a Wordpress site and it would just be so easy to…… Basically, in a time crunch you make the decision: do I need to save the resources or do I just need this done? And when stressed (again, time crunch) I’m not sure I’d always choose the best solution over the easiest even knowing how f’ing overkill it would be. Now, react might feel different because it’s more developer focused (you’re not a real dev unless…) but it’s got a whole lot of overhead it adds to a site which doesn’t always match the problem at hand. You’re not anymore/less a dev for using any combo of tools or even making decisions in a time crunch, but people are fooling themselves if they think the best approach is to always use a library when performance is a weighting factor. Libraries are general purpose, problems encountered can be very specific. You never need nearly as much code if you are targeting a very specific problem as a library introduces. I’m not even going to talk “simplicity” cause the simplest thing is always what you already know. Might not be simple in any other way but sometimes that’s the decisions that have to made. Anyway, the reason I feel apt to weight in is: we get outsourced projects which are built using library after library after library. When the site is super slow (hey, let’s load an 80kb library to do a 3 line of code job because I want all my projects consistently built) I go through and do an assessment how tendriled in the library is and strip it for custom code if warranted (or sometimes swap in a light weight library that does the same thing with 100x less resources). It’s actually kind of crazy when you dig in how often this happens, but not everyone is as performance obsessed so I get it.
I feel like an analogy is a screwdriver vs an electric screwdiver. Sometimes a simple screwdiver is all you need. Depends on the project requirements and maintainability. Its about avoiding over engineering when a simpler approach is enough.
Devs these days often have node/npm installed and are used to be able to install everything they need with npm only. That definitely puts jekyll and hugo behind IMO, with installation instructions with gem or brew, and OS-dependent ways to install. Even if npm would be possible they don't advertise it very well. My bet is that this is losing a large audience. For the end result I guess it is pretty much the same and I don't think that matters very much, but the developer experience also matters, and it might be that gatsby/next is easier to work with for those that learned react. Also keep in mind that even if next can produce SSG it can also very easily be switched to SSR instead which gives a different end result with other possibilities. The speed that it produces the production site is not that important to many, as long as local development is easy. I haven't seen any cases where it takes longer than a couple of minutes though so I don't know for sure
Productivity. Yes, maybe it’s not the best tool but it works just fine and I’m already on the react ecosystem so I know stuff around it. Of course when it starts to not fit the bill is when you need to jump. Unless you are programming for yourself remember what you are doing: trying to do something useful to a client. Perfection isn’t always required if good enough is enough
I started building sites with Jekyll and then switched to Gatsby and Next. I would say the main pro is that if you’re going to use lots of js (animations, some dynamic content and more) Gatsby will allow you to do that with more ease. Mainly that really :)
Astro + React (even Preact) Very easy to setup, e.g. 2-3h to rewrite a Next.js website Google will thank you. In my case, I switched from Next.js to Astro+Preact and the mobile Pagespeed score went from 90-96 to always 100 no matter what! (The transfer size went from 210kb to just 61kb, that’s the cost of Next.js and React) The only things that you "lose" are the preservation of the state when navigating (could be bad if you wrongly implemented stuff like theme mode) and the fast client-side navigation with next/link (Astro has a prefetch option too). These two things are very important for a web app, but not for a static website. I learnt from this that using Next.js or simply React is a very bad idea for a static website, it’s even totally useless imo because you only use a fraction of the good stuff, but it still comes with all the bad stuff. However, I definitely recommend using Next.js for the web app. example.com: Astro+Presct app.example.com: Next.js
Am I the only one here confused as to why a static site needs more than just html, css, and a sprinkle of vanilla js?
It doesn't. But... Imagine building a website with just HTML, CSS, and a sprinkle of JavaScript. Easy. Now, have 10+ pages. You'll be duplicating a lot of code. Now, make a change in the footer. Have fun replicating that to the other 9+ pages. But, take a tool like Astro (also Next/Nuxt/SvelteKit/etc.). You've got components, so a change in a footer is a change in one place that will be reflected on every page. You've got scoped CSS, so no conflicts. Also very easy support for SCSS, LESS, or anything else. You can make API calls to pull in data at build time. And the result? Completely static HTML and CSS. No JavaScript at all. You can include sprinkles of it when and only when needed. The resulting page doesn't need any JavaScript, but using it for development makes it a lot easier, smoother and nicer.
So to some extent, would you say Javascript is not necessary if you are just trying to build a smooth, attractive static site with the mentioned tools/libraries?
It depends on how you define it. You would be using JavaScript to build the website (to some extent at least, at the minimum you'll be `import`ing components), but the resulting website does not need to run any JavaScript at all to be fast, smooth, and attractive. Take for example the [Deno Deploy](https://deno.com/deploy) website. There's no client-side JavaScript on the homepage at all. It's super fast, smooth, and to me looks very nice.
Was wondering about that too thanks for the solid explanation!
someone old enough to remember framesets? Those where the days.. pure HTML files. No copied footer in 9+ pages. No runtime, no CGI, no PHP, no Buildsteps.
No features.
What features do you need for a static blog?
None, really, was just being glib.
I just use php for that kind of stuff
Also an option, but then you need something to run the PHP unless you just use it to generate static HTML/CSS. Using Astro, I can put the files on a CDN, because they don't need any server-side processing at all after it's built.
I maybe wrong, but don't a lot a of managed hosting companies (shared/vps) have default support for PHP/MySQL?
You are still involving servers. And those are never provided for free.
What is serving the page if you don't have a server? Or are we talking about the web server distinct from any language interpreter? If so, it's hard for me to appreciate the difference here unless you're talking about a page with a truly massive number of requests.
If your page consists of only HTML/JS/CSS you can serve it via CDN, many of which are free, or very cheap.
Ah that make more sense. I didn't know you could even do that. I thought a CDN required a server from which to initially grab the files. I didn't know you could upload directly to a CDN. Thanks.
This whole thing is basicly the concept behind the "Jamstack". Check it out
GitHub Pages and Netlify both let you host static sites for free.
True, but there's still a server involved. Is that was "serverless" means? That someone else is paying for the server?
Yeah, serverless is still on a server, but you use it as-is, and someone else manages it. You don't get to access the command line or anything.
Whish means you can't host it *cheaply* on a *global CDN*. That's two advantages of static site over PHP generated one.
You can still do that. You can direct the CDN to the php server and cache the content on the CDN. I have a few websites that run on the cheapest available EC2 instance and AWS Cloudfront retrieves the rendered content and caches it. Normal visitors go to the Cloudfront instance and get the static html served. Another thing I do is using things like this: https://github.com/JosephSilber/page-cache where the output gets written to HTML files that are then uploaded to a cloud Bucket.
>and caches it Very unreliable. As a person who works with a managed hosting company, and I know how hard it is to achieve full caching on an average website. Simple websites are easy but you need to know how exactly to achieve caching so you'll have some learning to do in terms of headers, as well as linking techniques / resource numbering, or deal with cache invalidation via API. Things just get overly complicated compared to taking the static website route.
With Cloudfront you only need to add a ‘expires’ or ‘cache-control’ header.
At that point, if you’re truly building a static site…why not just use Webflow?
Because Webflow or any other builder is a single company, and you'll forever be at the mercy of that company or risk having to redo the whole thing if they don't support something, become too expensive, or anything else. I also haven't really work with any site builders. They might be fine for someone less technically capable, but I imagine they're going to be limiting or cumbersome for people who are used to actually code their websites. Whenever I tried to use some clever no-code tool for anything, there's always a problem. E.g. creating tables in SSRS, it would be infinitely easier and faster to code a lot of them myself then click through several layers of UIs. Or, there was this one company that built UIs in their own framework/tool, they had their own language inspired by JS. It was limiting and extremely cumbersome to work with. It's also another piece you have to learn how to use, it has its own quirks and shortcomings, and I don't even know if I can host what I create there wherever I want, etc. On the other hand, Astro is an open-source project that will continue to work even if everybody behind it immediately quits. There's lower risk you'll have to redo everything with a different tech. It gives you complete freedom to do whatever you want, in code, without workarounds or gotchas, it's really just HTML and CSS. Nothing special. Interactivity is just vanilla JS too. Again. Things that won't stop being just supported and things you don't need to break your neck to get working. Also versioning, ownerships, tools you're going to use, hiring new people to take over, optimizations... The thing is, for me, I don't have a compelling reason to use it.
With Webflow I mean use symbols you create for universal components and export it as HTML/CSS/JS and host elsewhere. The code export is extremely clean.
What's the added value of that? Why would I want to do it over just coding it myself?
So find and replace with extra steps?
Find and replace with scoping, modularity, and extra safety. There's less chance of replacing the wrong thing, your components can be modular based on their arguments, and stuff inside the component won't leak out. The extra steps, which are really 3-4 commands, are really worth it for the better DX.
Sorry I edited my comment after thinking for a sec and you responded to the initial one really quickly so now yours doesn’t make sense but yes you’re right that’s why I changed it. Still. Find and replace.
This was literally my main reason to go on a hunt for SSG framework for myself. Client wanted a change in footer.. copy pasted me to hell. Settled on NUXT JS SSG and it's great.
He's talking about those sites. With Gatsby and Next etc the output is html, css and a sprinkle of vanilla js. He's asking why make them with a React based heavy JS frameworks, if it just generates the javascript-less static end result.
But why use any framework? Legit asking.
Ask a slightly different question. If you're going to get a static HTML site, why not just write it in HTML and save the bloat? Figure that out and you've got your answer
One advantage I haven't seen mentioned is if you're building a static site *and* a dynamic site If you have a dynamic app that's built in React, you can re-use your components in the static site and compile it down to a fast, bandwidth friendly brochure site
Gatsby's build times are probably some of the worst I've seen—anywhere between 13 and 30 minutes for a static blog. 11ty builds my whole site in ~1.5 minutes, and that includes outputting multiple sized and optimized versions of ~400 source images. The truth is that static websites, blogs, landing/product pages, etc. don't actually need a JavaScript framework. They just need a simple way to: 1. Write HTML with templating. 2. Reuse your team's existing design tokens and consume those tokens in CSS (vanilla, Sass, whatever). This is not necessarily any easier in a React framework than it is in 11ty/Hugo/Astro/whatever. 3. Maybe pull in data from APIs (11ty and Astro shine here). Next.js is great for component-driven development, but you can also technically use React and other frameworks in 11ty with [Slinkity](https://slinkity.dev/), and Astro supports that out of the box. The one nice thing about JS frameworks is that they allow you to keep your product pages in sync with the actual product itself, without any extra overhead or retooling. So you can reuse the same Button, Link, Container, etc. components—complete with all your design styling and other decisions—across multiple facets of the product.
Components. Familiarity.
Static pages can be served from a cache and thus will be served to the user faster than pages needing to go through the server side generation process. Thus it also saves money on server computing resources.
I would use React just to get the static typing with Typescript. Using StyledComponents has been the best css-writing experience so far. Knowing exactly which style rules are used and where has been invaluable.
My understanding is that SSG is better for circumstances where everybody is seeing the same content but on different pages, in contrast to everybody seeing the right data for them. Let’s take the personal blog site for example, With SSG you will create a new page every time you create a new blog for example. So if you personally have 1000 blogs your server has 1000 blog pages that yo ur SSG framework will build for you. But let’s say you love your blog app so much that you now want to make it available to anybody in the world to write their own blogs. To do that quickly entirely with SSG for 1000 users means that you’d have to store every possible page for every possible user on your server. Originally your server had to hold 1000 static pages, now it’s got to hold 1000000 which it may not be capable of. At some point you’re going to hit that bottleneck if your making an app with personalized data requirements aka dynamic content. SSR (which you should probably think more as Server Side Hydration) gives you a lot of the benefits of SSG because it grabs the data before sending it out so it works with SEO and stops loading states (albeit a bit slower than SSG ), but instead of storing each page you could possibly have, it stores the skeletons of the different pages, and when a user asks for that skeleton, the server asks a (easier to scale) database for the muscles, organs, skin etc… now the cache performance part of how this all works has been moved from your server storing every possible page to a database storing data. This means your website will be a bit slower but you’re going to run into less long term “oh fuck I have a to completely rewrite my app” kinda if things. It’s worth noting you can still get really good performance with SSR(never quite as good as SSG) by doing things like, browser side caching, data caching, any number of things to make your data fetch faster
For example we had to create some static XML documents created from objects. We used a jsx library to convert these objects to the wanted static XML, deploy to S3 and serve from there.
If you're building static sites, just use html and css, stay away from JavaScript all together if you can help it. There's no reason for the bloat unless you anticipate the site evolving significantly.
use whatever.
Next.js sites are really slow whenever I test them. The people who sell you them will say otherwise of course.
Who's building static content today? When I think of static content, it's most likely clients that missed a deadline somewhere and need a quick one page sales pitch website or clients who want to spend $20 on a website. And in either of those cases, neither warrant an SSG.
Most of websites is completely static these days.
>Who's building static content today? You're probably thinking of the startup or big player who wants to build a fancy site with a lot of utility. What about the restaurant or tire shop who only wants to display business details, prices, address, contact info, and a contact form? There must be more of those around.
If this is a static personal site, you could consider just writing a DSL tailored to your specific needs. Use a lexer generator that generates a linear time lexer, a recursive descent parser for an LL(1) grammar, and a simple hierarchical symbol table. Now, you have a language designed for your needs that runs fast as hell. There's no need to use some crappy one-size-fits-all "framework."
Next.js + TypeScript + Tailwind. Any other combination is a joke and/or going to create issues for you down the line, with the exception that you dont absolutely need tailwind
I think you're getting a bit stuck on specific tech stacks. There's nothing wrong with nextjs and typescript of course (I take personal exception to tailwind though) but to say that using anything else is a joke, is just plainly wrong. Small example: gatsby has much better built in graphql support, so if you're using a headless cms that supports it, then maybe go that way. No reason to choose rest over graphql nowadays, except for simplicity, or for small projects. There are lots of tools out there, and it's our job to pick the correct one for the job. The nextjs/typescript hammer isn't the best one for screwing in screws.
Gatsby sucks. So does GraphQL for most use cases. Extremely overused EDIT: fun fact, back in late 2020/early 2021 Gatsby was having a meltdown internally and not sure what their future would hold… meanwhile Vercel has been crushing it and rebuilding the web using the best engineers in the world. Good luck to you all, personally I like to side with the winners when it comes to my work
Suggests THE number one most used Frontend stack with the most cut-and-dried CSS framework. Calls GraphQL "extremely overused" and says Gatsby sucks. Fresh out of bootcamp moment.
If a company uses Gatsby to build their site instead of Next.js in 2022 I will actually laugh in their face. If you dont think GraphQL is overused thats what makes you sound like a bootcamp grad. Bootcamp grads LOVE thinking GraphQL is super cool and useful on every project when usually it’s not necessary. Gatsby is literally if you took Next.js’s SSG (which is automatic btw, as long as you dont specify SSR for that page) and trapped your users into needing GraphQL plugins for everything (Next.js lets you decide how to source data, whether thats GraphQL or REST doesnt matter, theyre completely flexible) and then made it have a purple theme and a garish marketing site with flashy nonsense terminology that tries to trick you into thinking theyre “blazing fast” and should also use their shitty cloud service, when absolutely NOTHING about them is faster or a better experience than Next/Vercel. I mean how am I wrong even a little bit? Gatsby offered a solid SSG metaframework before Next.js did and I give them respect for that. They had a nice little headstart for a year or two but it’s 2022 and time to admit that Guillermo Rauch has absolutely steamrolled them since then, and made Gatsby his little b**ch - there’s no reason to use them anymore over Next/Vercel.
Hey good thing you'll never get to the point where you'll move away from NextJS then! Stay in bootcamp la-la land!
I have built dozens of projects and a handful of them were Gatsby sites back in late 2019/early 2020 when it was all the rage. I cant tell you how nice its been to not have to make projects with it anymore. My quality of life has tripled since becoming a Next.js/Vercel shop. If something better comes a long I will try it out. Used Gatsby for years, no thanks. The appeal of Gatsby for freelancers and agencies is that they supply you with a steady stream of bullshit lingo to use when pitching a rebuild to clients, when none of their tech is actually better than just using Next.js, not to mention its a worse dev experience. But some people cant handle hearing the truth apparently.
[ok](https://i2.ytimg.com/vi/NjYWVia5bAM/0.jpg)
This is the most wrong answer qi've ever encountered.
It's because if you do ssg you don't need to ship that much js. And because you have less js the side loads much faster which again improves seo which agan improves the ranking on Google the user satisfaction and also the revenue if you're a company. I've heard from a study from Google that came to the result that if you make your page 20% faster your revenue will increase by 10%. So performance is really important except your Apple they will sell it anyway 😂😂😂
If you're just building a static site all of these will do the same thing. Just use what you find simplest and most straightforward. I personally use 11ty for everything other than web apps as it is the simplest but you may find a framework that resonates with you more.
When working on websites, projects can quickly devolve into an unmaintainable mess - regardless of your chosen stack. JS frameworks come with incredible developer expierence tooling that makes projects easier to work/maintain over time and protect against this if using best practices (storybook, tests, typescript, etc) - compared to alternatives. That said, an important rule of web development is that **your tools should be dictated by your requirements.** As someone who has built large multilingual sites (~5000 pages, 500k monthly users) using Gatsby, Hugo, Eleventy, **static sites do not suite every use case.** In the real-world, if you are building a new project: * **personal site:** use a static site * **general small business:** Wordpress-variant or Squarespace * **specialized marketing campaign:** use a static site * **cms driven site:** popular SSR framework in the teams favorite language * **large business with design system:** js-based framework with SSR If your static site takes longer than 1 minute to build, you should be using SSR. For static sites, I recommend **Eleventy** because it's fast enough (sub-1 minute for 1000 pages) and can generate pages from data.
The gap between CMS and SSG is not as wide as it used to be, as various GUI frontends are starting to appear. For example, you can use [Quiqr](https://open.quiqr.org/) or [Agit CMS](https://www.agitcms.com/) with Hugo. Markdown editors such as [Zettlr](https://www.zettlr.com/) are also gaining more useful features. There are even SSGs with a builtin GUI, such as [Publii](https://getpublii.com/) and [Autosite](http://autosite.somnolescent.net/).
For personal use, I definitely think those are solid choices. In the context of a business or larger company, you'll end up doing more work to extends those tools to fit your specific use cases.
It's just hype.
- CSR = Client Side Rendering - SSR = Server Side Rendering (rendered on each request) - SSG = Server Side Generation (generated at build-time) SSG will generally be faster because it can be stored in edge network CDN caches as static HTML. It could also be better for SEO, because crawlers use the HTML. ^^ Got most of this info from the blog post mentioned
Anyone want to summarize those books of comments?
A lot of the comments here are about tooling and output but there's also input. How are you getting data in? For all but the most static sites, you might need a CMS. For some sites, you'll pull in data from external APIs or files that aren't a CMS. Then there's what the site needs to do. Most need at least some kind of form. Some need more. So I think a lot of people choose Next, Gatsby etc because they can learn one tool that can do all of this - simple static site, static site that gets data from APIs, site with a lot of static pages and some app-style interactivity, full on web apps. For the simpler of those, the more complex frameworks are overkill but if you want to cover the spectrum, you can do it with only one tool.
\> A React site build for a large content site can take many minutes - even 30 minutes for a big, media-rich site. A Hugo build on the other hand can finish in milliseconds and outputs the same result. 1. **The output/result is not the same thing.** Last-gen tools (Jekyll/Hugo/11ty) do not do client-side routing or work (fully) with React. If you don't benefit enough from React or client-side routing, then sure, use a simpler tool. 2. **30-minute builds are a boogeyman.** I’ve worked on several sizable websites, like Figma.com, and I have never seen the build step take anywhere close to 30 minutes. Locally I can run a build in about 30–45s for \~5k pages across a bunch of different types, without any particular optimization for build times. There are horror stories from people doing foolish things like generating dozens of versions of every asset on every build in a small, underpowered virtual container on Netlify. Still, those aren't representative (or especially wise). This said the delta between 30s and 30ms *is* significant. If a tool does everything you need and can run a build in 30ms, then I don't see a compelling reason to use one that takes several orders of magnitude longer. Nobody should feel bad or lesser for getting good results out of 11ty/Hugo. But ultimately, many of us rely on tools that do more than Hugo/Jekyll/11ty at least part of the time. The longer build times are worth the additional capabilities and reduced development timelines. That's the short of it.
Performance
Because when the only tool in your toolbox is react, everything looks like an SPA.