Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The theory versus the practice of “static websites”

utcc.utoronto.ca

Post reply on HN
Print view View original

211–220 of 221 posts

Re: The theory versus the practice of “static websites”

#211

Post by eviks »

nicbou wrote: post #204
eviks wrote: post #186

Earlier quoted context omitted.

> and this was never an issue weird that broken search basics are not an issue, you extol the virtues of site search in your blog, that engine is capable of matching "shcfua" to "Schufa". Markdown, on the other hand, fails in search long before getting to fuzziness > § character, which I use a lot. It would take five seconds to fix it across the website True, and then forever to hunt down those few instances where §…

Search can be anything you want. It's just text. You are free to use the tools that work for you. I see the diff in Sublime Merge before committing, so I'm far less likely to break something. I used to make so many errors because the WYSIWYG editor caught a random keypress. Personally, I want those indicators to be there. I'm editing the text and the formatting. I want both to be on the screen. Frankly I don't need t…

But it's not "just text", that's the whole point of "markup", and that's also the reason why the diffs would fail outside of simplistic changes. To search properly you'd need to strip that markup, so it can't be anything I want, which text editors offer that???

Also, formatting is there on the screen - in the form of formatting!

Re: The theory versus the practice of “static websites”

#212

Post by nicbou »

eviks wrote: post #211
nicbou wrote: post #204

Earlier quoted context omitted.

Search can be anything you want. It's just text. You are free to use the tools that work for you. I see the diff in Sublime Merge before committing, so I'm far less likely to break something. I used to make so many errors because the WYSIWYG editor caught a random keypress. Personally, I want those indicators to be there. I'm editing the text and the formatting. I want both to be on the screen. Frankly I don't need t…

But it's not "just text", that's the whole point of "markup", and that's also the reason why the diffs would fail outside of simplistic changes. To search properly you'd need to strip that markup, so it can't be anything I want, which text editors offer that??? Also, formatting is there on the screen - in the form of formatting!

The markup is part of the text. Making text bold is a change to the text. It's part of the diff. The text without the markup has no value. I'm not sure I understand what you're getting at.

Re: The theory versus the practice of “static websites”

#213

Post by eviks »

nicbou wrote: post #212
eviks wrote: post #211

Earlier quoted context omitted.

But it's not "just text", that's the whole point of "markup", and that's also the reason why the diffs would fail outside of simplistic changes. To search properly you'd need to strip that markup, so it can't be anything I want, which text editors offer that??? Also, formatting is there on the screen - in the form of formatting!

The markup is part of the text. Making text bold is a change to the text. It's part of the diff. The text without the markup has no value. I'm not sure I understand what you're getting at.

> The markup is part of the text

So do you change text font size in CSS separate from the content or within markdown since it's part of text and has no value when separated?

> It's part of the diff

it doesn't have to be part of the same diff. In your current workflow you can't separate it by design

> I'm not sure I understand what you're getting at.

It's pretty simple - content diffs are very valuable, markdown pollutes it

Re: The theory versus the practice of “static websites”

#214

Post by eviks »

nicbou wrote: post #205
eviks wrote: post #134

Earlier quoted context omitted.

I meant searching for a "bold in a phrase" phrase when it can have various markup in arbitrary places (also, it's not just __, you might have some other valid marker) But anyway, you can't really use regex here as it's too complicated and error prone for such a frequently needed operation, you need a better mechanism line index or a built in functionality to ignore all markup

So look for **? This has been working well for me.

look where? it can be any other marker, and it can be nested, and it can be in any position, you can't craft a regex on the fly to capture that, your regex will be longer than the phrase.

Re: The theory versus the practice of “static websites”

#215

Post by Daril »

nicbou wrote: post #177
Daril wrote: post #19

Earlier quoted context omitted.

This is very interesting. Impressive how much efficiency and performance is gained. This also means that fewer resources (electricity) are consumed, that less bulky hardware is used and, most importantly, that security is improved. A static website is more difficult to attack and the only possible flaw is in the web server and not in the code of the website. I usually use Hugo. It is very complete and rich in feature…

I have a robot vacuum cleaner that runs linux, and it CAN run a Caddy server. I managed to get a website running on it last time. Now that my websites are static I'm tempted to host my personal blog on it. I try to keep things simple. Simple websites are fast and reliable. Turbo seems to be a departure from that. Since the heaviest part of my pages is the text, it would not help much.

In its simplest and most basic form, Turbo does it all for you. All you have to do is add the javascript files and when the user visits a page, Turbo will intercept the request, pass it to the server, retrieve the HTML response, extract the content of the body tag and surgically insert the content into the client browser. I'm using it on a couple of sites (including mine, a static one built with Hugo) and web applications and the difference in speed and responsiveness is remarkable. Of course you can go further. I'm now building a PWA using CodeIgniter and Turbo. The big advantage of this approach is that you can use "classic" technologies (HTML5 + backend) and achieve similar responsiveness to the modern Javascript frameworks, reusing all the existing backend code and logic.

Re: The theory versus the practice of “static websites”

#216

Post by matfrana »

chrisldgk wrote: post #191
pembrook wrote: post #73

Earlier quoted context omitted.

> Static makes so much sense for sole-author sites with technical owners. Totally agree for this narrow use case. But you're also correct that if you're a startup with a marketing site--going the Gatsby/Hugo/etc. route is a total disaster. Have seen so many technical founders make this mistake. What happens is you realize, crap, my team needs to publish content for SEO and build new landing pages...and they aren't ab…

Webflow has some huge constraints when you’re trying to actually build a good marketing page. Try framer instead, the fact that you can rely on React for anything that’s not possible to do in the visual editor is a life saver and actually enables you to build sites that are on-par with traditional headless CMS plus meta framework stacks while still being just as easy (if not easier) to maintain by non-technical users…

Or you can have a look at React Bricks, too. Devs create content blocks as React components with inline visual editing and sidebar props, with constraints so that the design system cannot be broken. Content editors can use these Lego bricks of content with freedom, without breaking the design.

Re: The theory versus the practice of “static websites”

#217

Post by d13 »

modernerd wrote: post #22
nicbou wrote: post #3

I run a content website for a living. This year I switched from Craft CMS to my own static site generator. I no longer think about the server or the CMS. I no longer need to keep it updated. I got rid of the heavy database and the elaborate caching setup. Now it's just a static file server. If it was just the blog it would be even easier to host. The website is more reliable and requires virtually no maintenance. The…

Static makes so much sense for sole-author sites with technical owners. Would be great to make the tech more accessible to those without the skills to recompile and deploy. It's such a fast and affordable way to build websites, but existing tools like Hugo assume a lot from users that can put the tooling out of reach. (Enjoyed your write-up too. I wrote the original version of html-to-markdown that you used in your m…

Adobe actually had a product like that about 20 years ago that the agency I worked with then used with their clients. Clients could just directly edit their content in a wysiwyg format, hit a publish button and it would upload. Can’t remember what it was called!

Re: The theory versus the practice of “static websites”

#218

Post by modernerd »

d13 wrote: post #217
modernerd wrote: post #22

Earlier quoted context omitted.

Static makes so much sense for sole-author sites with technical owners. Would be great to make the tech more accessible to those without the skills to recompile and deploy. It's such a fast and affordable way to build websites, but existing tools like Hugo assume a lot from users that can put the tooling out of reach. (Enjoyed your write-up too. I wrote the original version of html-to-markdown that you used in your m…

Adobe actually had a product like that about 20 years ago that the agency I worked with then used with their clients. Clients could just directly edit their content in a wysiwyg format, hit a publish button and it would upload. Can’t remember what it was called!

Perhaps it was Contribute? https://en.wikipedia.org/wiki/Adobe_Contribute

Re: The theory versus the practice of “static websites”

#219

Post by mdrzn »

muhammadusman wrote: post #133

Recently, while talking to a friend who hosts her website on Wix, I noticed that she was using it as a portfolio website and I asked what wix-specific features she was using and her answer was "domain management" and this got me thinking...what if the steps were pretty straight-forward, could someone who is not a web dev or technical get a website up on github? So I started putting together a template that looks very…

"Prerequisites

-Github account

-Familiarity with markdown (learn more here)

-Ability to run node.js and npm on your computer

-Optional: a domain name."

Definitely not the same as using Wix, and definitely not usable for non-technical people.

Re: The theory versus the practice of “static websites”

#220

Post by IIsi50MHz »

sixdimensional wrote: post #125
simonw wrote: post #97

I've been exploring an architectural pattern for a few years now which I think gives you the best of both worlds: it lets you run dynamic server-side code, but in a way that's both extremely inexpensive to scale up and that is self-healing if anything breaks. I call it the Baked Data pattern: https://simonwillison.net/2021/Jul/28/baked-data/ The key idea is that you deploy a full read-only copy of your site's data as…

Tangentially, I've been exploring something kind of fascinating... So, in compiled binary executables it was not uncommon to include encoded binary resources, like files or images. Not tons of them, because they would explode the size of the executable. For example, for C or C++ https://github.com/graphitemaster/incbin So here's the interesting part - we decided to build executables in a way that data in those execut…

> That said, think about what a container (e.g. docker) is. A running container is kind of like a packaged executable, except it also has a filesystem.

> So if you pack data (which can be modified and runtime!) into a container, it's a similar concept to an embedded resource in an executable, except it can change.

> Now, in a container, any changes made to data at runtime inside the container won't persist unless the container is given persistent storage.

> What I've been wondering lately is why we didn't invent some kind of single "executable plus volatile data space embedded within the executable", so that programs and data (say, a database) could couple together into a single file.

Things like this have existed before, and I presume still exist. For instance, before MacOS X, applications for Macintosh for (vaguely) similar to "application bundles. Leaving aside the technical differences of implementation, classic Macintosh applications had a "resource" store that included code and 'static' data (pictures, text, whatever) but could be modified by running program. Changes could be persisted without using any other files. In practice, changes were often persisted elsewhere, be cause if a fault occurred during modification, the executable could be corrupted, and because this made things like resetting to defaults easier (by deleting or moving an external preferences file, for example).

Post reply on HN