The fear-mongering about public domain seems to drift further and further from reality. Is SQLite "impossible" to use globally? Its public domain dedication is even more terse than the unlicense. If it really does become a practical issue for Germans, maybe the real problem is the German legal system.
It's unlikely to become a practical issue IMO (not a lawyer) but the German legal system has simply no notion of dedicating something to public domain like in the US. From what I've heard in my computer law course in university, you can safely assume that the authors/copyright holders of software like SQLite3 will not pursue their rights and use the software. If they decide to go after you legally, then you have to comply.
So the "unlicense" or "public domain" license is basically not more than a weak promise that the author won't sue you over any usage which they can break at any moment. On a proper license, you'd be safe if you comply with the license.
I don't know much about copyright law, but basically if you state the clauses in the unlicensed license and create the impression that you waive your rights to the software, you shouldn't be allowed to sue without real cause. That is to protect the software owner against ill-willed third parties. For example, if someone has made very minor changes to your software and distributes it commercially. You could sue that person, if you wanted, granted that you live in a law system where the copyright laws don't permit the usage of an unlicensed clause.
Waiving all your present and future claims on a software without any compensation beforehand could very well not be permitted in many legal systems. Law systems such as Germany and many other countries do not recognize software as an intellectual property. Software is recognized as a right which has personal and economic prospects. It is asserted that you can make legal acts on the economic prospects, but your ability to make legal acts for the personal part of your right on the software you've written can be limited. Because it is believed that there are some rights you have, that you cannot freely dispose of. For example you cannot make a legal act to become the slave of someone else, or you cannot trade your life for money. Because of the same reasons you cannot trade all rights for something you've created (~your software).
On the other hand, as tscs37 has stated, the unlicensed "license" statement means that you promise to not pursue your legal rights against anyone who uses your software. But as there are no parties, no signatures, no compensation, this is not a license agreement. This could only be regarded as a promise. You could break it at any moment, change your idea etc. But if you do that without any cause, you could get sued for damages, because of the trust you've implied to the other party.
Again, I don't know much about copyright law. I'm just a law student. But IMHO, you can safely rely on using software that promises to guarantee the unlicensed clause. If the author of the software changes their minds, you might have to switch to using a different software but you can in principle get compensation for all provable costs that this change has caused you or may cause you in the future.
No purchase necessary! The title and the slogan on the site seem to infer something else. It's public domain source, it says at the bottom of the page. Glad to see more static generators, not sure how this is better or different than the other many
Thanks for the clarification. I was looking everywhere for a price tag but couldn’t find it. Was excited to see another dev charge for their work! Maybe the title of this post should be changed so it’s less confusing?
Pelican is great, I find it very flexible thanks to its many plugins. I wished it was maintained a bit more though, there are a lot of PRs waiting for reviews[0].
Not OP, but I'm tempted to switch. Because I had an issue with Pelican where I couldn't get year/month archives to work sanely (Pelican does year/month/day which is too fine for me). So I had to write my own generator anyway, and plumb that into Pelican. It wasn't that easy to do, although I do think Pelican is fairly hackable, if anything else was more easily hackable/extensible, I'd use it. Plus not having Python 2 legacy stuff in the codebase is a plus when I'm grokking it. I also find the Pelican config overburdened [0], but understand why it came to be that way.
I'm giving it a go this weekend, let you know if it worked out for me.
I didn't get very far, because I found it hard to even specify which template a page should use. I tried to do it via the YAML front matter, but that gets clobbered. I could have written an extension that un-clobbers/sets it via the 'page_templates' hook, but there are other problems.
You'd have to re-write all your links, and the way you attach e.g. images to a post (for me the biggest deal breaker). You'd also have to write your own extensions for tags, neighbour pages, and much more. To be fair, the author never claimed it replaced Pelican or any other blog-capable static site generator. If you have a very simple site, it could work.
I also get the feeling Ivy is a bit of a vehicle to push the author's replacements for argparse (janus), markdown (monk), and jinja (ibis).
Sorry for offtopic, but I´ve seen many nice-looking website generators here, but being a backend-guy I struggle more with the frontend, getting a nice layout/theme/font without deepdiving into css/js/html. Any suggestions here ? Any Wysiwyg-Editor which generates a reasonable output ?
You can get some decent mileage out of a framework like Bootstrap[0] or Foundation[1] without diving too deeply into it, but it really depends on what your tastes are. I'm not sure about the WYSIWYG options out there though.
* Avoid custom fonts. You probably don't need a custom font. Just use system fonts. Using built-in fonts will allow your site to load faster.
* Getting a "nice layout/theme" is a design problem. I'd suggest following someone's style guide. I'm fond of the U.S. Web Design System [0] since it's lightweight and accessible. Disagree with their suggestion to use a custom font.
* Keep the layout as simple as possible, with a focus on content. You can go incredibly far with semantic HTML and a smattering of CSS. I don't think it requires a deep-dive.
I know this is controversial but the default html layout is what most people need. You can use markdown or org mode etc. to generate it. One improvement may be centering the content on bigger displays, which I do for my blog with two @media rules as follows: https://www.gkayaalp.com/style.css
If we're going to compile our FE code (sometimes once with production babel/webpack builds, sometimes more often with every server-side rendered cache miss), then we might as well go all in with static-site generators. The epitome of this trend is https://www.gatsbyjs.org/, a framework designed around GraphQL and React.
In more-or-less the same niche as Gatsby there is my Sitio[1], which also uses React (so kinda isomorphic pages), main differences being:
- No GraphQL stuff, but instead you'll use imperative JS code to tell the library which pages you want to build, with data from anywhere (files, CMSs, hosted contents elsewhere etc.) you can fetch using the same JS code, transform with any library etc.
- No Webpack, no Webpack transforms. I suffered when I tried to use Gatsby because of the gigantic dependencies on Webpack. I guess it's changed nowadays, but still I'm hurt and won't go back there. Here we're proud to use Browserify and go with more modular architecture.
The main advantage of a static site generator is it allows you to just write the contents of each page and the generator will insert that into a page template. It means that, for example, a site-wide navbar only needs to be written once rather than added to every page manually.
Even more importantly, if you change the navbar, it changes everywhere, no chance to forget, no tedious and error-prone copy-pasting.
Also, applying syntax highlighting to code fragments, doing the right thing around pictures, e.g. set explicit size, and many other seemingly trivial but tedious things.
In short, static site generators remove the legwork from static HTML.
Suppose for instance you wanted a static blog. Blog engines like wordpress (or django or flask for python setups) generate parts of the site on the fly as users visit. For instance, you might generate the most recent 10 posts in some list somewhere. This requires some (often not much, but some) additional time from the server as these are generated on the fly.
A static website generator like this allows you to make a blog (for example) and update content like most-recent-10-post lists (also for example) only when you actually add a new post. Thus no additional time is required on the fly.
I might add that there is an extension for flask (which I normally think of as dynamic) called Frozen-Flask which also allows a flask-built site to become a static site. This probably exists for django as well, but I'm less familiar with django than flask.
One django app that provides this is django-bakery, you could run the local server to add or edit content using django-cms or mezzanine then use bakery to generate a static site to host.
In HTML you cannot reuse code or split the code into multiple files without using copy and paste, iframes, or Javascript.
Software like this allows you to create templates and generate multiple pages with different content.
This can be achieved with server-side scripting languages. However, it is slower than static HTML. So if the content doesn’t change often, generating static HTML might be the eay to go.
It looks nice, but I guess I still[1] don’t understand the proliferation of simple static site generators. It’s pretty easy (and fun!) to build your own that works exactly as you want it to. And I don’t think a static site generator is suitable for non-technical users. Is there an in-between type of user technical enough to use a static site generator but not able to write their own? Or maybe the proliferation is only because they are both easy and fun to create?
Edit: I didn’t intend for this to sound negative for the creator. Even if it’s just for fun and the chance someone else might find it useful, that’s enough of a reason to build it for me.
I think if people dedicated time to creating one for their own use it can be done (I am decent at Python and I would like to think that I can too) but at the same time I don't want to much around with HTML and particularly CSS.
I use static generators purely by available themes because that's the part that I hate the most.
I'm one of those people who falls into that group -- I can, and have, used a static site generator, but have nearly zero programming knowledge so couldn't make one of my own. The biggest issue I have now is choosing which one to use. I've mostly used Hugo, with good results, but always have that slight niggle wondering if there's something that would work a bit better for me.
That’s the same for me. While I consider myself to be fairly technical, I’m not a programmer. Given enough time and googling I could probably write my own, but it would be a struggle.
However I’ve had lots of success building sites with Jekyll and love the speed with which it’s possible to get something up and running.
>Is there an in-between type of user technical enough to use a static site generator but not able to write their own? Or maybe the proliferation is only because they are both easy and fun to create?
Not sure if you mean to ask why people don't create their own static sites (without generators), or did you mean dynamic sites using PHP/Ruby/Python?
For the argument over dynamic sites:
Yes - the type that does not want to worry about security vulnerabilities.
My blog is made via a static site generator. I updated infrequently (once every so many months). I want to have it up and running for years without my intervention (i.e. maintenance).
I once had a Wordpress blog and treated it that way. It was hacked.
Then I built my own in Django. Then at some time it went down because my service provider updated Python libraries, etc.
The funny thing is: Using a static site generator is no more work, and has no fewer advantages. Why should I use a dynamic site or build my own?
For the argument against static sites, well then you'd have to maintain lots of links manually. A SSG gives you a lot of that for free. And you can use templates.
Hi, thanks, that all makes sense. I was asking why there are so many static site generators and why you wouldn’t just create a custom static site generator yourself, not why you would use one. I use one myself. Based on some of the other replies, I can see that there are use cases for not creating your own - when you aren’t a programmer, or when you don’t know or care to learn html and css, or when an existing generator already does all that you need.
>It looks nice, but I guess I still[1] don’t understand the proliferation of simple static site generators. It’s pretty easy (and fun!) to build your own that works exactly as you want it to.
I don't think that's true. It looks deceptively easy up front but the subtleties involved actually make it pretty hard. I've tried hugo, jekyll and pelican and they've all pissed me off for one reason or another. A common issue involves one of the 'template' themes I found on their template theme libraries not working on the "latest" version of the generator.
Ivy seems to have "solved" this problem by having almost no themes. This is not exactly the solution I was thinking of...
There's still a gap in the market here I think, and there will continue to be a proliferation (like how there was with bad javascript toolsets until jquery 'won' ~2007-8) until somebody makes an acceptably 'good' one or fixes an existing one until it obviously stands head and shoulders above the rest.
If you can make a well designed static site generator with lots of nice themes (or the potential for that) that doesn't fail horribly when I try to use it in a normal fashion I'd switch to it in a heartbeat and tell all of my friends. I'm using hugo now, but I'm not super happy about it: last problem with that being that I couldn't get it to competently handle breadcrumb navigation.
It makes sense that the static site generators with lots of bells an whistles are harder to get right, especially if they’re trying to build an ecosystem with plugins and themes where others can contribute. I’m considering the _simple_ generators like the one posted here, though. My original thought/question was why not just write your own if you have a simple use case? There have been some good answers here such as no programming knowledge, lack of experience with html/css, or wanting to spend your time on other projects.
I think even "simple" generators are harder than they look. Plus, those 'bell and whistle' features quickly end up becoming critical once you scale up from a few pages.
Also yea, don't really want to do CSS and web design just to put a bit of content online. Hence why these things exist.
> Ivy seems to have "solved" this problem by having almost no themes. This is not exactly the solution I was thinking of...
Yes, it really is a chicken-egg problem where I think you need to start with at least a half-dozen attractive themes to get attention.
Theme designers are not going to build themes for a site generator that nobody uses. And nobody (relatively) is going to use a site generator that has only a "document" theme.
Generators like Hugo, for whatever their faults, have dozens of really nice-looking themes so it's easy to find something close to what you want and either use it as-is or make some minor tweaks.
Learning how to program, especially when one doesn't come about it through self-selected autodidactism, can often seem to be an insurmountable challenge to people who don't know how.
This applies to even extremely technical, highly intelligent people. Often they recognize that there's an extraordinary time component to learning, and they optimize around that in other ways.
Learning to program is a weird thing because once you learn the mental processes of how to do it, it comes fairly easily. But the idea of "I'd like a tool that makes websites for me" and then knowing how to divide that problem down to the right mental abstraction model that perfectly (or near perfectly fits) some programming language and technical environment is a very difficult learning curve.
It's much simpler then to present small technical pieces that are well constrained in scope and definition and have tooling somebody else built do all the rest of the heavy lifting.
Static site generators are one of those things that are relatively easy, even for newish programmers, to build, but exist right on the other side of that learning curve for non-programmers.
Also, as a non-front end developer, I don't have HTML fresh in my mind and don't care to. Sometimes you just want to do something quick and not have to worry about it.
I've a site deployed using Lektor[0] for a slightly technically inclined user, who gets a UI to edit his site and when ready to publish, just click the button.
Yes, indeed. My original thought was more along the lines of why there are so many generators published to solve the same problem when it’s easy to create your own custom generator as needed. Add one more step - publish your custom generator online in case it’s useful for others - and now you see the proliferation. Makes perfect sense now :)
Yeah, you’re right - I forgot about Dreamweaver and similar tools. I do think that adding wysiwyg UIs to a generator puts it in a slightly different class than the type of generator posted here, but your point is a good one. Adding a UI to a simple generator would make it much easier for non-technical people to use.
>It looks nice, but I guess I still don’t understand the proliferation of simple static site generators. It’s pretty easy (and fun!) to build your own that works exactly as you want it to.
Notice how these two sentences are contradictory -- or rather how the second explains what the first supposedly can't understand.
If it's "pretty easy and fun" to build X, then that would inevitably lead to a "proliferation of" X projects.
It just takes a person that built one to then share their implementation on GitHub to increase that proliferation, and that's a very simple additional step.
And it just takes any person who understands "opportunity cost" to want to adopt an existing static site generator rather than build their own.
I agree it can be fun. And lots of us probably have written such systems ourselves. However, even for those of us who could write one, sometimes you just want to use a tool, not write it and worry about bugs and new features constantly. A good pluggable static site generator can potentially give you a lot more featues than something you write yourself.
Writing your own can be a good way to learn a new language as well as a good introduction to html/css if you’re new to it. Also, if you write it yourself (again, for _simple_ use cases), it’ll do exactly what you need and no more. Evidently, a lot of people have found reasons to write their own, including the author of this one - hence the proliferation of simple static site generators.
I find the features of Jekyll important; I use it for client projects and mock up designs. While I don't like everything about how it's structured and I've written my own for fun, it'd be a lot of work on my part to create and maintain something equivalent.
We're helping bridge the gap for non-technical users with our Jekyll and Hugo CMS (https://forestry.io). There are many other options too, just check out https://headlesscms.org.
It's an exciting time to be a web developer. We have many static site generators (like this one) to help build super performant sites, we can host them in the cloud for a negligible cost, and we can keep everything in Git.
Looks pretty nice for simple static sites. However on the homepage it says
> You can build any kind of website using Ivy but it's particularly suited to building project documentation
But unfortunately I'm not seeing anything about generating source code documentation from docstrings (like Sphinx). For me, that would make it much more useful.
It's odd that this has gotten so many upvotes while there are thousands of other static site generators[1] and this one doesn't even provide a single explanation as to why it is different or why would someone prefer this over one of the most famous ones.
I love this sort of static generator for a non-obvious (perhaps) reason: you can version control the source. I find that hugely useful when maintaining a complex site.
I wrote a similar tool, years and years ago, that took what looked like "troff -ms" input and spit out the whole website, complete with a site map. Here's an example
Site was done in php with peak user load being around 200 simultaneously users. I had git on the webroot and a chron job that dumped the sql, and pushed the whole thing every night.
General question - I don't understand why so many static site generates, github, many others, all use templates that won't fill the width of the page. Is using the full width of the page particularly difficult to design for? Or is it an aesthetic decision that template authors feel like having a 20 inch wide monitor with 8 inches of text in the middle flanked by 12 inches of white space is a nice layout? Particularly for code examples it's very frustrating seeing lines wrapped around unnecessarily on a large, wide monitor.
(sorry if this sounds like a rant, actually just genuinely curious).
Depends on width of the monitor, of course, but one reason would that it is easier for reader to follow lines if they are not too wide. The same reason is behind multicolumn layout in newspapers.
The best length for fast reading is not more than 60-70 characters per line. That's why you have columns in newspapers. I have a 4k 26 inch monitor. Full width texts are harder to read, I have to shrink my browser to make the text not so wide.
75 comments
[ 823 ms ] story [ 2881 ms ] threadSo the "unlicense" or "public domain" license is basically not more than a weak promise that the author won't sue you over any usage which they can break at any moment. On a proper license, you'd be safe if you comply with the license.
Waiving all your present and future claims on a software without any compensation beforehand could very well not be permitted in many legal systems. Law systems such as Germany and many other countries do not recognize software as an intellectual property. Software is recognized as a right which has personal and economic prospects. It is asserted that you can make legal acts on the economic prospects, but your ability to make legal acts for the personal part of your right on the software you've written can be limited. Because it is believed that there are some rights you have, that you cannot freely dispose of. For example you cannot make a legal act to become the slave of someone else, or you cannot trade your life for money. Because of the same reasons you cannot trade all rights for something you've created (~your software).
On the other hand, as tscs37 has stated, the unlicensed "license" statement means that you promise to not pursue your legal rights against anyone who uses your software. But as there are no parties, no signatures, no compensation, this is not a license agreement. This could only be regarded as a promise. You could break it at any moment, change your idea etc. But if you do that without any cause, you could get sued for damages, because of the trust you've implied to the other party.
Again, I don't know much about copyright law. I'm just a law student. But IMHO, you can safely rely on using software that promises to guarantee the unlicensed clause. If the author of the software changes their minds, you might have to switch to using a different software but you can in principle get compensation for all provable costs that this change has caused you or may cause you in the future.
As a happy user of Pelican[0], a different Python based static site generator. Why would I want to switch over to Ivy?
[0] https://blog.getpelican.com/
[0] https://github.com/getpelican/pelican-plugins
As the sibling comment mentions I sent a pull request to fix some broken css and they requested I fix their test suite first. No thanks, moving on.
I'm giving it a go this weekend, let you know if it worked out for me.
[0] http://docs.getpelican.com/en/stable/settings.html
You'd have to re-write all your links, and the way you attach e.g. images to a post (for me the biggest deal breaker). You'd also have to write your own extensions for tags, neighbour pages, and much more. To be fair, the author never claimed it replaced Pelican or any other blog-capable static site generator. If you have a very simple site, it could work.
I also get the feeling Ivy is a bit of a vehicle to push the author's replacements for argparse (janus), markdown (monk), and jinja (ibis).
[0] https://getbootstrap.com/
[1] https://foundation.zurb.com/
* Getting a "nice layout/theme" is a design problem. I'd suggest following someone's style guide. I'm fond of the U.S. Web Design System [0] since it's lightweight and accessible. Disagree with their suggestion to use a custom font.
* Keep the layout as simple as possible, with a focus on content. You can go incredibly far with semantic HTML and a smattering of CSS. I don't think it requires a deep-dive.
[0] https://designsystem.digital.gov/
If we're going to compile our FE code (sometimes once with production babel/webpack builds, sometimes more often with every server-side rendered cache miss), then we might as well go all in with static-site generators. The epitome of this trend is https://www.gatsbyjs.org/, a framework designed around GraphQL and React.
- No GraphQL stuff, but instead you'll use imperative JS code to tell the library which pages you want to build, with data from anywhere (files, CMSs, hosted contents elsewhere etc.) you can fetch using the same JS code, transform with any library etc.
- No Webpack, no Webpack transforms. I suffered when I tried to use Gatsby because of the gigantic dependencies on Webpack. I guess it's changed nowadays, but still I'm hurt and won't go back there. Here we're proud to use Browserify and go with more modular architecture.
[1]: https://github.com/fiatjaf/sitio
Perhaps a stupid question but isn't that what HTML was designed for? It doesn't even require a generator.
Also, applying syntax highlighting to code fragments, doing the right thing around pictures, e.g. set explicit size, and many other seemingly trivial but tedious things.
In short, static site generators remove the legwork from static HTML.
A static website generator like this allows you to make a blog (for example) and update content like most-recent-10-post lists (also for example) only when you actually add a new post. Thus no additional time is required on the fly.
I might add that there is an extension for flask (which I normally think of as dynamic) called Frozen-Flask which also allows a flask-built site to become a static site. This probably exists for django as well, but I'm less familiar with django than flask.
https://github.com/datadesk/django-bakery
Software like this allows you to create templates and generate multiple pages with different content.
This can be achieved with server-side scripting languages. However, it is slower than static HTML. So if the content doesn’t change often, generating static HTML might be the eay to go.
[1]https://news.ycombinator.com/item?id=14877298
Edit: I didn’t intend for this to sound negative for the creator. Even if it’s just for fun and the chance someone else might find it useful, that’s enough of a reason to build it for me.
I use static generators purely by available themes because that's the part that I hate the most.
However I’ve had lots of success building sites with Jekyll and love the speed with which it’s possible to get something up and running.
A lot of people who want pretty websites without writing or learning a lick of frontend technologies.
Not sure if you mean to ask why people don't create their own static sites (without generators), or did you mean dynamic sites using PHP/Ruby/Python?
For the argument over dynamic sites:
Yes - the type that does not want to worry about security vulnerabilities.
My blog is made via a static site generator. I updated infrequently (once every so many months). I want to have it up and running for years without my intervention (i.e. maintenance).
I once had a Wordpress blog and treated it that way. It was hacked.
Then I built my own in Django. Then at some time it went down because my service provider updated Python libraries, etc.
The funny thing is: Using a static site generator is no more work, and has no fewer advantages. Why should I use a dynamic site or build my own?
For the argument against static sites, well then you'd have to maintain lots of links manually. A SSG gives you a lot of that for free. And you can use templates.
Because there are an unlimited number of things to create, and only a finite time in your life?
- It's faster and I already have more fun projects than my time allows.
- I don't particularly enjoy writing HTML/CSS (though the rest of the project would be fun).
- I'm happier using an existing template rather than making my own. I know I'll be too critical of the design if I do it myself.
I don't think that's true. It looks deceptively easy up front but the subtleties involved actually make it pretty hard. I've tried hugo, jekyll and pelican and they've all pissed me off for one reason or another. A common issue involves one of the 'template' themes I found on their template theme libraries not working on the "latest" version of the generator.
Ivy seems to have "solved" this problem by having almost no themes. This is not exactly the solution I was thinking of...
There's still a gap in the market here I think, and there will continue to be a proliferation (like how there was with bad javascript toolsets until jquery 'won' ~2007-8) until somebody makes an acceptably 'good' one or fixes an existing one until it obviously stands head and shoulders above the rest.
If you can make a well designed static site generator with lots of nice themes (or the potential for that) that doesn't fail horribly when I try to use it in a normal fashion I'd switch to it in a heartbeat and tell all of my friends. I'm using hugo now, but I'm not super happy about it: last problem with that being that I couldn't get it to competently handle breadcrumb navigation.
Also yea, don't really want to do CSS and web design just to put a bit of content online. Hence why these things exist.
Yes, it really is a chicken-egg problem where I think you need to start with at least a half-dozen attractive themes to get attention.
Theme designers are not going to build themes for a site generator that nobody uses. And nobody (relatively) is going to use a site generator that has only a "document" theme.
Generators like Hugo, for whatever their faults, have dozens of really nice-looking themes so it's easy to find something close to what you want and either use it as-is or make some minor tweaks.
A lot of the themes on generators like Hugo are ugly or don't work too.
Probably porting a group of 10 nice ones would be enough.
This applies to even extremely technical, highly intelligent people. Often they recognize that there's an extraordinary time component to learning, and they optimize around that in other ways.
Learning to program is a weird thing because once you learn the mental processes of how to do it, it comes fairly easily. But the idea of "I'd like a tool that makes websites for me" and then knowing how to divide that problem down to the right mental abstraction model that perfectly (or near perfectly fits) some programming language and technical environment is a very difficult learning curve.
It's much simpler then to present small technical pieces that are well constrained in scope and definition and have tooling somebody else built do all the rest of the heavy lifting.
Static site generators are one of those things that are relatively easy, even for newish programmers, to build, but exist right on the other side of that learning curve for non-programmers.
[0] https://www.getlektor.com/
> It’s pretty easy (and fun!) to build your own
Seems like you answered your own question. :)
I'd very much like to see fullon wysiwyg static generators again; it could replace half, if not more, of the WordPress sites around.
Notice how these two sentences are contradictory -- or rather how the second explains what the first supposedly can't understand.
If it's "pretty easy and fun" to build X, then that would inevitably lead to a "proliferation of" X projects.
It just takes a person that built one to then share their implementation on GitHub to increase that proliferation, and that's a very simple additional step.
And it just takes any person who understands "opportunity cost" to want to adopt an existing static site generator rather than build their own.
Both kinds are in abundance.
It's an exciting time to be a web developer. We have many static site generators (like this one) to help build super performant sites, we can host them in the cloud for a negligible cost, and we can keep everything in Git.
> You can build any kind of website using Ivy but it's particularly suited to building project documentation
But unfortunately I'm not seeing anything about generating source code documentation from docstrings (like Sphinx). For me, that would make it much more useful.
[1]: https://www.staticgen.com/
I wrote a similar tool, years and years ago, that took what looked like "troff -ms" input and spit out the whole website, complete with a site map. Here's an example
http://www.mcvoy.com/lm/bkdocs/UG/tmp/Introduction.html
if you go up a directory level and poke around, that's the source to website and webroff is the script that produced that website.
(sorry if this sounds like a rant, actually just genuinely curious).