I opened this website on a laptop and it was a very satisfying read.
I immediately noticed that the page uses full width of the screen; that there are no distractions in the form of ads, newsletter popups, unintuitive scrolling, or the like; and that the increase in information density was without compromising readability. Embedding social media content as screenshots is a nice touch too.
An efficient way to prove your point.
> our collective web experience frustrates more than it excites. It is a whiplash feed of ephemeral 'content' interspersed with ads and walled within 3 or 4 platforms with web-accessible front-ends (social media, newsletters, Discord channels). They'd all love for you to switch to the mobile app, though.
Thank you, I intentionally went for this full-width format as I too don't like reading long articles in a skinny single column template that Medium and Substack default to.
As this is a personal website that isn't selling anything, I have no need for email sign up popups and the like.
> We can't expect to turn back the clock and have everyone writing HTML by hand again, not when we're all accustomed to typing text and uploading media via carefully manicured, intentionally minimal user interfaces.
There are days when I feel like I'm the last person left who hand-codes personal websites for pleasure. Though I refuse to believe this is true!
Then again, I doubt there's a freehand web editor that's ever been built that can cope with the sort of crazy I was building back in the day (and, against all probability, still works!)
> Too much knowledge of code is required to create a hand-made website. Building one shouldn't be any more difficult than making a PowerPoint [presentation]
I like this. I also wish designMode were more of a discoverable, easy-to-use feature in popular browsers.
Hosting (and DNS etc.) are still a pain though, and usually cost money.
> an abandonware WYSIWYG web editor called Hotglue
> Hotglue is a fascinating open-source "anything goes, WYSIWYG" website making tool
But it's open source (GPL), so anyone could revive (or un-abandon) it!
Even in 2024, the <table> element remains an easier, HTML-native way to build multi-column layouts than flexbox or grid. Is it responsive? No. Does it work acceptably in the absence of the above? Yes!
I mean that the problem with those is that they require lengthy tutorials and fairly extensive knowledge of CSS, just to get something pretty basic up and running. I've never seen an "ultimate guide to HTML tables", yet there are plenty such articles for flex and grid.
Well, you can do much more with them. But getting a basic example set up and explained is less then a few paragraphs.
The long blababla articles might exist because of SEO. And back then that was not a thing, so a modern guide to html tables would be likely "ultimate" as well.
"But it's open source (GPL), so anyone could revive (or un-abandon) it!"
Not everyone has the skill, or time and energy, to pick up a dead project. Most projects are dead, because the codebase became no more fun to work with. So it likely won't be well documented, nor clean code and original creators might be not around for questions. Really challenging start conditions, that is why most abandoned projects stay abandoned and people motivated rather start a fresh one.
(no idea about the state of hotglue, but it would surprise me, if it would be different here)
> Not everyone has the skill, or time and energy, to pick up a dead project.
To expound on that, usually when I encounter a "dead" project, the biggest hurdle(s) are the build assumptions that weren't addressed - large complex build systems that have many presumptions (usually dynamic run-times with macro libraries, that require specific versions of things to exist on your system, that themselves are also quite difficult to build/require specific starting conditions)...
A good example, I see (quite often actually) build systems with nested build systems that are then bootstrapping other builds - quite a technical marvel but unsurprising when a tweak to the "underlying build tools" causes strange errors and requires massive build-system surgeries...
The lesson? Be as verbose as possible about exactly everything you know you depend on, in as clear (human readable) format as possible, and always strive to pick the simplest build tool possible - if you are compiling a language, use that compiler, not a system that has support for systems that can compile your language.
Technical "shortcuts" are the bane of longevity of a software artifact.
Very much this. Please stop building Jenga towers.
It's always alarming to encounter build instructions that start with "you need this specific version of this particular compiler for this particular obscure language..."
Bonus points if your build process fetches modules from online endpoints that may or may not be there in five years' time.
[And yes, I'm as guilty as anyone of creating over-engineered but ultimately fragile scripts to automate a build. My favourite is a bash script which parses a text file for filenames, matches against the file extension and processes them accordingly. If you edit the text file with a Windows-style editor so it acquires CR/LF line endings, the bash script can no longer parse it. Fun times.]
Are you saying all new languages are bad because they encourage you to pull in half the program via some language package manager, injecting problems from simple networking availability to supply chain attacks into what was otherwise a simple program?
Are you saying we should only code everything in C and C++ and Bash with as few dependencies as possible?
Sorry for the late reply: what I'm saying is that build-process fragility is bad. Ill-considered or slapdash dependencies can be part of that, as can runaway complexity. So can the choice of language, but so can the hackish bash-script example I confessed to from my own project.
> Are you saying we should only code everything in C and C++ and Bash with as few dependencies as possible?
Every so often I encounter a package with very few (or no external) dependencies that just works, and it's wonderful.
There is something to be said for going with a mature, stable, non-bleeding-edge platform and minimizing dependencies.
Regarding C/C++, they tend to facilitate memory errors, while memory-safe language systems (Ada, Java, Javascript, Rust, ...) all seem to come with various down sides.
Overly complicated things, but also things that are so fragile that the slightest disturbance (such as a minor version change) in the foundations will make them collapse.
No worries about that with Hotglue (PHP), the deployment is no more complicated than dropping the unzipped project folder onto a webserver.
I really wish I knew more PHP to fix some things, as Hotglue as it is already ticks a lot of boxes for me (non-SaaS, self-hostable). I tried to find a way to make public pages password-protected, but it didn't work when I used the Apache server method (conflicts with the authentication method used for editing the pages). And I don't know enough PHP to do it on the application side.
I think ChatGPT and alike could probably help here. Maybe they even know the project and had its sources in the training data and your request sounds quite standard.
Shameless plug for my startup’s freehand web editor https://hatch.one. You don’t have to throw back to hotglue if you want to create your own site visually with tremendous creative freedom.
And no affiliation, but I've been enjoying https://mmm.page which isn't open or self hostable, but also a long the same lines. (I think I found it here on HN)
A search engine presumably has 2 things, a database and a search algorithm
The user doesn't have direct access to the underlying database
Sometimes when I'm searching something, I want to do some very specific and unusual filtering and the built in filters/settings just aren't enough. It would be impossible (or at least crazy) to include all the different possible settings that I might want, you'd practically be writing a new scripting language.
However databases are important and common enough that they already have specific languages for querying them, like SQL. Where filters and settings wouldn't be enough, SQL probably would.
So what I really want is direct access to Google's databases (because it presumably has the biggest and this comes up when I'm looking for something really obscure). But I'm guessing that's not gonna happen.
I don't think it is the software that is the blocker for people doing this. It's not like it was easy in the old days - if anything it is easier today to create a personal-if-bland site on one of the many free WYSIWYG editors that use templates (I know the article mentions this) yet they don't. And let's face it search engines were utter trash until early-google arrived so it's not like you could count on your site being easily found (...and some may argue the current utility of search engines - or lack of! - puts us back where we were pre-google era anyway...)
I think there are some other reasons - I don't know which one(s) (if any) are most true or not:
- maybe people still are doing it but we just don't see it now the net is so much larger? Look at Gemini protocol et al - people are doing things but not in a necessarily eye-catching way
- maybe video is the kids' new HTML? There is some weird/creative stuff on tiktok etc al. Even getting photos let alone 4k video into a computer was hard in the early/mid 90s.
- it just went out of fashion
- the novelty wore off
- people see the internet as a utility these days, and take it for granted
- everyone is spending all their time trying to bootstrap a Like-OpenAi-But-For-Ride-Hailing start-up instead
Tl;dr - motivated individuals will build something if they want to, but I think the motivation has gone. I don't think it is because they feel constrained by templates
> puts us back where we were pre-google era anyway...
Google (search) is becoming increasingly less relevant. I know of DuckDuckGo / Kagi, a quick search (on DuckDuckGo) shows a lot of other search engines such as Mojeek, Ecosia, Qwant, Brave:
However I wonder if it would be technically feasible to distribute the search problem instead - Mastodon for search. Technically a node only needs to spend time spidering results with a simple variation on something like PageRank, then some trust/value mechanism needs worked out among the nodes.
The problem with the rise of new competing engines is just that, their competition. Lets say one, e.g. Kagi, becomes the de-facto quality non-AI search engine in 5 years, there's nothing to stop them being bought/sold/bankrupted (financially/morally/infested with secret AI).
> Tl;dr - motivated individuals will build something if they want to, but I think the motivation has gone.
Author here: you are right, but it's a shame that those who are motivated skew towards building a "product" of some sort, like a Substack, or a "personal brand". This means they will be well-served by the existing business-focused options out there.
And on the other side of the spectrum, there are creatives making cool things on itch.io, Blender, and elsewhere. It would be great if there was a "middle ground" option for the average weirdo that could use a pure drag-and-drop anywhere web canvas to express ideas, without being hamstrung by the steep learning curve of running anything beyond Medium.com.
While I’m sympathetic to the aims of this manifesto, I can’t help but see the paradox of “free hand” being antithetical to html, a format that chose semantic over aesthetic, and legibility over expressiveness.
I didn't go into it in the article itself, but you are correct. HTML has a pretty strict hierarchy of elements to maintain a semantic style. While this is helpful for those using screen readers, or running search crawlers or AI scrapers, it is unfortunate that this decision mostly excludes the ability to build freeform layouts without incurring SEO and potentially WCAG penalties.
I hand code my business website by hand, fun and it's actually fast once you know what are you doing. Best thing is you can actually optimize everything properly by building things to be exactly as needed and make fine refinements. Even with animations and stuff, it's total weight is below 1MB (854Kb).
But this is not for everyone, not only the lack of knowledge (which is fine, not everyone has to write their websites manually) but also lack of interest. Great for tinkerers to deal with the challenges and make it do.
> We can't expect to turn back the clock and have everyone writing HTML by hand again, not when we're all accustomed to typing text and uploading media via carefully manicured, intentionally minimal user interfaces.
I mean, I do it. That was always allowed! You've been able to write as much or as little HTML as you want since the Web was invented.
I immediately noticed that the page uses full width of the screen; that there are no distractions in the form of ads, newsletter popups, unintuitive scrolling, or the like; and that the increase in information density was without compromising readability. Embedding social media content as screenshots is a nice touch too.
An efficient way to prove your point.
> our collective web experience frustrates more than it excites. It is a whiplash feed of ephemeral 'content' interspersed with ads and walled within 3 or 4 platforms with web-accessible front-ends (social media, newsletters, Discord channels). They'd all love for you to switch to the mobile app, though.