I love this initiative in principle, but the instructions left a rather sour taste in my mouth. Create a Firebase app, download and install Node and run some arcane cli commands? For what? To upload a 10-byte HTML file somewhere?
Please, do yourself and us a favour and sign up for a free account on https://neocities.org, and make a quirky website by hand for all of us to enjoy.
I half want to write a post like this but with dead-simple instructions, like "Open Notepad, write <html><body>Hello!</body></html>" inside and upload it to Neocities. Congratulations, you now have a website!"
A good addition would be a nice CSS stylesheet (https://newcss.net/ looks good, linked by sdan in his comment here) to get the site looking nice and mobile-friendly. That's pretty much all you need to make a simple website.
https://glitch.com is also excellent. I’ve been using it to teach a website development workshop to 10-15 year olds and it’s the most intuitive interface I’ve found so far for those with no prior experience with HTML/CSS/JS.
Yeah, they let you drag and drop a zip file to create a site, but is geared more towards companies/professionals. Neocities is more geared towards a community of independent creators, though, so I'd rather support/promote them for indie stuff.
WYSIWYG editors are universally bad, and so are Markdown ones. The benefit of Markdown is that you just write it in a text editor. You don't need syntax highlighting to use it effectively. Take reddit, as an example, which got millions of people to write perfect Markdown as intuitively as writing English.
I like entering markdown in text editors, it gives me the freedom to format without fighting the editor. A preview panel helps, and yeah reddit demonstrates that people can learn it.
It really depends on the editor. Some editors give you raw access to the underlying code and apply styles to it as you type, kind of like syntax highlighting. Some actually try to be rich text editors with a (usually restricted) Markdown input. You can guess which ones make me want to flip a table. (Hint: Slack, fix your editor!)
I hate those undisableable social media accomplishments that come up as notifications, is Github.community based on Discourse or did it just copy their bad ideas?
edit: wow you can disable them in this one, amazing. I still hate it.
i think slack now allows you to disable the visual editor in settings - you can still format with markdown but the formatting isn't rendered until you send.
I had more or less the same idea, but perhaps with the markdown syntax extended (I understand this is a touchy topic since there are various markdown parsers that don't all work the same) to allow for simple generation of form controls and navigation bars/layouts.
E.g for navigation sidebar:
* [Home](/home)
* [Blog](/blog)
etc
For form controls:
[ ] I'd like to receive marketing emails.
( ) Female
It'd be even better if it can support basic CRUD/BREAD operations. Basic CRUD webapp with just markdown, imagine that.
I think there are several sites that offer such functionality. Squarespace and Wix immediately come to mind due to all of their advertising. There was some other company I used a while back for a small website for an engineering team, but the name escapes me. These sites are perfect for small business and organizations that just need some web presence without having to think through any of the technical side.
You mean a WYSIWYG editor? Yeah, they want to encourage individuality, though I guess an HTML editor wouldn't be out of the question (I think kyledrake just hasn't found one he liked).
I'll second Netlify. Totally fantastic service; I've played with a lot of "github to deployed app" services, and I was still blown away with how straightforward it was to get a NextJS static site on there, auto-deploying, on a custom domain, with site analytics built-in, no code required.
I find myself torn on the specific instructions. It's certainly a lot more arcane than my early sites, but that was mostly because there was a whole lot of boilerplate handled by the host (Enter these details into your FTP program, put your files into public_html, start with index.html).
I didn't have any idea what Apache was, how files were served, or really anything about internet infrastructure. And that's fine, certainly good for a kid or to whip up a quick business site, but it doesn't satisfy the hacker in me today. There's too much magic going on behind the scenes for me to feel much ownership of it.
I suppose it sort of depends who you're aiming it at. TFA didn't feel to me like it was trying to approach novices (after all, it's talking about leaving frameworks and libraries behind, novices aren't much using frameworks). Your instructions are good for an easy introduction for people with no web development experience, to recreate that sense of ease, but I think it's a different thing from what the article is going for. Even a simple site requires a fair bit under the hood, because serving files isn't all that simple unless you just hide it away from the end-user.
I don't know, I mostly agree with you, but I disagree that a simple site requires that much. Just drop the files in a folder in some web server and you're done.
I do agree that beyond the site being tiny, an important part of taking control back is to question the hosting part. The "traditional" web is, unfortunately, not fit for minimum hosting without either shelling out some money or depending on a third-party (however good it is). It is high time decentralized web alternatives gain adoption.
1. Open Beaker
2. If you don't have any content, select "New Hyperdrive" from the burger menu, enter your site name, and start editing content with the integrated editor
3. If you already have a folder with content, select "New Hyperdrive from folder"
4. You have a website ! Update it locally and changes will be propagated. Your site address is the hyperlink in the URL bar !
There shouldn't need to be more steps and, more importantly, dependencies on external processes/companies/organization to say what you want to say and spread it.
You do need to keep your computer always[0] on, though. I don't mind depending on external companies, I mind depending on external companies that I can't pay to ensure their loyalty to me.
- Beaker, like any decentralized web thingy, allows visitors to re-share content if they wish to do so. Integrity is provided through the crypto bits
- There is of course the possibility to ask a third-party such as Hashbase (https://hashbase.io/) to host content for you. The difference with WWW hosting is that you don't depend on them to serve content at all times, only when you or your visitors can't; you aren't as dependent
Beyond self-hosting, the major differentiator is that the "web" goes further than just interlinking, it also contains safe distribution. Beaker does even more: foreign content is typically accessed through "mounting" other sites, just like you'd mount with FUSE, so an application doesn't really care where the content comes from. It's all files in the same virtual filesystem.
It can be cheaper to host own (desktop-grade) hardware instead of paying someone to host a stupid single website. The calculation is easy, especially if you only take into account electricity and not hardware purchase costs:
Monthly costs per watt are around 0,3EUR/kWh * 24h/d * 30d/m/1000 = 0,2EUR. That's roughly the price tag for keeping a raspberry pi on 24/7 (yes, it's below 0,2EUR/month). For an average desktop/laptop, which will consume way less then 30W in idle, it's 6 EUR/month. The price of an average hosting offer.
Agree.. I ran a home-hosted web site with regular traffic on a Raspberry Pi 2B for a couple of years before upgrading it to a Pi 3. If you get power issues you can always switch to a battery power bank for a while (assuming your router doesn't go down at the same time).
Agreed, you'll lose access to all that server-side stuff after not too long. Just do something dead simple: single page of vanilla html/css. You'll have to move it at some point, the hosting server will need updating or shut down, and a single file is way easier to move around.
My website, https://cyrialize.dev/, is hosted on Neocities. I used jekyll to create it and I use water.css which I found on CSS Bed (https://www.cssbed.com/). The Neocities gem is VERY useful.
Oh that would be fantastic! Where will this template show up? I didn't know Gitlab had CI templates.
How do you upload files without WebDAV? As far as I know, there's no API.
BTW I'm not sure if it still exists, but they had a lifetime supporter account, where you can get a lifetime subscription for $100 in Bitcoin. I got it to support the effort, though I don't really use it, but a bunch of Terabytes of bandwidth and 50 GB of hosting space won't go to waste.
Well that's fantastic, great job. Will it be uploading a specific directory, like in mine? That would be nice since most people keep other stuff in the repo.
Yes, it will upload the public folder only. You can see the details of how it works at https://gitlab.com/pages/neocities (I realize now this would have been a better link to share than the other one).
Yeah, that whole Firebase thing was not necessary. After creating the public folder, dragging and dropping it onto Netlify would've instantly given you a public website. No commands necessary. I use Netlify for everything, even hosting a static blog generated in Hugo. All free, only thing I pay for is my domain.
>“ Things have really changed since I began learning, and rightly so. Instead of coding in plain HTML, CSS and JS, I'm now using endless frameworks, modules and libraries to build increasingly more complex web and mobile applications. It's great, if I didn't use these tools my code would be an unmaintainable mess.”
How sad that this has become the widely accepted narrative.
There’s a lot of value right now in NOT building things that way.
Last week I had to deal with fixing another dev’s mess on a stuck project.
Big company website, but nothing fancy at all. Purely a marketing window. The amount of complexity he put into it by using Vue.js was insane for the scope of the project. INSANE.
To do something as easy as changing the pages <title> tag we had to write an unjustified amount of lines of code.
Framework-itis really is a bad disease, it not only affects your work, but it definitely clouds the simplest form of judgement, it appears.
Then we have exactly this: someone who got a hammer and spent years treating everything like a nail comes to a reckoning, usually framed as a longing for the good old days when things used to be simple.
Well, you know, things can still be simple, if you don’t offload to unjustifiably complex frameworks the duty of understanding what’s going on in your project.
To be clear, I’m not at all against frameworks. I love and use some of them, but they’re like a closet. If you are a tidy and organized person, your closet will be full of neatly folded clothes; if you’re a messy person, it will still be a repository for heaps of displaced garments, ready to fall out as soon as you open the door.
As someone that has used vue.js quite a bit in the past, I have to admit what you came up against is quite odd.
It is a very minimal framework.
He might just be that kind of JS dev that really likes to build a webpack castle.
You know, if you can drop in a url to a cdn-distributed version of a JS, you'll instead rebuild the whole thing in webpack, babel, and several other things just to be able to type "import".
We had a similar scenario at my workplace, but with React rather than Vue.
We wanted an internal component to be able to change the page title, which ended up with a project to transition to using react-helmet. It ended up taking a few weeks before this project completed.
It's not about Vue (or React for that matter). Incompetent developers will take whatever tools they have at their disposal and turn a few hours project into an unmaintainable monstrosity.
True, but in my experience a lot of younger developers have been trained to think in frameworks all the way, with the result of growing a dangerous fondness for unnecessary complexity.
To them, I feel, turning something easy into an opaque mess that the client is of course too dumb too appreciate, let alone understand, is a sign of quality and somehow a matter of pride.
For the aforementioned project, that I could have built up in three days with HTML + CSS + some js sprinkled on top for effects, it took them a month and a half, and then he bailed on minor Cosmetic changes because “the allotted time was over”.
The client was literally fooled into spending more for this bullshit.
I made that _tiny_ website for evenings with friends. It works great. You enter a few names, hit the save button, you get a list with scores and a +1 button for each players. When you refresh the page the scores are reset. The most important feature is the _ding_. The ding makes it fun.
It's ridiculously small, but it brings lots of fun.
It's tiny, it's fun, it's enough. Keyword : enough. Yes I could add a preventDefault, but I don't care. Really, I only entered the names of my friends once, it has been in my localStorage since, and it's only really meant to be used by me.
I didn't see myself asking Tom Scott for his sound effects, the ding is also not the same. And my friends and I have our own gimmick, generally more cheese-based (raclette or fondue) than biscuit-based.
Yeah! I am with you on this. I've used nothing but HTML/CSS for all of my side projects for years. I manually create, update, and publish each page. Hell, I still drag and drop via FTP. It is indeed very fun.
Here's a screenshot of my latest project, nothing fancy, just starting to tinker with Tufte CSS and typography (Lyon Text and Concourse): https://cln.sh/BzBD
It's interesting to note that the website content itself for this article is 5,045 bytes (HTML + CSS), but the analytics code (firebase-analytics.js) is 26,458 bytes, and firebase-app.js (whatever this is?) is 19,865 bytes.
Not a criticism; analytics is important & maybe the app JS is too. Just think it's worth bearing in mind that it's really easy to blow out your website's total delivery impact to users by several times with third party includes.
Even for small personal projects, analytics can give you a lot of insights into what your viewers like. Things like session duration and bounce rate, broken down by page, can tell what content people enjoy and what contents needs some work. Also useful to know what fraction of your users are recurring versus new users to tell whether people actually return to your site or if they just check it out once. Lastly, the refer stats can help you figure out what other sites and communities are interested in your project so that you can further engage with them.
Things like session duration and bounce rate, broken down by page, can tell what content people enjoy and what contents needs some work.
All those things can be gathered from the initial request if you can set a cookie on the user's machine using a cookie header. If you're Firebase then you'd need a request for firebase-analytics.js to set the cookie, but the file itself could be empty.
Also useful to know what fraction of your users are recurring versus new users to tell whether people actually return to your site or if they just check it out once.
Once the cookie is set you can get all this from the server side logs.
Lastly, the refer stats can help you figure out what other sites and communities are interested in your project so that you can further engage with them.
Referers, if they're available at all, come in an HTTP header so once again server side logs would give you this data.
There is no reason to serve any JS for logging unless you want browser fingerprinting data like the user's window size. If your analytics script is more than 0kb then you're tracking people.
This is so incredibly true. It's astounding how an entire generation can't be bothered to look at their own server logs and think they need to pipe it off to a third-party to let them present graphs to you.
To be fair, you can't tell how long someone spent looking at page using just cookies. You can't distinguish between me (a) loading your page then immediately closing it, (b) loading it, reading it for ten seconds, then closing it, (c) loading it, reading it for ten minutes, then closing it, and (d) loading it, leaving the tab alone for ten minutes, reading it for ten minutes, then closing it.
But it doesn't take 50 kB of JS to be able to do that!
You can't tell if I load a page and then walk away and spend 5 minutes making a cup of tea, and then come back and close the tab without looking at it either. Even with JS. Assuming that having a tab active and focused means a person is engaged with the page is false.
Also, believing a page is better because I spend 10 minutes on it rather than 5 is nonsensical. Am I reading everything (good) or am I hunting around for some piece content and not finding it (bad)?
Time on page is a stupid metric that doesn't measure anything useful.
And that's when things get seriously invasive and people start saying "Why are you using a 26kb tracking script?"
If you collect information about how often a user is moving their mouse and scrolling the page in order to tell how long someone has been on a page then you've moved from collecting what's useful to collecting everything you can just in case it's useful. That decision comes at the cost of invading everyone's privacy, and that needs to stop.
Some people care about any of that stuff, but it's perfectly reasonable to make a site/page/app that just does something without trying to grow a community or engage or anything.
I'm working on Plausible Analytics which is only 1.4 KB right now and provides a modern dashboard. It also doesn't use cookies and doesn't collect personal data so you're not required to show the cookie/GDPR prompts which would make tiny websites much less tiny.
You claim that using your analytics doesn't require user consent:
> "Plausible does not use cookies and does not collect any personal data. This makes us compliant with the different cookie laws and privacy regulations. It means that you are not required to annoy your visitors with a cookie notice if you’re using Plausible analytics." [1]
> "Compliant with privacy regulations: Google Analytics places cookies and collects a lot of data from your visitors. You’re required to have a privacy policy, to show a cookie banner and to obtain consent for GDPR. Plausible Analytics doesn’t use cookies and doesn’t track personal data so you don’t need to annoy your visitors or worry about those prompts." [2]
It would seem you are collecting PII and processing it server side (?), e.g. calculate_fingerprint here [3].
Care to explain how that doesn't require user consent?
Instead of setting a cookie with a unique user ID, we simply count the number of unique IP addresses that accessed your website to determine the visitor count.
To enhance the visitor privacy, we don’t actually store the raw visitor IP address in our database or logs. We run it through a one-way hash function to scramble the raw IP addresses and make them impossible to recover.
To further enhance visitor privacy, we add the website domain to their IP hash. This means that the same user will never have the same IP hash on two different websites. If we didn’t do this, the hash would effectively act like a third-party (cross-domain) cookie.
Network Address Translation allows many unique users to share the same public IP address. For this reason we also add the User-Agent string to the hash, although we don’t store the actual User-Agent string.
Mine[1] is rather tiny and simple. It is actually generated by the tree command in about a second. It's a port from the gopher protocol and is hosted by the venerable sdf.org[2]. I decided to pay an exorbitant $60 a year for an enhanced membership simply to have an https address and some other assorted goodies[3]...
I was considering joining SDF, but I'm confused about the membership levels. What's the minimum level needed for static html hosting with a domain I already own?
with static sites server-side analytics are doable. You can still cookie the browser, record it to access log and you can get pageviews and uniques easily
Problem is if you're using a CDN it might not give you access to complete logs. Still there's at least one better free option than GOOG analytics IMO[0]
So? I have javascript disabled so a frontend analytics option also won't give you complete analytics.
It's a tradeoff, you get to decide if you run code on your visitor's computers without consent and get analytics that are wrong in one way, or if you run code on your server with your own permission, and get analytics that are wrong in another way and simpler.
> During my time using frameworks I've become more and more out of touch with the code I'm writing. For example, when I plonk down a button in the Ionic Framework I get a beautifully engineered and designed button, but it also has 10 CSS classes attached to it that I don't really understand. I sometimes feel like the thing I've created isn't truly "mine".
That seems to be the nature of CSS utility frameworks. Composition over inheritance; or in this case monolithic element styles. Is the utility function to fetch elements from the DOM tree also truly "yours"? Where's the line drawn? I could get the text representation of the DOM tree and write my own parser? How about that?
> I therefore decided to go back to the basics and code my own tiny website. I already knew how to go about it, you probably do too, it's really easy (if you don't know here's how). However, I'd never actually done it, and I'd not made a website without a framework in over a decade.
Ah! And there's the problem! Are you creating a website or an application? I do understand that this feels like a cleansing of sorts. But in my opinion doesn't reinforce the original argument.
I think the more experience you gain as a developer the more often you will come to the realization that technology evolves and also becomes more nuanced over time. When confronted with this fact of course the first instinct will be to feel overwhelmed and return to basics. Which if you're creating a mostly static website in this case is perfectly reasonable. But you can't be an expert in everything. Thus frameworks and tools emerge to alleviate some of the pain that stems from designing applications not websites.
Which again reinforces another often quoted realization: the right tool for the right job.
Most of the "small" designs and frameworks I've seen are quite large, in my mind. I just finished building a minimalist html/css template for some of my own projects. I'm starting to feel like this is some lost art form.
Your `pre` elements are set to `overflow: scroll;`. You pretty much never really want that. (And it looks terrible on platforms that still have real scrollbars instead of the iOS-style overlay indicators that fade away. It should be `auto`.
I couldn't decide on this one. When I centered it, it didn't feel quite right. I searched the web for examples, and found a lot of left aligned examples, so I went with that. I also had this in my design decisions, but because I hadn't really decided yet, I took it out.
Tiny websites are indeed great. They load fast, and minimize the steps involved in publishing content. I think my sentiment however, practically (i.e: in a business, startup, big company) conflicts with two things/requirements:
1. People who usually write content are not developers
2. People tend to trust sites that are minimal like the one OP posted.
Content writers traditionally come from background where they are trained and use tools like wordpress. We are now asking them to write HTML. I believe Jekyll here is a good compromise. We can generate static sites using Jekyll while still allowing simpler tools pre-publishing.
Regarding my point #2. Not a week ago, there was a thread to discuss how cool Stripe's animations are. There were multiple conversations in said thread that attest to this fact. Many people look for a sense of branding on product or service based businesses and relate those to their legitimacy.
I think my sentiment for small/simpler sites is a pretty common one on HN, but I think it all boils down to who your users are and what they prefer.
My personal website, https://g5t.de uses a custom directory-listing kind of framework I wrote - so it doesn't tick all of the requirements. It's not much, but it does its job kinda well (still lacking notable, deep and interesting content, sorry).
That is very nice, a little broken in some places: the [001]-how-to-not-build-a-router link doesn't work, you have to click the .md file, and your github link is broken
I see that this is your first submission. I love that it is refreshingly original.
Now, there are two main steps to making a website public.
* Developing the website (idea, design, development)
* Hosting it (domain, email, host, server)
What you posted is great for emphasizing that the first step can be done in a very simple way, without any complicated frameworks.
The way you did the second part - hosting your site (Using Node.js/npm, Firebase, and npm package) - does not fit well with the simplicity you demonstrated while doing part one.
However, if considered as a how-to for building a tiny website using Firebase, it is awesome.
>No libraries or frameworks (the exception being analytics)
No, analytics are not an exception. Don't put fucking spyware on your pages. I can't believe it's 2020 and people still need to be told this. It's not okay.
I think the same idea can be applied to the backend as well, instead of creating a firebase account, and allowing someone else’s code to magically serve your tiny website. Granted, its not as simple as <h1> Tiny Website </h1>, but it is just as satisfying to build something on the backend that is “your own”, as least in my humble opinion.
I have a (french) blog[1] having analytics for first years. I realize most page views where not necessary the ones I had the most fun at writing. It was sad to realize your next post would not necessary bring interest and you start to bring what you guess peoples would be interested in, and not what you are interested at in the first place. It breaks motivation on the long run. Like if you where no more blogging for yourself.
I finally remove analytics and now write what I love without being to rationals. It brings far less pressure.
I have been working on a tiny website aiming to teach Japanese using HTML/CSS and Emojis. It is hosted on Github pages. I take this opportunity to share it since I believe it is the kind of website that people miss.
The main problem I have is that despite some love for this type of website on Hackernews they are not really popular. Also, they are not accepted in Show HN.
> 2. As few CSS tweaks as possible
> 3. It must be fun to build
I personally enjoy messing with CSS, it's incredibly fun to try new things and give an otherwise boring page some life and expression. Obviously there is a fine line between tasteful design and obnoxious/unnecessary clutter but a simple website with some character via design is much more memorable that black text on a white background.
CSS 3 is absurdly powerful and, if you use semantic HTML, progressively degrades really well. Putting just a bit of your touch on the content is a nice feature to take advantage of.
Since we're talking about tiny websites, and this seems pretty relevant:
If it's only static HTML and CSS, it's just a bucket o' files. You can store things like that on S3 for... I don't even know how little. A tiny amount. You will not find a cheaper hosting option than this.
I made this site on S3, using Svelte, which is intentionally the humblest, smallest step up from plain JavaScript HTML & CSS, at the link below.
Now, the one drawback here is that this doesn't have HTTPS, and you'd need CloudFront for that. This link covers how to do that (note: you should buy your domain on AWS, using Route 53, when following these instructions to make your life easier).
You will find a cheaper hosting option. GitHub and GitLab pages are both free for static sites. I've used both, they both are pretty painless. You basically click "make this a website" and tell it your URL. Automatically HTTPS, completely free.
> You will not find a cheaper hosting option than this.
If you just want to host static files with HTTPS and reasonable traffic, there's several free options. Netlify, Github Pages, Gitlab Pages, Neocities, ...
I agree that S3, Route 53, Certificate Manager, CloudFront are great for serving small static websites, but as others have mentioned there are plenty of free alternatives. Nonetheless less, I think this approach is the right solution if you're already in the AWS ecosystem since it integrates well with other serveries. E.g, adding LambdaEdge if you need some dynamic components in the future.
I eventually added an editor that displays the html source in a textarea. Above it is a field with the file name, below is the submit button and a password field. (There also is a cookie req that I make manually and it does some IP checks when trying to save.)
After submitting it checks if there are links pointing at the (new) page. If those are missing the "success!" page gets a link pointing back at the editor with the index appended to it as the query string, the url that must be added and the page title. (the substring between <title> and </title>)
When clicked it loads the index into the editor and inserts a link into the html (so that I can move it around or type text around it)
That same functionality is reused by a bookmarklet to insert www links into pages. (it also inserts highlighted text from pages)
Except the save page everything is still static html.
Managing a website and writing for it are two different activities to me. I prefer to do the latter in a WYSISYG editor. I don't want to fire up a terminal to deploy content changes.
With proper caching, the output of a CMS can be indistinguishable from a static site, but it can also include RSS, pagination, categories, tagging, responsive images, tables of contents, etc.
Take https://allaboutberlin.com. In my browser, most of its pages load faster than the tiny website above. It has a big header image, custom fonts and other features. You can achieve great things with HTTP2 server push, static caching and gzip.
You should definitely consider making simple, fast websites because they're great for visitors, but how you produce the HTML doesn't matter.
Sure, but they need to be generated by some sort of framework, somewhere. If your definition of a static site includes framework-generated index pages and page structures, aren't almost all websites static already? Making them tiny is just a matter of writing better templates, not picking more obscure frameworks.
In my books the difference lies in how the HTML is generated. In case of static sites you generate it only when you rebuild the site after changes. In dynamic sites you build it dynamically on each request. Sure, you can cache the hell out of it and have a feeling that it's the same, but the truth stays that perhaps you're doing 50 SQL queries for a simple "welcome on our site" landing (something I actually witnessed some years ago). And with caching you're achieving the result with adding another infrastructure layer on something that could have been dead-simple from day one.
Initially, I wanted no JS and for it to look good in a text-based browser like links, too, but I've strayed from that a bit. Syntax highlighting of the code examples was easiest with a javascript include, and the TOC is a mess hidden by CSS, so it looks particularly egregious in text-based browsers.
The website is still functional without JS and text-only, though, and without the favicon and syntax highlighting it comes in at ~4kb to load a page, which I'm happy with; with them it's closer to 40kb, which isn't the worst.
How far down the abstraction tree do you go before something is 'pure'? Programming on the whole is at a much higher abstraction level than ever.
Maybe what people are really looking for is simplicity, but this changes depending on the complexity of your project. Therefore the question becomes, "What is the best level of abstraction for this project?"
I do HTML from scratch and Flask w/HTML templates at most. Adding a couple of CSS files is all I'm looking towards, not a bunch of weird React code (which imo looks ugly).
I love the original thinking in this post. If there was no React/Angular/VueJS, how would YOU design ANY system to help you code faster and more maintainable? That what I'd love to see: more original ideas to solve complex tasks, and not stopping at the first idea coming to mind.
BTW: I believe tailwindcss is fantastic at achieving and helping with the OP's frustration.
For me the biggest requirement is
> 3. It must be fun to build
for me that requires a level of abstraction, I don't want to be monkeying with HTML if I don't have to, I just want to write the damn article. That's why I use Hugo, I feel like it hits a fantastic balance between speed for the user and ease of maintenance for me.
Along the same vein, I've been working on a Vi-like editor for creating webpages [0], and if anyone's looking to create a tiny website, it's worth checking out.
If you enjoy using Vi, you'll likely have a blast using this one.
Really awesome idea! I ended up following suit and whipped together http://kojichamber.com to put out the list of things I used to build a fermentation chamber and the nuances of one.
Really love building tiny projects like these. Had built a simple online code editor a long time ago for exactly these types of projects. http://codecast.me (not optimized for mobile yet)
Just a nit: Using "max-width: 600px;" leaves enormous white margins on either side of the text, when browsed on larger monitors. I wish CSS writers would stop trying to guess the width of my screen.
Reminds me of the 90s when I first started out. In a way it's a shame that the basics have been forgotten, and the first step taken to develop a website is a cli app to install a load of boilerplate.
Ugh, how I loathe the term "full stack". Many who claim this have attended a 12 week crash course where they're armed with the programming equivalent of heavy weaponry and then turned out onto the world to "engineer" websites that are bloated, slow me-too creations with background video, fly-in scroller elements, and everything else that bogs down even the most powerful PC.
"Many were increasingly of the opinion that they'd all made a big mistake coming down from the trees in the first place, and some said that even the trees had been a bad move, and that no-one should ever have left the oceans." - Adams
Why not go a step ahead and host it on a raspberry pi from your home. Then one could copy the text file directly to the public folder or create the file in the rpi itself.
I really like the concept lets say you want to include a code snippet does it support the syntax highlighting and do you write a blogpost in plain html or markdown
You can always write in Markdown, say with iA Writer, then export to HTML. I typically write offline, then type and revise on the computer, then copy paragraphs over to Sublime. Code snippets and syntax highlighting done with CSS.
It worked fine for me, and judging from comments on this page that respond to the article not just the title, for many others.
If you see this message in Firefox for many sites (try some random sites you rarely visit) it's probably a local problem such as "Anti-Virus" software or a "security" appliance helpfully making stuff unsafe. Get rid of them if possible.
It is possible that, as the message says, there's actually "Possible Security Issue" just for you, or some subset of visitors, and we can't really help you diagnose that. Maybe your ISP, or your government, or that nerd neighbour kid who said she'd fix your WiFi are trying to snoop you. But probably not.
It's also possible the server hosting this went a bit haywire maybe under the load. It's clearly on some cheap bulk host and those can be a bit flaky.
Can you please make your substantive points without being a jerk? We're trying for a bit better than that here, and it's all too easy to come across that way, even if you didn't mean to.
I can't think of any reason why they would be. SEO things to do on your own site are all about content, markup - nothing about a tiny site is a problem here. In fact, speed of website is (was?) a important SEO factor - so by definition tiny websites start with a massive plus.
Why are they bad for SEO? The author seemed to be talking more about CSS and JS rather than content - does not using bootstrap or ReactJS mark you down on search results?
Please, do yourself and us a favour and sign up for a free account on https://neocities.org, and make a quirky website by hand for all of us to enjoy.
I half want to write a post like this but with dead-simple instructions, like "Open Notepad, write <html><body>Hello!</body></html>" inside and upload it to Neocities. Congratulations, you now have a website!"
A good addition would be a nice CSS stylesheet (https://newcss.net/ looks good, linked by sdan in his comment here) to get the site looking nice and mobile-friendly. That's pretty much all you need to make a simple website.