[HN Gopher] My stack is HTML+CSS
___________________________________________________________________
My stack is HTML+CSS
Author : zdw
Score : 189 points
Date : 2021-01-07 16:54 UTC (6 hours ago)
(HTM) web link (blog.steren.fr)
(TXT) w3m dump (blog.steren.fr)
| Rauchg wrote:
| This is an inaccurate over-simplification. If you just use HTML
| and CSS, you can also have really bad Lighthouse scores. For
| example, vanilla `<img>` will ship the same image to every
| device, regardless of viewport size. Vanilla `<img>` doesn't
| enforce setting `width` and `height`, which makes your layouts
| shift. Slow-loading images and layout shifts are the very things
| that will downgrade the "100" score he's currently proud of.
|
| Frontend performance is basically an iceberg[1]. We tend to look
| at the top and that's where the fashionable "silver bullet"
| currently is (whether Rust+wasm or HTML+CSS or a JS framework).
| Then we find deeper in the iceberg that even a `box-shadow`
| property[2] can ruin our day, and let alone images, YouTube and
| Twitter embeds, and all the things that make the web more
| interesting and powerful than a black page with white text.
|
| Oh and it gets even more fun! A Lighthouse score in itself is an
| over-simplification. There's more to a great experience than the
| initial impression the site makes, like what happens to FPS when
| you scroll or click around[2]
|
| [1] https://rauchg.com/2020/next-for-vercel#realistic
|
| [2] https://ishadeed.com/article/new-facebook-css#using-an-
| image...
| dceddia wrote:
| Oh boy, YouTube embeds! I went through checking the Lighthouse
| score on a few of my pages a while back, and the ones that had
| videos were performing pretty badly.
|
| It turned out that embedded YouTube videos were pulling down
| something like 1mb of JS, _just to show the thumbnail_ , before
| the user even clicked Play.
|
| I ended up making a static thumbnail with a hover-over "play"
| icon that would replace itself with the real embed when it was
| clicked. Got the Lighthouse score up and saved all those
| unnecessary downloads. But it was pretty amazing to me that
| while one arm of Google is pushing for web performance, another
| is building this YouTube player that auto-downloads a megabyte
| of JS just to show a thumbnail.
| winrid wrote:
| You can also use lazy loading with iframes.
| leerob wrote:
| Twitter embeds are equally bad. Ended up remaking them to
| output static HTML + CSS to improve perf
| (https://leerob.io/tweets).
| umaar wrote:
| Same, I get ~500 tweets displayed with:
|
| - No JavaScript necessary
|
| - All profile images turned into one massive sprite
|
| - Minimal payload size
|
| Here are what the tweets look like when rendered:
| https://umaar.com/dev-tips/feedback
|
| Here's the code to achieve that:
| https://github.com/umaar/better-twitter-embed
| toinbis wrote:
| Well done, thanks for sharing!
| leerob wrote:
| Nice job!
| recursive wrote:
| As a user, I hate twitter embeds. If I select text inside
| them, they redirect my user agent location. That's never
| what I want.
| leeoniya wrote:
| [srcset]
|
| https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
| alberth wrote:
| You might not be aware of the '<picture>' HTML tag that only
| sends the correct size img to the user based on their browser
| size.
|
| https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...
| Rauchg wrote:
| Definitely. But notice he's not using the <picture> tag in
| this post for his image. "Just HTML+CSS" cannot possibly be
| connected to the 100 score conclusion (same for dismissing
| WordPress, which could have yielded that element as well.)
| m___ wrote:
| Just meant to be humorous, does your brain not provide any
| illumination, while at it, do you have time and energy left to
| address other then software in itself, for adding to the cycle
| of aggregate rentier-ism?
| tomc1985 wrote:
| Back in the day you sized your image for the web, there was no
| need for dimensions in img tags
|
| > For example, vanilla `<img>` will ship the same image to
| every device,
|
| As it should be, for simplicity's sake.
|
| Designers trying to assert pixel-perfect control of layout is
| part of why the web sucks so much today.
|
| Let the browser handle layout, that is one of the things it is
| designed to do!
| [deleted]
| fouric wrote:
| Removing the dimensions from the image tags is absolutely the
| wrong thing to do.
|
| If you do this, then a browser/user/client that wants that
| information simply doesn't have it - you can't create bits
| from thin air.
|
| If you leave the metadata in, then any browser that wants it
| can use it, and any brower that doesn't want it can ignore
| it.
|
| I can code up a Greasemonkey script in a few minutes that
| will strip the width and height attributes from img tags, but
| nobody on earth can write a script that will magically detect
| what size the author wants them to be if they don't send that
| data to you.
| onion2k wrote:
| _Designers trying to assert pixel-perfect control of layout
| is part of why the web sucks so much today._
|
| Sending a high resolution image to a user with a low pixel
| density display is wasting their bandwidth and battery.
| Sending a low resolution image to a user with a high pixel
| density display isn't giving them the good experience they
| paid for when they bought a high end device.
|
| Optimization is about giving all the users the best
| experience you can on a website. It doesn't necessarily
| change the design at all.
| pastjean wrote:
| Well on my low latency nordic cellphone connection, it's
| always nice to receive a lower resolution image. Especially
| if I don't have the resolution to display it
| onion2k wrote:
| It would be good if more browsers and websites implemented
| the prefer- reduced-data setting that Chrome and Edge have
| right now, but you do have that option in Chrome for
| Android right now. https://developer.mozilla.org/en-
| US/docs/Web/CSS/@media/pref...
| masswerk wrote:
| I fail to understand why you wouldn't set dimensions for an
| `<img>`tag or use a `<picture>`tag with `<source>` elements for
| appropriate variants using just HTML and CSS.
|
| (I'm doing this all the time, also with perfect Lighthouse
| scores. That is, there's often also a bit of PHP involved for
| includes and setting some meta tags, and a bit of non-essential
| JS sprinkled in.)
| [deleted]
| henlo wrote:
| > Vanilla `<img>` will ship the same image to every device,
| regardless of viewport size.
|
| You can have responsive images with vanilla <img>[0]. You can
| even lazy load images with just `loading="lazy"` attribute[1].
| I'm pretty sure I can optimize more things.
|
| I'm mostly agree with this blog post. Plain HTML+CSS is really
| good for simple webpages, like landing page or portfolio that
| requires less update. But for a blog with pagination? I don't
| think so. Imagine updating each page in plain HTML. SSG can
| help my life easier.
|
| [0] https://developer.mozilla.org/en-
| US/docs/Learn/HTML/Multimed...
|
| [1] https://web.dev/browser-level-image-lazy-loading/
| z3t4 wrote:
| Also sending binary images and rendering them is very light-
| weight. They are also cache friendly (doesn't change often).
| Rauchg wrote:
| The point is that "just HTML+CSS" is not the recipe for
| performance. You get into the same nuance as any other
| technology: _how_ you use HTML+CSS is the recipe for
| performance. In fact, his image in this blog post doesn 't
| have `width` and `height` set, so had it been higher up on
| the page and part of the "Largest Contentful Paint", not sure
| we'd have a 100 here.
|
| This is where frameworks can be really helpful, and I
| wouldn't dismiss them. It gets quite tedious to keep up with
| the new attributes, cross-browser and cross-platform
| differences, image optimization CDNs and so on :)
| apolymath wrote:
| JS frameworks are for noobs. HTML+CSS is the way.
| https://saber.datasilk.io
| lhorie wrote:
| At the same time though, in my experience, performance
| optimizations follow paretto's law: try to get 80% of the
| way with 20% effort. There are pitfalls both with and
| without frameworks (e.g. it's equally easy to accidentally
| plop a hi-res image into a Next.js app), but generally
| speaking, limiting the tech stack means there's less
| potential stack-specific pitfalls.
|
| If "I'm gonna restrict myself to HTML and CSS only" gets
| them 80% of the way to their performance goals then IMHO,
| that's a perfectly valid approach.
|
| As far as images go, the reality is that most mainstream
| sites with image/video content are heavy sites with multi-
| second page load times, despite literal millions of dollars
| being spent on engineer salaries. In that context, does it
| really matter if a random blog decides to just use pngcrush
| and a dumb img tag for the occasional eye candy imagery,
| instead of whatever is the state of art multi-resolution
| technology?
| [deleted]
| maloshackeros wrote:
| As a Fortran programmer I approve of this post.
| Evidlo wrote:
| Why can't HTML some kind of templating system, or even simple
| includes? Then I wouldn't need to use a static generator and
| could just author HTML directly.
|
| e.g. (with hypothetical <extends> and <block> tags)
|
| template.html <!doctype html> <html>
| <h1>My Fancy Blog</h1> <block main/> </html>
|
| index.html <extends "template.html">
| <block main> <body> Hello world
| </body> </block>
|
| Maybe this would compromise browser performance or add some kind
| of vulnerability, but authoring DRY HTML directly is my fantasy
| crazypython wrote:
| It's called XSLT
| sseagull wrote:
| Not exactly HTML, but webservers typically support server-side
| includes (SSI).
|
| https://en.wikipedia.org/wiki/Server_Side_Includes
| err4nt wrote:
| Look into custom elements and web components, HTML already has
| amazing stuff built in, supported in every browser, and maybe
| even being used on some of your favourite sites!
| progval wrote:
| > Why can't HTML some kind of templating system, or even simple
| includes?
|
| XHTML does, it's XSLT.
|
| For example: <?xml version='1.0'
| encoding='ASCII'?> <?xml-stylesheet type="text/xsl"
| href="stylesheet.xsl"?> <root> <title>Page
| Title</title> <block name="main">
| <article xmlns="http://www.w3.org/1999/xhtml">
| <p>Hello world</p> </article>
| </block> </root>
|
| With this in stylesheet.xsl: <?xml
| version="1.0" encoding="ASCII"?> <xsl:stylesheet
| version="1.0"
| xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
| <xsl:template match="/root"> <html
| xmlns="http://www.w3.org/1999/xhtml"
| xmlns:xhtml="http://www.w3.org/1999/xhtml">
| <head> <title><xsl:value-of
| select="title" /></title> </head>
| <body> <h1>My Fancy Blog</h1>
| <xsl:copy-of select="block[@name='main']/xhtml:article" />
| </body> </html>
| </xsl:template> </xsl:stylesheet>
|
| And it's supported by all major browsers. Probably even IE6.
| ironmagma wrote:
| Very much like saying, "my vehicle will outlive yours. No, it
| doesn't have wheels or axles, because my vehicle is the human
| legs."
| type0 wrote:
| "The World Reveals Itself To Those Who Travel on Foot"
|
| - Werner Herzog
| netizen-9748 wrote:
| More like saying '...because my car is the public bus system'
|
| Github pages is still software, running on a server
| ironmagma wrote:
| Github pages is more akin to the roads; if Github, a
| particular road, were to go away tomorrow, your site could
| just use a different road.
| v3ss0n wrote:
| Try that in a big , enterprise project and come back and say.
| Tomte wrote:
| My Wordpress blog has a system font stack (that's vanilla
| Wordpress with the current theme Twenty Twenty One), and a
| Lighthouse score of 100 Performance, 100 Accessibility, 100 Best
| Practices, and 98 SEO.
|
| The only plugin that's relevant for that is WP Super Cache.
|
| I don't know what the author did with his Wordpress, but even the
| awful Twenty Twenty theme with the broken fonts wouldn't give you
| a 19 score in Performance.
| nikivi wrote:
| The only issue I see with going pure HTML + CSS is that you lose
| those smooth client site transitions that tools like
| next.js/gatsby give you.
|
| Is there a library that can give you HTML + CSS low kb site but
| those client site fast interactions (no page reloads)?
| projektfu wrote:
| Combine your static site with intercooler.js or Htmx.
| netzone wrote:
| I'd say probably Turbolinks is your best bet there. You
| basically drop it in, and then it prefetches all the links on
| your page, and when you click them, it replaces the DOM. It
| works quite well actually, Rails has been using it out of the
| box for years and years.
| nikivi wrote:
| How come GitHub isn't using Turbolinks then? Because each
| link transition will reload the page.
| henlo wrote:
| Plain HTML+CSS is really good nowadays. You can for example lazy
| load images with `loading="lazy"` attribute. You don't need JS
| anymore just to lazy load images. You can use plain CSS for
| simple interaction like opening and closing menu, toggling
| pricing plan, etc.
|
| If you're curious with what you can build with plain HTML+CSS,
| check out my side project[0]. It's a collection of free landing
| page templates in plain HTML+CSS (no JS). No frameworks, no
| preprocessors.
|
| [0] Uisual: https://uisual.com
| TheRealPomax wrote:
| Not needing to write markup at the time of content generation
| even better than writing HTML, though. Use any of a million
| static site generators and get the benefit of writing what you
| want to write in the most efficient format for that, without
| needing to program the typesetting markup while you're writing.
|
| HTML is in no way the best tool for write content. But it _is_
| the best tool to serve content in a browser.
| m___ wrote:
| The browser is the bitch. Out of control, bloated, willingly
| so, in interaction with layers of scripting on both sides.
| The server and client are bait. There should be a serious
| effort to tackle the world of academics and their use of
| analog tools for digital publishing. Nothing is better mined
| and searched(for any entity not meta-rapers that "employ"
| slave coders as battery-chickens) as text. There should be a
| tendency to reductionist auto-censuring or have coders but
| one ambition? Being scooped up by corporations for scraps so
| they can piggy back on their wild efforts for cents on the
| dollar?
| robertoandred wrote:
| CSS-only solutions for interactions are usually awful for
| accessibility.
| kome wrote:
| my homepage, pure html+css https://mrtno.com/ (not optimized for
| smartphones)
|
| p.s.: hire me pls.
| canadianwriter wrote:
| My site too, it has made life SO much easier:
| https://kolemcrae.com/notebook/whynocms.html
| [deleted]
| unabst wrote:
| I feel like there should be some better way to recognize and
| promote solutions that are future proof. Like transpilers and
| site generators that only produce vanilla code for deployment.
| Because it wouldn't matter how dated the tool is. Sticking to
| vanilla only is not the only option.
|
| But I guess there could still be vulnerabilities in HTML that may
| need to be addressed? Like cross domain or cookie security...
|
| But then again, same for a vanilla stack.
|
| It definitely seems like maximum future-proofness should be more
| of a thing.
| m___ wrote:
| The thing, auto-censureship should fit in, as well as the code
| a-n-d hardware life-lines, including how to reproduce the
| workflow outside of corporate claws.
| pgcj_poster wrote:
| <title>My stack will outlive yours</title> <meta
| name="description" content="My stack will outlive yours">
| <meta name="twitter:title" content="My stack will outlive yours">
| <meta property="og:title" content="My stack will outlive yours">
| "name": "My stack will outlive yours", <h2>My stack will
| outlive yours</h2>
| steren wrote:
| So what?
|
| Don't Repeat Yourself? I'm OK repeating myself if that can
| avoid me taking a dependency on fragile tooling
| Wowfunhappy wrote:
| The one thing I really feel like I'm missing out on, in my own
| no-build-system Github Pages site, is an RSS feed. A couple of
| people have emailed me asking if there's a way to be notified if
| I make a new post, but I don't see how I can do it without
| bringing in an external service.
| progval wrote:
| What about your commits' RSS feed; assuming most of your
| commits are only to add a page?
| [deleted]
| pedro1976 wrote:
| Have you tried https://github.com/damoeb/rss-proxy ?
| Wowfunhappy wrote:
| This is the sort of the thing I may eventually go with. (And
| I hadn't seen this one, so thank you!)
|
| But it feels more than a little like I'm essentially adopting
| a build system, since I have to run this manually each
| update. The idea was I wanted a stack which I could not touch
| for 10+ years, and nothing would go out of date and stop
| working. I don't think I have that safety for anything
| involving NPM...
| projektfu wrote:
| The main issues are the ergonomics of authoring and maintaining
| consistency around a site. A minimal static site generator would
| keep internal links and boilerplate consistent. Connecting that
| with markdown, Org mode, or reStructured Text would help with the
| ergonomics. But then you lose the goal of having no necesary
| tools.
|
| Anyhow, if there's one general purpose tool that predates the web
| and will probably be around when it's replaced by some other
| content publishing standard, it's Emacs. You could do a lot with
| a minimal SSG in Emacs and Org Mode, and it would be forward
| compatible with whatever is in the future, as well as backward
| compatible to whatever you like.
| cxr wrote:
| > A minimal static site generator would keep internal links and
| boilerplate consistent.
|
| Maybe not. There's an argument to be made that says you should
| treat a blog as a series of pages, each modeling something
| corresponding to what you might call a "publication event" in
| the real world, e.g. printing a magazine or passing around a
| physical memo. The consistency angle is probably overvalued
| (not worth its cost). When a newspaper or magazine changes its
| masthead, old issues don't get updated. You might say that this
| reflects a limitation of the physical medium and that you would
| if you could (as is the case with digital editions), but what
| does it get you, really? Your links to external sources are
| already going to lead to wildly different forms of presentation
| outside your control.
|
| If an internal link leads to a page published in 2014, and it
| still matches the way it looked in 2014, is that a problem?
| (And if so, e.g. due to changes in fashion/trends that have led
| to it being intolerable, it's worth asking, "what makes it
| so?", "was it ever really tolerable, even in 2014?", and "is
| the material I'm publishing right now guilty of the same thing
| --its presentation only squeaking over the threshold of
| acceptability because of something else that's currently en
| vogue but soon won't be?")
| projektfu wrote:
| OK, but blogging isn't the only type of site you might manage
| like this. Documentation, for example, you want to update
| your links properly when you change the name of a function or
| whatever. Or perhaps you have a catalog naming files by SKU
| and those can change.
|
| And, if you're just blogging, and you want to have the
| permanence you're talking about, you still need to ensure
| that all your links are properly linked, which requires some
| tooling.
| rimliu wrote:
| Yes, I remember seeing this idea. Some blog was making new
| design for each of the post. I really liked that, but I did
| not see it getting popular ever back in the days when FB was
| not yet a thing and websites used uniques designs instead of
| the cookie-cutter so popular today.
| xkcd1963 wrote:
| "will never have any security vulnerability" that is a good joke
| considering that css keyloggers have been around since a while
| gunnarmorling wrote:
| What this approach doesn't really consider is that the same
| contents may appear multiple times on a site:
|
| - actual post
|
| - teaser on the front page
|
| - RSS feed
|
| - search index
|
| - title in multiple "tag" pages
|
| - title in sitemap
|
| - title in a paged list
|
| etc. pp. Sure, you can maintain all that manually, but it's so
| much easier using an SSG like Hugo.
| netizen-9748 wrote:
| This post appears to assume that github pages will never have any
| vulnerabilities ever and will always be available.
| webscout wrote:
| Great, now show me the money.
| miguelmota wrote:
| Has anyone tried to create something other than a simple blog,
| like an actual web product with with users, using only the
| HTML+CSS stack?
| ratww wrote:
| I worked in a project from 2010 to 2014 which was just HTML and
| CSS.
|
| It was a University portal for teachers, students and admin
| staff that handled almost everything in the campus: grades,
| attendance, class schedule, downloads, renting books in the
| library, making room reservations, lunch vouchers for staff, a
| helpdesk system for students and staff, getting a free email
| account, etc.
|
| The goal was to be simple enough for non-technical students and
| older teachers. Most things were one click away from the home
| page, which was just a bunch of colorful icons. You clicked one
| icon and could see schedule, grades and attendance. The teacher
| could edit grades and attendance of the whole class in a single
| screen.
|
| There were no special requirements to drop JS. We just removed
| JS at some point and never added anything again.
|
| Frankly it worked pretty well. The design was made by a
| professional rather than using off-the-shelf stuff.
|
| What killed it was a migration to Bootstrap around 2015 after I
| left. For no reason. The layout ended up looking outdated
| compared to what we had, and the animations and javascript
| dropdowns were too heavy for the University's ageing computer
| fleet. The extra whitespace from default tables made everything
| too big to fit in a screen. Kind of a pity.
|
| But by this point everyone was moving to phones anyway, so the
| university spent a couple million in an iOS/Android app.
| deckard1 wrote:
| That's impossible. You're going to need a backend, which at
| that point it stops being HTML+CSS and becomes LAMP or
| something.
|
| The only thing I can think of that can be done in pure HTML+CSS
| that would drive any sort of revenue and could be considered a
| business is an affiliate marketing site. I suppose you could
| also run a survey site and collect feedback via mailto link,
| but that's really old school.
| stimpson_j_cat wrote:
| Yes. In the nineties.
| ghostbrainalpha wrote:
| I'm also a huge fan of keeping things simple. But there is a
| reason we are having this conversation here, and not in the
| comments section of his blog.
|
| Comments are something I consider pretty vital to even a basic
| blog now. And so he's kind of missed the mark for me.
| m___ wrote:
| My approach of theoretics goes in that direction, more or less
| accentuated on different goal settings. Your approach must work
| for you as for sheer efficiency. You will spend more time on
| relevant issues, if so desired, of producing meaningful content.
|
| Now include hardware into the same philosophy, the long term into
| shelf live, a single programming language worked on by dedicated
| knowledgeable individuals ideally. You are on our side of things.
|
| A page (web/print) should be written, locally, off-line, in the
| same editor of always, in open-source code, preferably the blob
| of compiled code at it's nucleus, if there is any neeeded also.
| Content should have a seven hundred year lifeline, readable,
| view-able in minimal software allowances. Then it cannot be said
| too often, hardware-software is in-extricable.
|
| For all those that think phishing in the public domain for the
| soul of the crowds, well, that is fine, but nothing the matter.
| And be prepared for a frustrated life-time of scratching your
| itches.
|
| Theodore Kackzinski, people who vouch for the "hundred year",
| robust hardware, for the fashion of the ages, they seem to be on
| the right side of history. That same observation de-obfuscates
| the evidenced in what is going on in AI, and statistics, mining
| data. ...when the data are repeats, high-level, junk, outright
| meaningless, no amount of AI or tweaking using computer power
| will assert anything but junk outcomes.
|
| People scale badly, that makes for the most efficient workflow to
| be a-synchronous, for nuggets of which as an individual we have
| as a rule none, and few individuals very little, that sort of
| data merits a long life-line, that data need to be tailored for
| the above allowances as you point rightfully out.
|
| You might be fake, or limited in your ambitions, but from what I
| read, I must concede you make sense before any back-ground check
| is at order.
| ehutch79 wrote:
| I'm very glad the author actually said this:
|
| ``` You don't need Wordpress, or Hugo to put a blog online, or
| Angular, React or Next.js to put a web page online. Raw HTML and
| CSS do the job.
|
| That being said, you'll need to pick up some tooling or framework
| if you want to build a web app or add more interactivity or
| customization to your web pages. ```
|
| So often people forget not everything sitting on the web has the
| same needs. saying 'you don't need a framework' ignores that,
| maybe i do infact need one, because otherwise i'd have to write
| it myself.
| jaywalk wrote:
| > Sometimes, for drafting long blog articles, I'm working in
| Google Docs, and when I'm happy, export the content to clean HTML
| using an add-on.
|
| Oh, but as he said earlier in the post, relying on a static site
| generator that you can install and run locally is unacceptable.
| That makes sense.
| nashashmi wrote:
| Great for information but no so much for application.
|
| Once you get into forms and submissions you can't do no-js
| anymore.
| krsdcbl wrote:
| Sorry to be so negative on this one but I'm kinda triggered by
| these "look its that easy" kinda blog posts that fail to adress
| the common task at hand entirely.
|
| This works for your personal blog with a super minimalistic
| design. This is completely unfeasible for client projects, or at
| least it will break your neck in the long run. And chances are
| your abysmal lighthouse score on WP had more to do with a
| bloated, mashed together WP setup than with the technology
| itself.
| greatgirl wrote:
| Sure, but all the problems come from the server side. You could
| suffer data corruption, power outage, domain name theft,
| whatever. I agree css and html is great but the author made this
| post specifically to feel superior about his theoretically
| perfect website, and i figure it's my job to inform him it's not
| theoretically perfect.
| naberhausj wrote:
| I agree wholeheartedly with this sentiment and have elected for
| the same thing on my website. The only difference is that I wrote
| a simple template based static site generator
| (https://github.com/JosephNaberhaus/naberhausj.com/tree/maste...)
| to keep my HTML sources in accordance with DRY.
|
| What I don't understand is how the linked page is downloading 1
| MB of resources which unpack to nearly 2 MB. This page shouldn't
| need more than 100 KB.
| antihero wrote:
| Ah, it's the regular: Wow, amazing, if you do not need to do very
| much, you can do it with very little! Post
| chubot wrote:
| I use Markdown and HTML, CSS, and Python (just stdlib, no
| packages) to generate static files. I think that will last just
| about the same length of time.
|
| http://www.oilshell.org/blog/
|
| Markdown is a significant win, and CommonMark made it a lot
| better.
|
| _CommonMark is a Useful, High-Quality Project_
| http://www.oilshell.org/blog/2018/02/14.html
|
| Admittedly I need a Makefile, and Make is pretty impoverished for
| this use, and I want to replace it with something else. Shell
| isn't quite good enough because I don't want to rebuild the
| entire site on every edit, and I don't want to remember which
| files to rebuild. http://www.oilshell.org/site.html
| kkoncevicius wrote:
| I use something very similar on my website, except with a few
| twists - MultiMarkdown (instead of Markdown) for HTML, Perl for
| piping MultiMarkdown produced HTMLs through some regex changes,
| and redo instead of Make for rebuilds.
|
| If you are looking for Make replacement - I cannot sing enough
| praises for redo: https://github.com/apenwarr/redo
| chubot wrote:
| I've seen redo (and talked with apenwarr about it) although I
| think my brain is still stuck on static/declared
| dependencies. That doesn't apply to every problem but it
| definitely applies to a blog.
|
| Is your build parallel? That's one of my main requirements.
| I'd be interested in seeing the redo files if they're public.
| protonimitate wrote:
| I swear this same exact post gets re-dressed and upvoted weekly.
|
| Is there anything worth discussing here? The entire thesis of the
| post is "my blog is maintenance free". Ok, and? Is blog
| maintenance really a noteworthy topic?
|
| How many times can blogs rephrase "use the right tool for the
| job"?
| kodt wrote:
| Gotta get people to read your blog somehow.
| marc_abonce wrote:
| Well, this is a motherfucking website without the swearing, so
| I guess it could be useful to people that would be offended by
| that? Although, to be fair, the intersection of people that
| would switch to raw HTML but are offended by swearing is
| nonexistent as far as I know...
| JxLS-cpgbe0 wrote:
| "My personal website with 4 pages doesn't need a CMS!"
| cxr wrote:
| This comment presents a caricatured perspective of those it
| opposes by using a made-up quote (it doesn't seem to have
| actually been said by anyone anywhere), and it doesn't really
| do anything for the discussion that wasn't already covered by
| the parent comment it's attached to.
|
| Please, folks, don't encourage people to post low-effort
| noise by upvoting comments like this.
|
| https://news.ycombinator.com/item?id=13602947
| chubot wrote:
| I agree it could have been phrased more nicely, but it
| actually pointed out something valid, which I didn't catch
| at first. The author hasn't written any posts in 5 years,
| and has ~15 total since 2010:
|
| https://blog.steren.fr/
|
| As someone who blogs regularly, I'm more interested in the
| toolchain of people who HAVE done significant writing. I
| read blogs for at least a decade before I wrote one, and
| it's harder than it seems, and coercing a good result out
| of tools isn't easy.
|
| In fact I just wrote a few of my own tools to fix the image
| problem, e.g. http://www.oilshell.org/blog/2021/01/blog-
| roadmap.html#unix-...
|
| Basically, the author's strategy is not likely to last
| (though it's not impossible). My blog started out very
| minimal, but as you write, you bump into the need for more
| automation and tools. My site looks very simple and
| minimal, but there is a surprising amount underneath.
|
| Funny comic: https://rakhim.org/honestly-undefined/19/
|
| When I was writing those tools I often wondered if we
| should just go back to Spolsky's CityDesk. It was a Windows
| GUI that would FTP HTML and images to a static server! I
| remember trying it briefly in the early 2000's. Although
| his blog also rotted due to CityDesk rotting! It's a hard
| problem.
|
| https://www.joelonsoftware.com/2016/12/09/rip-citydesk/
| cxr wrote:
| > it could have been phrased more nicely
|
| That's an understatement. It's the kind of comment that
| should be in the grey. Comments that amount to pile-ons
| and smug dismissals--like the one above--are far more
| welcome here than they used to be.
|
| > Spolsky's CityDesk. It was a Windows GUI that would FTP
| HTML and images to a static server!
|
| Among the things that Microsoft first started pushing to
| GitHub around the time that they formed the .NET
| Foundation was Live Writer. <http://openlivewriter.com>
| Dave Winer's Frontier is open source, too, but has also
| rotted. Brent Simmons, the creator of NetNewsWire, set
| out within the last couple of years to recreate it as a
| modern Mac app, but dropped the project last summer.
|
| > Although his blog also rotted due to CityDesk rotting!
| It's a hard problem.
|
| I'm convinced that we've missed the obvious and have been
| doing it all wrong, due to predilection for certain
| systems and ways of working. If you have a personal
| homepage, you should have among the stuff hosted there a
| document that describes how your site is updated. This
| document should be less of a blog post than an SOP. But
| now make sure it's specified with enough rigor that you
| can feed the same document into a machine that can
| perform those steps automatically. The reason the
| "WordPress setup from 2004" works and "old-ass
| blogger.com site" work is because they're closer to this
| ideal than Jekyll or Hugo or the others are. The caveat
| is that the hosted services make it really hard to
| actually look over the procedures that the machine will
| run, and if they let you, then you'd find that they were
| spread out over multiple "documents".
|
| Whatever the case, the thing _not_ to do is to have this
| sort of thing live out-of-band elsewhere as a tool that
| requires its own configuration and setup (with both the
| tool and the configuration being subject to rot)
| accompanied (if at all) by a terse README. (Otherwise, if
| you 're keeping that sort of thing elsewhere, then your
| homepage is not really a true digital home, is it? It's a
| Potemkin palace, and the place where those other things
| live is your real home.)
| commandlinefan wrote:
| Well, that's fine if you're running a completely static blog. I
| keep my stack as slim as possible, but I still need CGI and a DB
| to maintain a comments section. I also have just a bit of server-
| side scaffolding to ensure that there's a standard look and feel
| to the site.
| city41 wrote:
| My output is HTML and CSS, but my stack is React with Next.JS. I
| just tell Next to not emit JS at build time.
|
| This is the best of both worlds. You get an excellent dev
| experience with TypeScript, fast refresh, the world of React
| components (granted many don't work when reduced to being static
| HTML), and I can also opt back into React on a page by page basis
| if I have the need.
|
| With Next's static site generation and export, the output is just
| HTML and CSS (and optionally JavaScript), no need for a server.
|
| If anyone is curious, my personal site was done this way:
| https://mattgreer.dev
| anderspitman wrote:
| I too, enjoy Dependabot reminding me my blog exists.
| freedomben wrote:
| Beautiful site! Do you write your articles in markdown or
| something like that and render them into pages at build time?
| Is your source available by chance? I've been wanting to do
| this exact thing but while the Next.js docs are great, what
| would really help is to just see an example site that does
| exactly what I want to do. All the good examples are either too
| trivial to be useful or to complex to be useful.
| city41 wrote:
| Thanks! I am using MDX for the articles. I don't really like
| it though. MDX is fiddly and causes some headaches here and
| there. I am exploring other options.
|
| The MDX files are here: https://github.com/city41/mattgreer.d
| ev/tree/main/pages/arti...
|
| And I just now wrote a new post about how I did the static
| HTML: https://mattgreer.dev/articles/how-i-built-this-static-
| site-...
| freedomben wrote:
| Wow, thank you so much! That's a great post, very helpful
| :-)
| forgotmypw17 wrote:
| I agree 100%. Any Browser.
| tomaszs wrote:
| After fighting with React hooks, SCSS, BEM, Node.js and styled
| components it must be a relief to use pure, normal, simple and
| elegant CSS and HTML.
| taivare wrote:
| I want to build a simple blog with HTML + CSS, but I also need to
| have reader comments any suggestions?
| duxup wrote:
| I appreciate folks who do this, and they're not wrong that it
| works for them and their use cases.
|
| But all the other complexity that comes along with the web and
| web development don't exist just because of those use cases.
|
| Nothing wrong here, although the litany of "look i'm just using
| html and css" gets to be a bit much sometimes and it sort of irks
| me to see yet another and another posted on HN and up voted with
| nothing new to say about it.
| cookingoils wrote:
| A much better post on the same topic:
| http://john.ankarstrom.se/html/
| scook wrote:
| Those poor Lighthouse scores are what you get when you put no
| work into refining your site's performance. This is especially
| true for an out-of-the-box Wordpress implementation. I have a
| React project with 100s across the board, but I wouldn't
| necessarily recommend a React implementation if high performance
| is key.
|
| This doesn't even touch upon the topic of good developer
| performance, which is just as important as a set of Lighthouse
| scores. It's far easier to jump into an app with established
| build tools and documentation than it is to wade through a block
| of static HTML. Though if you're the only one working in your zen
| garden, have at it.
| stimpson_j_cat wrote:
| The site still fails Lighthouse, including the test for
| "Includes front-end JavaScript libraries with known security
| vulnerabilities." But wait, I thought it was just HTML and CSS!
| Veen wrote:
| > The site still fails Lighthouse
|
| No it doesn't. Are you sure something on your system isn't
| injecting JavaScript (browser extension?)
| mastermojo wrote:
| I am pro github pages. Used it for 5 years, no complaints. [1]
|
| However, I've chosen to also use Jekyll. Github pages explicitly
| supports/couples with Jekyll [2], so I view the combination as a
| single dependency as opposed to an extra. For deployment, I push
| to a git branch and github builds and updates my site in the
| 10-60 second time frame.
|
| [1]
| http://www.growthalytics.com/programming/2015/07/19/setting-...
|
| [2] https://docs.github.com/en/free-pro-
| team@latest/github/worki...
| ARandomerDude wrote:
| I've been using the same Middleman + Slim setup as a static site
| generator for 7 years now. Still outputs HTML+CSS for speed but
| with some nice writing features.
|
| Version everything in your Gemfile, use rbenv, and and you're
| set.
| nsilvestri wrote:
| This is almost my stack, but I added PHP for rendering Markdown
| files (via Parsedown) and use include statements for common
| components like headers. I use an Apache server on a 512mb VPS
| and deploy by ssh and a git pull.
|
| The only downside I have notice is that I can't easily put JS
| demos _within_ my rendered markdown, but I can work around it by
| stitching together multiple markdown files. Not pretty, but it
| works.
| dubcanada wrote:
| Ya well my stack is just HTML, who even needs CSS. It has
| everything yours has with the benefit is having a single file.
|
| Why just HTML you ask? Well all the reasons that they provided
| plus the fact it's only HTML files.
|
| This whole stack argument is silly, just let people use what ever
| they want to use. If someone wants to use a giant complex webpack
| setup, that's perfectly fine. Sure there is obvious downfalls and
| longer term maintenance can be a hassle, but it's what they
| enjoy.
|
| If you want to use just HTML and CSS, go for it, but why are we
| bragging?
| dceddia wrote:
| While I really like the idea of _serving_ raw HTML and CSS, I
| think that on the authoring side, a static site generator that
| ingests Markdown and generates HTML is a more practical way to
| go.
|
| I think writing raw HTML can work fine for small pages, and
| arguably it can be better than Markdown for pages with a lot of
| design elements, like landing pages. But for the typical blog
| post, or especially if the blog post has code snippets that you
| want to have syntax-highlighted, a static site generator is way
| easier to work with.
|
| With the pace of change, I do worry a bit about the longevity of
| some of today's static site generators, but the Markdown itself
| is pretty darn portable.
| stan_rogers wrote:
| With that, you can't even tell me why the text it italicized.
| Markdown mostly sucks.
| Tomte wrote:
| There are lots of different MD flavours, though.
|
| And even with Pandoc extensions you cannot really have an image
| inside <figure> with <figcaption> and alt text and title text.
| esperent wrote:
| Easy enough to do that with a static site generator like
| Hugo/Jekyll though.
| dceddia wrote:
| Yep there are definitely some differences, especially once
| you start to go off the beaten path by including HTML in the
| Markdown, or using whatever flavor of template language the
| SSG provides.
|
| I've got some older posts that use Jekyll's {% highlight %}
| directive, and I know that won't work if/when I change SSGs,
| but to me that's a small price to pay for not having to
| author those in raw HTML! :)
| TheRealPomax wrote:
| Most near-trivial to rewrite to each other's format though,
| which means you can get any static generator to ingest your
| favourite flavour with only a one-time step _possibly_ (but
| almost certainly not) required to teach it how to ingest a
| format that isn 't a perfect match for what it expects.
| chrismorgan wrote:
| A couple of years back, I helped move Fastmail's blog from
| a home-grown thing from the mid-2000s that used
| Markdown.pl, to Ghost. It was nowhere near trivial. Line
| break behaviour changed, handling of indentation changed,
| treatment of raw HTML and Markdown characters within HTML
| tags changed... I fixed everything I noticed, but there was
| a _lot_ of incompatibility, and old posts would have looked
| uniformly bad without some of the fixes we applied.
| chubot wrote:
| I just use the small reference C implementation of CommonMark
| and it works great:
|
| https://github.com/commonmark/cmark
|
| There is an example where you load it via shared library in
| Python, i.e. send a Markdown string and get back an HTML
| string.
| forgotmypw17 wrote:
| I don't like Markdown, because it too often takes what I meant
| and changes it to what I think I meant.
|
| I'm OK with ambiguity between implementations, but this one is
| a deal-breaker for me, and I've not encountered a Markdown
| implementation which doesn't do it.
|
| I think it's just a faulty idea to begin with.
| ivanhoe wrote:
| Sure, it's super easy when your page doesn't have even a header
| and/or a footer. Try having a top-menu in your design, or some
| banners/ads, and then you need to change ALL the pages to change
| a single url. This is how we used to do things long time ago, and
| it sucked BIG TIME, and that's why people invented server-side
| includes and cgi and mod_php and all of that... it saves time,
| and your time costs much more than hardware...
| asddubs wrote:
| to cover slightly more use cases, you could go for <?php
| include "header.php"; ?> like it's 2002, and then have that
| file just be plain html also. Of course if you're gonna pitch a
| solution that's impractical in most cases, you might as well go
| for the most extreme variant of that solution and not bother
| with that
| [deleted]
| 411111111111111 wrote:
| To be fair, static site generators are a thing and are very
| much underused in cooperations.
|
| He could have the same scores/performance and still get the
| full advantages you mentioned.
|
| But yes, handcrafting html is pointless at some point,
| especially if you have to update the contents every so often
| josefresco wrote:
| > To be fair, static site generators are a thing
|
| There goes your super-lean stack and we're back to square-
| one.
| 411111111111111 wrote:
| Not necessarily, because I didn't specify the tool. You can
| even use pure bash to generate it if you want.
| lazyjeff wrote:
| A static site generator requires a toolchain, being platform-
| aware, updating dependencies, etc. Sometimes I think of these
| things as labor for a new employee (if you need to onboard a
| new maintainer) on a new system (if you need to switch hosts
| or upgrade the disk/OS).
|
| It's probably about 2-4 hours for an experienced developer to
| figure out how to setup and maintain a static site generator
| assuming no unexpected problems, then get familiar with the
| syntax and structure, so hopefully the labor savings from
| using a static site generator is worth that.
| forgotmypw17 wrote:
| A static site generator requires the cat command.
|
| I don't see how you can call yourself "lazyjeff" when
| you've just written this, tbh.
| rchaud wrote:
| He mentions that SSGs require tooling and dependencies.
|
| And if all you need are dynamic headers and footers, just
| wrap those in 'php include' tags and rename the files to
| .php. It's still HTML and CSS that's getting rendered.
| indigodaddy wrote:
| I'm not a web guy--- this should be safe from php
| vulnerabilities I would think, because there is no db and
| it's just taking advantage of very limited/basic features
| of php right?
| z3t4 wrote:
| I've used both server side rendering and server side
| includes. A static site generator beats both. Just have a
| listener that will re-generate the site live when you write
| new content, then just ssh/ftp the generated content to the
| server when you are done, or if you are fancy you can use
| version control and push to a repo with a CI toolchain that
| will regenerate and ssh/ftp it for you.
| egypturnash wrote:
| "I looked at static site generators like Jekyll, Hugo, 11ty,
| but all of these require tooling installed, have a build step
| and will ultimately need some updates or be abandoned by
| their maintainer." - from the article
| specialp wrote:
| Yes and to that point you could use something like Hugo,
| generate a static HTML site. Then with that static site in
| HTML/CSS you are no worse off the solution the author
| proposes even if that generator became completely abandoned
| and unusable the next day. But in the meantime your work
| would be a LOT easier if you are doing anything at all with
| headers/menus/accessibility
| steren wrote:
| My article covers that:
|
| > So... if I don't use any templating system, how do I update
| my header, footer or nav? Well, simply by using the "Replace in
| files" feature of any good text editor. They don't need
| frequent updates anyway. The benefits of using a templating
| system is not worth the cost of introducing the tooling it
| requires.
| [deleted]
| Hitton wrote:
| >The benefits of using a templating system is not worth the
| cost of introducing the tooling it requires.
|
| Other people use static site generation, you use search and
| replace in your editor - not much of difference. Your
| approach is slower in long term, but with your on average 1
| article per year it will take some time until you reach the
| threshold.
| lhorie wrote:
| Eh, I don't think a person can ever write enough articles
| and rewrite their layout enough times that search+replace
| overhead ends up bigger than the upfront time it takes to
| read jekyll/hugo/whatever docs (plus debugging
| idiosyncrasies, etc). And even if search and replace was
| slower overall, you might be looking at a difference of
| minutes over a period of decades (i.e. it wouldn't actually
| matter in any practical sense).
|
| Far too often I see people spend days to save 2 seconds
| (and then proceed to not realize the savings over a long
| enough timespan)
| andai wrote:
| You forgot to mention the main benefits! Your website does
| not fingerprint my device, nor present me with a dark pattern
| infested "do you want us to send your data to 50 ad networks"
| popup.
| LeonenTheDK wrote:
| This is the exact thing I experienced and have been dealing
| with the past couple days. I wanted to create a small
| collection of pages as my website, intending to keep everything
| as small and simple as possible since it was (mostly) just to
| display some basic info and "posts". Well as soon as I wanted
| that menu for pages it was a whole new can of worms.
|
| Sure, I could just copy/paste/replace content as it changes.
| But I don't want to have to be doing that any time I decide I
| want to change or add something. And I'm known to be a source
| of human error.
|
| I ended up going Node+Express+EJS for the includes and certain
| more dynamic content on pages. It works well enough, page sizes
| are still small. Also considered some static site generators
| but at the time they seemed like overkill for what I wanted.
| Maybe there's a tool out there that will compile to plain old
| HTML files that I'm unaware of, I don't keep up much on front-
| end things.
| mouzogu wrote:
| HTML, CSS and SSI includes would be an easier option. If you
| don't want to deal with Node.
| robertoandred wrote:
| How do you set the state of a nav with SSI? Does it know
| what the page being built is?
| LeonenTheDK wrote:
| I was unaware of SSI, thanks for pointing it out. I'll be
| taking a look at that tonight.
| eurasiantiger wrote:
| Just create the header/footer as static SVG, embed as <object>,
| let http/2 handle the rest.
| onion2k wrote:
| Back in the old days of web development in 1999 there was a
| great app called Adobe Pagemill for making changes across
| thousands of HTML pages. It was great.
|
| These days you can do the same thing with about 5 lines of
| Python.
| Shared404 wrote:
| > it's super easy when your page doesn't have even a header
| and/or a footer.
|
| It's not that hard even with.
|
| My stack consists of HTML/CSS, and a small program to stitch
| headers and footers onto documents generated with markdown.
|
| If anyone would like to see it, it should be in the Sourcehut
| page linked in my profile. The program is a hacky (but
| functional) piece of garbage however.
|
| E: Spelling
| scooble wrote:
| I did this. Had a header template, a footer template and a
| bunch of pages. My build script was basically 'for page in
| pages cat header page footer > ouput'. Worked fine for its
| purpose (which was limited in scope).
| yagizdegirmenci wrote:
| > You don't need Wordpress, or Hugo to put a blog online
|
| It took me about 25-30 minutes to publish my website with Hugo,
| from scratch. I can't even estimate how long will it take if i
| try to build something like the current one.
|
| > Angular, React or Next.js to put a web page online. Raw HTML
| and CSS do the job.
|
| If you see someone who uses Angular for a blog, go straight to
| the DEA and report him/her.
| Evidlo wrote:
| Yes, but you probably used a provided Hugo theme.
|
| For a fair comparison, you'd use a premade pure HTML+CSS
| template or write a Hugo template from scratch.
| dmje wrote:
| This. But also, the point here IMO isn't just about performance
| but about tooling choices. There's so much tendency in the dev
| community (and has been since 1996 when I started doing web
| stuff) to jump on the latest thing without thinking about context
| or applicability. Perl then CFM then asp then Flash then js
| then...it goes on.
|
| Thing is, you don't need some jamstack hellhole of complexity if
| you're serving simple content pages. Need a common header, just
| do a find replace as he says or write a php include.
|
| It's always been the same: choosing overcomplex solutions may be
| fun and groovy - and good to learn and interesting - and this may
| be enough of a reason to do it, but it's always worth asking what
| you're trying to achieve and whether the toolset fits. So often
| that doesn't happen, and almost always the simplest solution is
| the very best one.
| davidwparker wrote:
| I use Rails. I use Svelte. I do SSR and CSR. I have dynamic
| content (not a static blog).
|
| My light house scores are ~95, 100, 100, 100.
|
| It can be done, you just have to be smart about how you do
| things.
| greggturkington wrote:
| Writing HTML and CSS by hand?! Those are just the output. OOTB
| Wordpress didn't have a perfect Lighthouse score, so it's
| worthless?
|
| > I didn't need 99% of its features anyway
|
| Oh, then it was already a terrible fit. So why are _you_ advising
| people on how to replace Wordpress?
| tannhaeuser wrote:
| > _How could you possibly consider writing HTML and CSS by
| hand? Those are just the output._
|
| You know, HTML is rooted in SGML and digital humanism. The
| entire point of it is that you use it as a _simple_ means for
| self-publishing of digital text (and HTML 5 "standards"
| portray it in that role, in case you've never had a look).
|
| Granted, that isn't quite apparent when looking at the
| trainwreck that is HTML/CSS/JS. The solution (with SGML at
| least) is that you use your own custom markup vocabulary,
| including custom Wiki syntax for markdown and other short form
| syntax, and then convert that into result markup for delivery.
| The idea being that nothing can be as lasting for your specific
| purpose than your own text format.
|
| But the self-proclaimed web heads didn't get it. They made CSS
| so absurdly powerful and "meta" to cater for the historic
| shortcomings of HTML, which is just a format for casual
| academic publishing locked in 1991. Not considering that you
| can, in fact, define your own elements and meta rules. Or at
| least, I don't have another explanation for the fact that
| everything around HTML has to change ad absurdum while HTML has
| to stay the same while it quite obviously isn't a good fit for
| the vast majority of content on the web. And that for some
| reason you absolutely have to send the same HTML to your mobile
| that you send to your desktop, and that CSS absolutely has to
| be the place to shift, re-layout and hide content for these
| different purposes.
| greggturkington wrote:
| Yes I did know that and I have had a look. Sass and CSS-in-JS
| were a godsend at their times. I give that all up so I don't
| have to type `sass watch` in the terminal once?
| m___ wrote:
| You make sense. The high-leveling and not refactoring adds to
| the service industry of jobs and con-Z-umerism. Since they
| look in the mirror showing of, the mirror answers "awsome"
| for any new flimsy blob addition. It all starts with both:
| hardware and software, both should be tuned within your
| philosophy. See my initial post on this page.
| deckard1 wrote:
| no one that lived through the SGML/XML days would describe it
| as anything close to "simple." That's why the world has
| developed countless ways to get away from it all... JSON,
| yaml, markdown, etc. etc.
|
| The world prefers ad hoc rather than formal and verified.
| Worse-is-better strikes again.
|
| Which is ironic now that we have garbage like GraphQL and
| TypeScript moving us _back_ to formalism, but built on top of
| dynamic ad hoc structures. Guys... this... this is bloody
| fucking ridiculous. It 's like trying to build a house out of
| wet tissue paper.
| ehutch79 wrote:
| For a blog page, especially something as simple as what's
| linked to, coding html and css by hand is very simple.
|
| It's a blog, not a full blown app.
| greggturkington wrote:
| Yep, if you wanted you could re-write the same HTML and CSS
| by hand for every page instead of using templates. Is this a
| revelation?
| dctoedt wrote:
| > _" When I publish a new page, I need to link to it manually
| from the index page. I'm OK with that. It's done in one line. It
| also allows me to have more control over when I want the page to
| be "published"."_
|
| I've sometimes wondered whether pg's essays are done with just
| HTML and CSS -- it kinda looks that way, [0] but I'm not expert
| enough to be able to tell.
|
| [0] http://www.paulgraham.com/articles.html
| apolymath wrote:
| I built a CMS that focuses on HTML + CSS code writing and uses
| mustache to enable multilingual content. Check it:
| https://saber.datasilk.io
| notjustanymike wrote:
| Yeah and I walk to the grocery store on good old fashioned feet,
| but you can bet your ass I'll use an airplane if I need to get to
| California.
| nicbou wrote:
| Well yes, but your website has a dozen pages, wasn't updated in 6
| years, and is as interactive as a sheet of paper. Do consider
| that some people tackle slightly harder problems.
| [deleted]
| wishinghand wrote:
| I've found for little blog sites like what the author talks
| about, templating is still really handy. https://sergey.cool is a
| very slim one that supports Markdown. There's no way I'm going to
| type up all a blog post and add in `<p>` tags as I go.
| newsbinator wrote:
| After having written Pug and component-scoped CSS the last few
| years, it's surprisingly hard for me to go back to raw HTML and
| raw CSS.
| [deleted]
| anderspitman wrote:
| I've found a nice middleground to be writing a custom static site
| generator for each site. They can be quite small (here's one[0]
| in ~50 lines). Usually it just loops through a directory and
| turns Markdown files into HTML (with header injected), and syntax
| highlighting.
|
| Also, if you're really committed, you might be surprised how app-
| like you can make HTML+CSS, using things like checkbox and
| :target hacks[1]. The UI demoed in the video on this site[2] has
| no JS. These techniques pretty much require a generator, and
| there are obviously tradeoffs.
|
| [0]:
| https://github.com/boringproxy/boringproxy.io/blob/master/ss...
|
| [1]: https://www.mattzeunert.com/2017/10/30/javascript-free-
| todo-...
|
| [2]: https://boringproxy.io/
___________________________________________________________________
(page generated 2021-01-07 23:01 UTC)