A Reflection on the Small Web(misc.l3m.in)
misc.l3m.in
A Reflection on the Small Web
https://misc.l3m.in/txt/smollweb.txt
58 comments
Mostly because corpos and web dev tantrums: planned obsolescence and corpo/web dev locking via non-pertinent technical complexity and size of the web engines. This is a scam or toxic dellusions.
Those "open source" web engines have grotesque and absurd complexity and size, are written with a computer language (c++) which has a syntax complexity morbidely accute that it requires compilers (even naive ones) not better than the web engines themselves.
Hard truth: bazillions of services provided over the net can be provided as noscript/basic (x)html, aka basic html forms.
Hard truth: asking nicely usually does not fix that (I tried).
Hard truth: the real work in not the web "code", it is protecting it against hackers, like DDOS attacks.
Hard truth: Don't fool youself, hackers will be "paid" to push hard those sites on big tech network infrastructure (or are idiots). "Ppl coding computer viruses are probably those who sell anti-virus software".
Those "open source" web engines have grotesque and absurd complexity and size, are written with a computer language (c++) which has a syntax complexity morbidely accute that it requires compilers (even naive ones) not better than the web engines themselves.
Hard truth: bazillions of services provided over the net can be provided as noscript/basic (x)html, aka basic html forms.
Hard truth: asking nicely usually does not fix that (I tried).
Hard truth: the real work in not the web "code", it is protecting it against hackers, like DDOS attacks.
Hard truth: Don't fool youself, hackers will be "paid" to push hard those sites on big tech network infrastructure (or are idiots). "Ppl coding computer viruses are probably those who sell anti-virus software".
[deleted]
Gemini and Gopher seem to be quite different from the intention of the small web. One is a retro-computing thing, the other is a mission to focus on people rather than organizations
In practice they're not so different . There are plenty of people regularly publishing stuff over gopher that has nothing to do with retro-computing. Gemini also grew out of a gopher community.
I wanted to mention offpunk but I forgot! (edit: done)
(I read your posts on your gemlog as well as the french ones on your blog, thank you very much for writing all of these posts)
(I read your posts on your gemlog as well as the french ones on your blog, thank you very much for writing all of these posts)
On a higher level, the trend a couple of years ago to have big video banners & highly complex interactive websites with lots of moving content does seem to have turned a bit. You still see it a bit from these more designerly 'award-winning' websites that start up with a loading bar...
But now tools such as Google Lighthouse and Next.js logging first load file sizes makes it quite tangible to focus the team on and advocate for faster first meaningful content paints.
But now tools such as Google Lighthouse and Next.js logging first load file sizes makes it quite tangible to focus the team on and advocate for faster first meaningful content paints.
> faster first meaningful content paints.
That seems like trying to address one of the symptoms, not the underlying problem. "First meaningful paint" means nothing to me, depending on what the developer means by "meaningful". Why can't I just have the whole page load and display quickly?
A lot of this nonsense is because of mobiles. Mobile browsers don't handle some UI elements (checkboxes, radios, drop-downs) very well, and all the browsers have "interesting" incompatibilities; so developers use these compatibility shims, which usually result in a badly-degraded desktop experience, and slowness for everyone.
So I'm blaming the mobile browsers. They don't deal with standard markup properly.
That seems like trying to address one of the symptoms, not the underlying problem. "First meaningful paint" means nothing to me, depending on what the developer means by "meaningful". Why can't I just have the whole page load and display quickly?
A lot of this nonsense is because of mobiles. Mobile browsers don't handle some UI elements (checkboxes, radios, drop-downs) very well, and all the browsers have "interesting" incompatibilities; so developers use these compatibility shims, which usually result in a badly-degraded desktop experience, and slowness for everyone.
So I'm blaming the mobile browsers. They don't deal with standard markup properly.
Depending on the goals of the page I would say its not up to the developer either. Developer/designer/pm whoever should ask the user: is this part of the page/content meaningful to you to load first?
Unless you have something specific you want to communicate and then its up to you to decide whatever you find meaningful to show first.
Unless you have something specific you want to communicate and then its up to you to decide whatever you find meaningful to show first.
Just to add to conversation, IMO the smol web is mostly in need of great content, and discoverability.
When I say great content, I mean something that can federate a large audience and serve as a reference and inspiration for others.
Today most of content creator are producing for the rich web, so most of the interaction happen there, and as a result most of the new content is formatted for the rich web.
From the top of my head, Phrack Magazine [1] is the only examples I can think of text based good content. It is mostly aimed at a very specific audience, but I am sure they are other examples out there.
Which basically lead to the other question of discoverability...
1: http://phrack.org/
When I say great content, I mean something that can federate a large audience and serve as a reference and inspiration for others.
Today most of content creator are producing for the rich web, so most of the interaction happen there, and as a result most of the new content is formatted for the rich web.
From the top of my head, Phrack Magazine [1] is the only examples I can think of text based good content. It is mostly aimed at a very specific audience, but I am sure they are other examples out there.
Which basically lead to the other question of discoverability...
1: http://phrack.org/
The more I’m on the smolnet, the more I believe that there’s no content on the smolnet. Only conversations.
You will not find that trendy topic everybody is talking about. You will not find buzz and virality. You will not find a bunch of content creators with thousands of consumers happy to comment/reshare.
And that’s the whole point.
You write in the smolnet thinking you write in the void. Then, sometimes, you realize you are part of a conversation. Because you see posts replying to you. Because you receive emails.
The web is now mostly a huge stadium where we watch millionnaires playing football. The smolnet is the grassy field were you can play with others, having fun and improving your skills.
The small field is not there to replace the huge stadium. You can even enjoy both.
You will not find that trendy topic everybody is talking about. You will not find buzz and virality. You will not find a bunch of content creators with thousands of consumers happy to comment/reshare.
And that’s the whole point.
You write in the smolnet thinking you write in the void. Then, sometimes, you realize you are part of a conversation. Because you see posts replying to you. Because you receive emails.
The web is now mostly a huge stadium where we watch millionnaires playing football. The smolnet is the grassy field were you can play with others, having fun and improving your skills.
The small field is not there to replace the huge stadium. You can even enjoy both.
This should meet your standard, I think:
https://woodgears.ca/
https://woodgears.ca/
But then he blows it by linking to Instagram.
I'm not sure I like it. This Small Web stuff (and other similar movements) is close enough to plausibility to capture people's time and attention, but far enough from reality to inevitably fail without making a dent in the awful state of the Web today.
Here is something you should think about. If Small Web actually worked, we would be discussing this on Small Web right now. Do think about what this statement actually means before dismissing it as yet-another-negative-HN-comment.
This means, for starters, that I would gladly use another platform to discuss your ideas, but none of the websites from various "alternative web" movements have any plausible solutions for people collaborating with one another. Which indicates a kind of lack of high-level, systemic thinking that is absolutely essential if you want to change anything at scale.
Here is something you should think about. If Small Web actually worked, we would be discussing this on Small Web right now. Do think about what this statement actually means before dismissing it as yet-another-negative-HN-comment.
This means, for starters, that I would gladly use another platform to discuss your ideas, but none of the websites from various "alternative web" movements have any plausible solutions for people collaborating with one another. Which indicates a kind of lack of high-level, systemic thinking that is absolutely essential if you want to change anything at scale.
>I'm not sure I like it.
I'm gonna go out on a limb and say that that is basically what it boils down to - the small web, and similar movements, just aren't for you. Because...
>This Small Web stuff (and other similar movements) is close enough to plausibility to capture people's time and attention, but far enough from reality to inevitably fail without making a dent in the awful state of the Web today.
... in spite of that point, the small web has always been around in one form or another. While the rest of contemporary culture glommed onto Web 2.0 and social media, there were just enough people keeping alive some of the ideals from the older web that have made their way into the more contemporary "small web" movements that you see today. There's always been an audience.
>Which indicates a kind of lack of high-level, systemic thinking that is absolutely essential if you want to change anything at scale.
But I don't see it (and this is just my view of the small web) as an attempt to completely wipe out the current, contemporary, "popular" web. "Scale" isn't the goal, and I'd argue that scaling is antithetical to the general ideal of a small web. It's about focusing on smaller, community-run spaces without all of the noise and bullshit. You have to resist scaling in order to keep that spirit.
To that end, the small web will always be there, for those who want it.
I'm gonna go out on a limb and say that that is basically what it boils down to - the small web, and similar movements, just aren't for you. Because...
>This Small Web stuff (and other similar movements) is close enough to plausibility to capture people's time and attention, but far enough from reality to inevitably fail without making a dent in the awful state of the Web today.
... in spite of that point, the small web has always been around in one form or another. While the rest of contemporary culture glommed onto Web 2.0 and social media, there were just enough people keeping alive some of the ideals from the older web that have made their way into the more contemporary "small web" movements that you see today. There's always been an audience.
>Which indicates a kind of lack of high-level, systemic thinking that is absolutely essential if you want to change anything at scale.
But I don't see it (and this is just my view of the small web) as an attempt to completely wipe out the current, contemporary, "popular" web. "Scale" isn't the goal, and I'd argue that scaling is antithetical to the general ideal of a small web. It's about focusing on smaller, community-run spaces without all of the noise and bullshit. You have to resist scaling in order to keep that spirit.
To that end, the small web will always be there, for those who want it.
> If Small Web actually worked, we would be discussing this on Small Web right now.
Doesn't HN count as Small Web? It seems pretty minimal.
Doesn't HN count as Small Web? It seems pretty minimal.
small web as it does not require big software to interact.
Not small in traffic.
Not small in traffic.
hn works "okay" on TUI browsers
> inevitably fail
What would failure look like though?
I mean, I have a couple of Gemini sites ("capsules") up on sr.ht, I figure that they will stay available at least as long Drew Devault lives, and I bet he'll take steps to keep the service going beyond himself.
Since I'm not trying to record traffic stats, or monetize, or anything like that, how would failure be defined?
> If Small Web actually worked, we would be discussing this on Small Web right now.
As lambic says in a sib comment, I think HN counts as "Small" (that's a large part of why I use it and not, say, twitter.) Sure it has some JS and CSS, but it's basically text-based and all the dynamism is unobtrusive.
> none of the websites from various "alternative web" movements have any plausible solutions for people collaborating with one another.
Gemini, at least, has facilities for interaction, and some sites make use of them.
Also Gemini itself was developed by people collaborating with one another, largely over email & mailing list. (Interestingly, last I checked the mailing list serve had gone down, and they left it down because Gemini A) is done and B) has developed a self-sustaining community outside of the list.)
(FWIW, I have a mailing list and an IRC channel for collaborating with people, suits me fine. YMMV.)
What would failure look like though?
I mean, I have a couple of Gemini sites ("capsules") up on sr.ht, I figure that they will stay available at least as long Drew Devault lives, and I bet he'll take steps to keep the service going beyond himself.
Since I'm not trying to record traffic stats, or monetize, or anything like that, how would failure be defined?
> If Small Web actually worked, we would be discussing this on Small Web right now.
As lambic says in a sib comment, I think HN counts as "Small" (that's a large part of why I use it and not, say, twitter.) Sure it has some JS and CSS, but it's basically text-based and all the dynamism is unobtrusive.
> none of the websites from various "alternative web" movements have any plausible solutions for people collaborating with one another.
Gemini, at least, has facilities for interaction, and some sites make use of them.
Also Gemini itself was developed by people collaborating with one another, largely over email & mailing list. (Interestingly, last I checked the mailing list serve had gone down, and they left it down because Gemini A) is done and B) has developed a self-sustaining community outside of the list.)
(FWIW, I have a mailing list and an IRC channel for collaborating with people, suits me fine. YMMV.)
> If Small Web would actually worked, we would be discussing this on Small Web right now.
You mean discussing about lightweight websites on a website that weights less than 100KB? That would be incredible for sure :D
You mean discussing about lightweight websites on a website that weights less than 100KB? That would be incredible for sure :D
>post: One of those ways is to force your browser to *not* download any file larger than a fixed threshold (like 50 kilo bytes
>You mean discussing about lightweight websites on a website that weights less than 100KB?
Many HN threads exceed the 50kb download you mentioned in your post. See examples from: https://news.ycombinator.com/best
- over ~200 comments will often exceed 50kb download
- over ~500 comments can exceed 100kb
(Open those big threads in with F12 browser Dev Tools and look at the byte counts.)
The arbitrary byte limits of 50kb or 100kb don't seem like a useful heuristic. In other words, if you tweak the rules to increase it to 200kb to allow HN threads, it then conflicts with other "bad" downloads that seemed to fit the profile of 50kb on other websites being an indicator of something unwanted.
>You mean discussing about lightweight websites on a website that weights less than 100KB?
Many HN threads exceed the 50kb download you mentioned in your post. See examples from: https://news.ycombinator.com/best
- over ~200 comments will often exceed 50kb download
- over ~500 comments can exceed 100kb
(Open those big threads in with F12 browser Dev Tools and look at the byte counts.)
The arbitrary byte limits of 50kb or 100kb don't seem like a useful heuristic. In other words, if you tweak the rules to increase it to 200kb to allow HN threads, it then conflicts with other "bad" downloads that seemed to fit the profile of 50kb on other websites being an indicator of something unwanted.
As a thought exercise: IMHO the limitation should be transfer speed, rather than size of assets.
> Do think about what this statement actually means before dismissing it as yet-another-negative-HN-comment.
Well you've pooh-poohed the idea without offering a constructive alternative. To me that's a typical negative HN comment. Why not suggest some ways to make it closer to reality?
Well you've pooh-poohed the idea without offering a constructive alternative. To me that's a typical negative HN comment. Why not suggest some ways to make it closer to reality?
One alternative would be the web as today but without JavaScript. I think 90% of what sucks about current web goes away if js goes away. I don’t like executing arbitrary code from the web anyway. Even if the browser sandboxes it. Most of what websites do with JavaScript is not in my interest anyway.
I find the layout that browsers use really annoying, and the way HTML and CSS are used to modify the layout very unintuitive. To get something to show up on the screen in the way you want, you have to keep changing lines of code and experimenting until it finally shows up the way you want. This is really annoying and unnecessary.
Tools like PowerPoint and MS Publisher have allowed (for decades) the ability to just drag and drop anything you want onto a screen, save it, then send it to someone, and it will display for them exactly how it displayed for me. Text, pictures, sound, video. And it supports clickable hyperlinks. Which was the entire point of the web! But for some reason, web browsers are 10,000 times more complicated than these other ancient tools.
If we really want to make the web less braindead, less bloaty, easier to use, we should throw away the annoying crap we have now, and start from scratch with something that is just easy for the average person. We don't have to regress to text terminals and Gopher, or just use browsers without JS. We can make something new that is both easy and useful.
Tools like PowerPoint and MS Publisher have allowed (for decades) the ability to just drag and drop anything you want onto a screen, save it, then send it to someone, and it will display for them exactly how it displayed for me. Text, pictures, sound, video. And it supports clickable hyperlinks. Which was the entire point of the web! But for some reason, web browsers are 10,000 times more complicated than these other ancient tools.
If we really want to make the web less braindead, less bloaty, easier to use, we should throw away the annoying crap we have now, and start from scratch with something that is just easy for the average person. We don't have to regress to text terminals and Gopher, or just use browsers without JS. We can make something new that is both easy and useful.
> Tools like PowerPoint and MS Publisher have allowed (for decades) the ability to just drag and drop anything you want onto a screen, save it, then send it to someone, and it will display for them exactly how it displayed for me
The tools you mentioned have a fixed viewport size, the web does NOT have it.
99% of the difficulties of a web design is in supporting all possibile client screen sizes / ratios.
A powerpoint like experience is trivially to build, just use position: absolute and place everything pixel by pixel.
I'm not aware of any GUI for creating responsive content (unless you limit the content to a simple flow of text)
The tools you mentioned have a fixed viewport size, the web does NOT have it.
99% of the difficulties of a web design is in supporting all possibile client screen sizes / ratios.
A powerpoint like experience is trivially to build, just use position: absolute and place everything pixel by pixel.
I'm not aware of any GUI for creating responsive content (unless you limit the content to a simple flow of text)
> 99% of the difficulties of a web design is in supporting all possibile client screen sizes / ratios.
For a web designer.
For a normal person, 99% of the difficulties of web design is that they need to get a PhD in HTML, CSS, & JavaScript, in order to make some text and images show up. PowerPoint/Publisher are usable by anyone. The Web today is basically an employment scheme.
> I'm not aware of any GUI for creating responsive content
If all you want is to show someone some text and pictures, that should be (is, actually) incredibly simple.
If you want to show someone "responsive content", that is a different use case. It's a custom program at that point. So just ship them a custom program. It used to be common, trivial actually, to mock up a program in a visual IDE and send it to someone. The program would be small and fast and networked. We used a thing called Visual Basic, and nearly anyone with the most basic programming skills could use it. Worked great.
Today we do the same thing, only they are called "mobile apps" and are written in Java for a dedicated mobile operating system. Just like years ago, these are proprietary platforms run by quasi-monopolies, so you have to make your program multiple times to send it to everyone. But we could improve on that.
For a web designer.
For a normal person, 99% of the difficulties of web design is that they need to get a PhD in HTML, CSS, & JavaScript, in order to make some text and images show up. PowerPoint/Publisher are usable by anyone. The Web today is basically an employment scheme.
> I'm not aware of any GUI for creating responsive content
If all you want is to show someone some text and pictures, that should be (is, actually) incredibly simple.
If you want to show someone "responsive content", that is a different use case. It's a custom program at that point. So just ship them a custom program. It used to be common, trivial actually, to mock up a program in a visual IDE and send it to someone. The program would be small and fast and networked. We used a thing called Visual Basic, and nearly anyone with the most basic programming skills could use it. Worked great.
Today we do the same thing, only they are called "mobile apps" and are written in Java for a dedicated mobile operating system. Just like years ago, these are proprietary platforms run by quasi-monopolies, so you have to make your program multiple times to send it to everyone. But we could improve on that.
> If you want to show someone "responsive content", that is a different use case.
No it's not! You create your content with text and images, you send it to two friends: one opens it in a 27" inch monitor, the other one on his mobile phone. How big should the images be? How big the text? What happens if there is a text on the left and an images on the right, and you watch it on a mobile phone? should it go down, should the image resize to occupy at maximum half the viewport? what happens when the text overflows?
The reason you can do it on a Oowerpoint or Publisher is that the viewport is the same, you position it and you are done. The user on the desktop will see it very small, the user on the phone will need to keep scrolling and dragging.
If you are ok with these limitations, there are plenty of tools available to share content! You named them.
If you want better control, there are no easy way of doing it, there are no example of this problem being solved, and I don't think it's a web problem.
No it's not! You create your content with text and images, you send it to two friends: one opens it in a 27" inch monitor, the other one on his mobile phone. How big should the images be? How big the text? What happens if there is a text on the left and an images on the right, and you watch it on a mobile phone? should it go down, should the image resize to occupy at maximum half the viewport? what happens when the text overflows?
The reason you can do it on a Oowerpoint or Publisher is that the viewport is the same, you position it and you are done. The user on the desktop will see it very small, the user on the phone will need to keep scrolling and dragging.
If you are ok with these limitations, there are plenty of tools available to share content! You named them.
If you want better control, there are no easy way of doing it, there are no example of this problem being solved, and I don't think it's a web problem.
What you're describing is already dealt with by mobile applications, and could easily be added to a PowerPoint/Publisher type app. You wouldn't have to use a fixed viewport.
Here is a screenshot of Android Studio using a point-and-click layout editor to create responsive design, with no manual editing of code: https://developer.android.com/static/images/screens_support/... https://developer.android.com/guide/topics/large-screens/sup... It's very reminiscent of Visual Basic.
Here is a screenshot of Android Studio using a point-and-click layout editor to create responsive design, with no manual editing of code: https://developer.android.com/static/images/screens_support/... https://developer.android.com/guide/topics/large-screens/sup... It's very reminiscent of Visual Basic.
You asked for a tool that can be used by "a normal person". A normal person is definitely not capable of creating an android app, so I really don't see your point. You need to learn how to do it, both on Android and on the web.
Moreover, the layout editor is rarely used in Android development, most of the control is done via code because it depends on dynamic content that is not available to the layout editor ahead of runtime. Most the examples in the exact link you attached are code examples for this very same reason
Moreover, the layout editor is rarely used in Android development, most of the control is done via code because it depends on dynamic content that is not available to the layout editor ahead of runtime. Most the examples in the exact link you attached are code examples for this very same reason
The irony is that the introduction of XHR was intended to avoid page reloads which were seen as a major source of inefficiency.
Not all websites need to be dynamic, though. And I'm with you in spirit. I just think that throwing out JavaScript entirely throws out the baby with the bath-water for a lot of websites.
In theory, you can use XHR and client-side rendering to make things smaller, not bloatier. Fetch the HTML once with first content, then fetch only content updates at the user's request without reloading the page. This can result in better cache efficiency and improved render times. But a lot of people might object on principle to the idea of using XHR requests and dynamic behaviour in something called "small web."
Not all websites need to be dynamic, though. And I'm with you in spirit. I just think that throwing out JavaScript entirely throws out the baby with the bath-water for a lot of websites.
In theory, you can use XHR and client-side rendering to make things smaller, not bloatier. Fetch the HTML once with first content, then fetch only content updates at the user's request without reloading the page. This can result in better cache efficiency and improved render times. But a lot of people might object on principle to the idea of using XHR requests and dynamic behaviour in something called "small web."
I did a calculation a while back [0] that showed that there's 30x more js than html on the web today.
[0]: https://misc.l3m.in/txt/js_ratio.txt
[0]: https://misc.l3m.in/txt/js_ratio.txt
CSS still gives a lot of opportunities for abuse: crooked web fonts, colors, padding, spacing, text size, positioning, cookie consent, spinners, side bars, hover bars, even somehow manages to mess scrolling. We basically need only html as if it's old good text as it was initially intended to be displayed as the user wants.
"Small Web" is certainly something of an extremely viable idea, I just think that e.g. Twitter captured the essence of it.
At least for a little while they did, I quit twitter the day they closed the html version of their website.
Twitter does all of it's loading using js calls, there's no content on a twitter page without js, and it makes me sad [0].
[0]: Another small rant here: https://misc.l3m.in/txt/html.txt
[0]: Another small rant here: https://misc.l3m.in/txt/html.txt
I'm all in favour of small websites, but publishing plain text files to the web seems a little bit too crude for me.
If you take text file, wrap it with just a <pre></pre> tags, and publish it as .html you can then use any inline html tags such as bold, italics, links, etc. And even block level stuff like headings and lists.
But really, just mark up your text as plain, semantic HTML. It add very little to the file size.
If you take text file, wrap it with just a <pre></pre> tags, and publish it as .html you can then use any inline html tags such as bold, italics, links, etc. And even block level stuff like headings and lists.
But really, just mark up your text as plain, semantic HTML. It add very little to the file size.
[deleted]
A lot of these (Gemini included) throw the baby out with the bath water.
Yes, we want pages small. But we also want images and video in those pages, and those can and will be quite large.
Yes, we want pages small. But we also want images and video in those pages, and those can and will be quite large.
Speak for yourself. I'd just like to click a video link and have it open in VLC.
(you can point to images in gemini pages, you just can't display them, and it changes my way to consume this content)
Yes for distraction free content!!!
Someone mentioned this site in the comments: https://woodgears.ca/
For example, this kind of visual tutorial page is impossible in Gemini: https://woodgears.ca/pantorouter/linear.html
In it's insistence on "human consumption of predominantly written material" Gopher has removed the possibility of such content, too.
Edit: corrected a link
For example, this kind of visual tutorial page is impossible in Gemini: https://woodgears.ca/pantorouter/linear.html
In it's insistence on "human consumption of predominantly written material" Gopher has removed the possibility of such content, too.
Edit: corrected a link
Are anchor tags frowned upon in the small web movement? It feels like making it harder to follow hyperlinks goes against the "spirit" of what the web was built for.
(this txt file is not an html element, it's lighter than a traditional webpage because of my poor connection and the fact that I'm self-hosting my website)
ok, but wouldn't the tags still be resolved by browsers, even if they're not wrapped inside <html>? or is the point that it's not meant to be viewed through a browser? the overhead of the tags in terms of bytes seems fairly negligible, no?
HTML tags will be recognised by browsers even if the file is not wrapped with an <html> tag, but only if the file is served as html.
As I mentioned in a comment above, wrap the plain text in <pre></pre> tags, serve as html, then you can use links without adding any other html at all.
As I mentioned in a comment above, wrap the plain text in <pre></pre> tags, serve as html, then you can use links without adding any other html at all.
right - just removing .txt at the end should be enough even
Just want to say that I love the way this page looks and think that I'm going to ~steal~ take inspiration from it.
Thanks! I found that you need to add some kind of magic chars [0] at the beginning of the txt file in order to display utf-8 chars (prevent this éà  :P), here's how to do it:
echo -e "\xef\xbb\xbf\n" > myfilename.txt
I'm guessing you wouldn't need that if you set this header:
Content-Type: text/plain; charset=utf-8That's another level of work :P
I created the whole https://misc.l3m.in/txt/ trying to prove a point with a friend (the point was something like "you can start a blog right away if you have a domain name and a ssh access to a server, let me show you") :D
I created the whole https://misc.l3m.in/txt/ trying to prove a point with a friend (the point was something like "you can start a blog right away if you have a domain name and a ssh access to a server, let me show you") :D
You're using apache which I'm guessing you installed. If so I think adding `AddDefaultCharset utf-8` to the config should be enough, and probably easier than adding a BOM to each of your files.
Oh, the good old PHP days, when the BOM was considered a source of bugs :)
Ah, good to know! Thanks!
I’ve developed a terminal browser for the web/RSS/gemini/gopher and I’m everyday astonished how 95% of what I need is best served as simple text in my terminal. It makes me wonder "why do we to invest so much time learning/tweaking CSS/JS when all we want to do is exchanging text and a few pictures ?"
https://notabug.org/ploum/offpunk
PS: to be inclusive of gemini/gopher, I prefer the word "smolnet" over "small web". But we understand each other, that’s really a detail.