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

Next Gen Static Blogging

inoads.com

Post reply on HN
Print view View original

141–150 of 179 posts

Re: Next Gen Static Blogging

#141

Post by jl6 »

lessthanseventy wrote: post #136
jl6 wrote: post #126

Earlier quoted context omitted.

IMHO blogs are documents, and HTML is no longer designed for documents but web applications. Blogs need to go back to document publishing formats. It doesn't get more user-friendly than 1. WYSIWYG word processor; 2. Save As PDF; 3. Dump the file on a web host. I'm switching to PDF/A: https://lab6.com/0#page=2

As a visually impaired person please don't. I like being able to resize text and still have the document flow properly instead of endlessly scrolling back and forth.

It's a Tagged PDF so supports reflow or extraction into HTML or text formats.

Re: Next Gen Static Blogging

#143

Post by still_grokking »

anjbe wrote: post #134
still_grokking wrote: post #122

Earlier quoted context omitted.

Please never ever break XML compatibility! Not having valid XML in the first place complicates any further processing quite a lot. Also you're going to run into annoying and / or strange issues with tooling. Those HTML shortcuts are just not worth it. Their value is "questionable" (to put it kindly) but down the road their cost can become surprisingly high.

Implicit and optional tags have been part of HTML for decades. A valid HTML page that uses them is completely unambiguous. Nothing prevents it from being parsed and converted to an XML‐compatible document on the fly by tools. Writing HTML in an XML‐like fashion has its own quirks since HTML is not parsed the same way. Can you add elements within an , or self‐close a ?

Automatic conversion to XML is not always possible cleanly as those documents tend to not follow all rules (which can happen for example by template nesting). At that point you have a headache.

The point of being XML compatible is not about the browser environment. It's about tools and processes that work with XML (and assume therefore valid XML) and use your HTML as input. That's still a quite common thing. Even you don't do it today you can't know whether you or someone else is going to need it tomorrow.

Being XML compatible also opens up the possibility to use powerful tools like transformations and queries right on the raw HTML data in ad-hoc scenarios.

Sure, that's nothing you would do on an private blog usually, but in more enterprisey settings all kinds of processing happens on all kinds of data, quite often including web page contents. My experience after working in such environments is that not keeping HTML XML compatible will cause some serous trouble eventually.

Re: Next Gen Static Blogging

#144

Post by BlueTemplar »

jl6 wrote: post #126
onion2k wrote: post #117

I think it's a bit of a shame that this discussion has focused on the tech and (slightly odd) HTML choices here. Those are probably the least interesting parts of any discussion around what a "next gen" blog platform might look like. Where the author is correct about next-gen blogging (in my opinion anyway) is in the attempt to reduce the friction to publishing a new post. What tech stack you use, whether it's static…

IMHO blogs are documents, and HTML is no longer designed for documents but web applications. Blogs need to go back to document publishing formats. It doesn't get more user-friendly than 1. WYSIWYG word processor; 2. Save As PDF; 3. Dump the file on a web host. I'm switching to PDF/A: https://lab6.com/0#page=2

No, Pdf isn't appropriate for electronic documents, it is especially user-unfriendly.

What exactly do you have against HTML? (It's not like we have any better alternative...)

IMHO the .mhtml format should be resurrected.

EDIT: And the Pdf format can be abused as well. At least it's easy to block JavaScript on HTML, even selectively (uMatrix).

I expect to be able to use video in an electronic document, PDF readers don't seem to be even able to support MP4, much less the upcoming AV1 !

Re: Next Gen Static Blogging

#146

Post by toast0 »

majormjr wrote: post #63
cwackerfuss wrote: post #56

Earlier quoted context omitted.

Frontend developer here -- Although you could omit the closing tags, I don't see the benefit of doing so. If you know HTML, nesting is fundamental and not explicitly closing dom nodes would lead to confusion. You would also need to concern yourself with the "certain conditions" that must be met for it to work. Consistency and clarity over brevity!

Especially with HTML as it's going to get minimized and hacked up to reduce the filesize. Including the closing tags makes the transpilers job easier and less error prone.

The minimizer should output HTML without unneccesary tags, and it should probably expect to run on its own output, so I don't see why adding unneccesary tags would help it work.

Re: Next Gen Static Blogging

#147

Post by FalconSensei »

rayrag wrote: post #119
onion2k wrote: post #117

I think it's a bit of a shame that this discussion has focused on the tech and (slightly odd) HTML choices here. Those are probably the least interesting parts of any discussion around what a "next gen" blog platform might look like. Where the author is correct about next-gen blogging (in my opinion anyway) is in the attempt to reduce the friction to publishing a new post. What tech stack you use, whether it's static…

Author created static website where he manually links to each page and he claims this is 'next-gen' of blogging. You know what's next gen of blogging? Substack. You know why? It's because for most people rss is "hard" to use (mostly because they aren't familiar with it, thanks Google!), meanwhile everyone is familiar with email clients. Author says: > Managing this blog is a little more involved than dynamically gene…

Agree with you. So... managing it is more involved than dynamically generating everything, and it doesn't have rss?

I mean... I expect that putting more work into it would be a tradeoff for more features, not less

Re: Next Gen Static Blogging

#148

Post by FalconSensei »

Priem19 wrote: post #106

I applaud that simplicity seems to be trending, but the benefits of not having paragraph tags don't seem to outweigh the downsides. It's not that big of a deal, and it enables reader mode. Leaving as much as possible left to default is what I prefer; it supports the greatest number of browsers and assume is the fastest. https://www.quitfacebook.org/file/play.html

yeah, for me, breaking reader mode is a big downside.

Re: Next Gen Static Blogging

#149

Post by FalconSensei »

clintonb wrote: post #116
unicornporn wrote: post #80

Earlier quoted context omitted.

> Once you choose the technology that runs your blog, use it. Don’t replace it, ever. Never ever rewrite it.[1] [1] https://macwright.com/2019/02/06/how-to-blog.html

The antithesis of this is exactly why I asked the question. I was reminded of a tweet/post describing that most blogs have a single post: the one that describes how the author built their own static site generator/blog framework. After that, they are too tired/unmotivated to write anything else. I was on WordPress. Now I’m on Jekyll. I occasionally think of changing the theme, then I remember how little that will ben…

THIS!

I'm on Hugo now, and have used both self-hosted and .com (free) versions of Wordpress. Which of the 3 do you think I wrote the most when I was in it?

Yeah, free wordpress is limited, if not open-source, blah-blah-blah. But it's a few clicks to create, easy to write the posts/have drafts/change theme. And I would argue that having limited themes on free can actually be a positive thing. You have a few options, chose something and start writing.

Having to write in any other editor (to have grammar checking), then paste on VS Code, deploy... it just takes more time. And this is without managing any media, which I just upload to imgur and use the link...

Re: Next Gen Static Blogging

#150

Post by scrollaway »

jl6 wrote: post #141
lessthanseventy wrote: post #136

Earlier quoted context omitted.

As a visually impaired person please don't. I like being able to resize text and still have the document flow properly instead of endlessly scrolling back and forth.

It's a Tagged PDF so supports reflow or extraction into HTML or text formats.

I'm a big fan of pdf/a but it doesn't support reflow, not in any sense that users would want or mean. Reading your post on a phone is awful.
Post reply on HN