http://montaigne.io - made this one for myself. Just publishes website from Apple Notes. Every time time I update note on my laptop or iPhone the site is updated automatically.
had the same problem with previous platforms so made this new tool. I think I've road 6 posts in the past month. So hopefully it will help me to write more too.
thank you! I tried many setups over the years and then realized that I have 4000 notes in my Apple Notes anyway. And I have my drafts there and it works across devices.
I need to write a blog post explaining this in more detail.
But basically Notes are shared with public account, then they synced automatically to the apple mini machines in the cloud. Using Apple Script they are exported and saved into DB and then render and published.
Well, there is a fair amount of css wrapped in <style> tags. Not sure I understand the upside of not putting it in a separate file.
Though the look is reasonably pleasant.
Edit: The example blog also loads js, despite the "no javascript" claim. Like: <script src="https://cdn.usefathom.com/script.js" data-site="WKWMFTPV" defer></script>. Perhaps that's not a default thing, but it seems odd to link to an example blog that doesn't match the sales pitch.
Creator here. So it may be a bit pedantic, but yes, there are styles (pure HTML isn't the most pleasant to read) but no external stylesheets.
I ran a bunch of tests when setting it up to see what loads faster and it turns out the <style> tag in the head, with such minimal styles outperformed external stylesheets (even though the browser can cache them). With styles so small once the html page is loaded (at 2-5kb gzipped) the styles are immediate, whereas even if retrieving from browser cache the html needs to load first before it can take effect.
The second bit with Fathom analytics is that users can optionally connect Fathom to their accounts (this is the only analytics tool you can connect since they have a track record of being trustworthy). But yes, it is technically included JS.
Inline CSS has the benefit of not making a second HTTP request, as well as (if I recall correctly) rendering the page styled from the get go, as opposed to once unstyled and once again when the CSS has finished downloading.
One might argue, that inline CSS cannot be cached by browser and are loaded with each HTTP document, thus increasing total download size. And using HTTP/2 making additional requests ain't such a big problem anymore.
All in all I think developers have considered all options and chose the best solution for their particular use case.
If the stylesheet is less than a few kilobytes, it will generally be faster to inline it even for subsequent page views with an immutable cache header. Caches and separation into external files still aren’t free.
One other thing that is almost always overlooked is that you don’t tend to use all styles on a given page, and you could strip out the unused styles. For example, the front page linked here has over 4KB of stylesheet, unminified and with unused styles; minified, it’s 3KB; with unused styles removed (including the wonky body:hover), it’s about 662 bytes. Something in the vicinity of 1KB is for specific pages, and 1KB for editing (form fields and such). If you try actively minimising the front page (removing unnecessary whitespace and attribute quotation marks, minifying and paring the stylesheet, and removing a few pointless elements), the whole thing ends up under 3.4KiB (down from 7.8KiB).
(Mind you, most browsers can do some degree of intra-session sharing of an in-memory representation of a stylesheet, for performance and memory usage reasons, and doing this will thwart that. But that’s only likely to make things faster over inlining if you’ve got much heavier styles, dozens or hundreds of kilobytes, the sort that you wouldn’t be so likely to inline anyway.)
As for the “making additional requests thing”: you still have to remember latency, because you’re adding another whole round trip to the waterfall. In the case of bearblog.dev which is hosted somewhere on the other side of the world from me (I’m in Australia), that will add an absolute minimum of over 260ms, more commonly half a second or more. Inlining of small resources like this when you have a very short waterfall already significantly improves load performance. The HTTP/2 and HTTP/3 improvements are about requesting more than just a couple of resources: in a case like this if you had one HTML and one CSS resource from the same host, HTTP/2 would not improve anything over HTTP/1.1.
> One might argue, that inline CSS cannot be cached by browser and are loaded with each HTTP document, thus increasing total download size. And using HTTP/2 making additional requests ain't such a big problem anymore.
I’ve spent a lot of time obsessing over this—and being perplexed by performance-focused web devs favoring inline styles generally. Here’s what I’ve found.
- External <link> stylesheets are exactly as you describe, with some important caveats depending on specifics of the actual page, site, host, resources, and other bundle characteristics.
- Perceived performance is almost universally better, for all network conditions I’ve tested, when at least a portion of a page’s styles are inlined in <head>. Yes, even with HTTP/2. Yes, even with optimal metadata hints which should degrade better on a slower network. The most reasonable conclusion I can come to is that the main document parser is so well optimized that beating it is like challenging the Harlem Globetrotters on “fundamentals”: you’re going to be right, some of the time; you’re going to lose, every time.
- The benefits of inline styles degrade pretty quickly for subsequent navigations, with appropriate cache headers. This is expected, but with perf (web or otherwise) validating assumptions isn’t something you should leave unspoken.
- Many hosts have bad cache headers, even those you’d expect to do better (glares at GitHub Pages, my host).
- While the benefits of inline styles degrade rapidly, the drawbacks rarely if ever accelerate enough to care except under the worst network circumstances. And the drawbacks of <link> stylesheets accelerate much more rapidly.
- Most of these facts are mostly unnoticeable, on most mainstream devices, for most of this audience. You have to measure to register a difference, and the measuring has a greater impact than any measurable implementation difference.
- The notable exception, one which users will notice regardless of their device capabilities or network conditions, is web fonts. If you load them, the best perceived performance strategy is to mark them optional. Even so, they have the greatest impact on perceived performance, on otherwise well optimized pages, on high perf devices with good network conditions.
- When loading fonts on a page, inline styles perform dramatically better than <link> stylesheets regardless of any other implementation detail or circumstance. They have better perceived performance if baseline styles like colors and basic typography are inlined as well. This is what is commonly glossed over (and sometimes overloaded to mean more) as “critical styles”.
- From this point on, <link> styles perform “the same or better” for a basically useless unit of “better”. Assuming a relatively flat request waterfall. HTTP/2 helps if you know your entire dependency graph upfront, which nearly no site does… and it doesn’t matter, because Push is dead or on its way out and that graph is meaningless if the client disregards it.
- Good luck knowing your dependency graph. The tools that are designed for it are concerned with JS bundles. Your best bet is the added build-time complexity of CSS-in-JS and dynamic atomic classes (which are both great, albeit an unpopular combination). If you don’t, you’re either serving redundant styles, too many (my personal preference, after critical styles), or you’ve rolled your own static analysis tool (please share!).
True, but they can’t cache a portion of the page that happens to be shared across every page on the website. If I go to a dozen different pages on the site, any in-http-page styles will be loaded a dozen times, while a separate style sheet will only be loaded once.
Visiting 1 article then bouncing is the most common pattern for blogs by a long way.
Also the amount of time taken to download a CSS file is usually much less than the round trip time for requesting the file. Especially in the p90/p99 end of the latency distribution. Here in Australia, I can download a 10kb css file in less than 1ms. But simply requesting that CSS file from America will take 200ms.
For a blog, inlining the css is absolutely the way to go. Especially if the css is small (which it should be!).
Perhaps, though I thought the net benefit of newer http protocols was to make that second request very lightweight. Then it's also cached if they visit a second page on the blog.
true, but for a blog, the html would be cached per page, which means that if you look at n pages the same css is loaded n times too.
depending on _how_ you cache it, there might be a cache invalidation round trip for your css (Q: has this changed? A: no), which might or might not transfer more data than your embedded css anyway.
CSS is render blocking. The browser will never paint anything on screen until it’s downloaded and parsed in to a css object model.
Unless you’re hyper tuning the page load performance in some specific way I think CSS is usually best served as a separate asset with a very generous cache time.
If the entirety of the CSS is extremely minimal it can make sense to in-line it too. Especially if you can get everything in at under 14kb. (Initial TCP window size)
The fact that this needed to be said is concerning.
There's no FOUC if you add a stylesheet to <head>, and it concerns me that people seeing that flash have come to expect it as a fault of CSS, when it's really these frameworks making a decision to load the stylesheet via javascript.
I completely agree. I'm promoting a concept called TACE to get back to the principles of the web that were being promoted between 2000-2010. I've realized that a lot of web developers these days don't understand the basic principles of HTML, CSS, and JS because they initially learned web development using a Javascript framework.
I feel like this is an overblown reaction to a single person getting something wrong in the internet? It's not really concerning that not everyone knows everything with a 100% degree of certainty.
> Edit: The example blog also loads js, despite the "no javascript" claim. Like: <script src="https://cdn.usefathom.com/script.js" data-site="WKWMFTPV" defer></script>. Perhaps that's not a default thing, but it seems odd to link to an example blog that doesn't match the sales pitch.
Probably safe to turn off, as uBlock Origins and other ad blocking solutions would, depending on your settings. So I guess in a way the site itself works just fine without JS enabled and doesn't require it, but the authors have chosen to add analytics to see who uses their site, then.
Bear Blog users can optionally add Fathom as an analytics tool. It's a fair criticism that this adds JS, but Fathom is arguably the best choice for analytics (maybe Plausible as well).
I use bearblog for my .dev website [1]. It's a one pager and works great for me.
I inject some CSS to make it work for me, i.e. fonts - and simple colors and I removed most of the "extra" pages because I wanted to keep it as a one pager.
It's a great platform and I wish there was a version where I could self host it like `hexo.js`
Thanks for your work herman!
[1] orlie.dev - Currently using it behind Cloudflare!
How is Google treating your website? I run a couple of pure/majority text only websites & I've noticed that Google favors websites with images/videos in them even if they copy your text content.
Not as snappy as I would have expected considering the 5KB pages. Not sure where it comes from but there is a very noticeable delay before the individual blog pages are rendered.
- "No trackers, no javascript, no stylesheets"
- inline js.
- inline stylesheets.
- uses favicon which can be used for tracking.
- not self hosted.
- requires an account to sign up
- "TOS" > "Bear may disclose personally identifiable information under special circumstances, such as to comply with subpoenas or when your actions violate the Terms of Service."
- can't be bothered to indent the html.
- payment system could require real identity.
I suspect what he means is "this is a safe space" in contrast to the open/hostile internet "out there", i.e. there is no nefarious intent. As you point out, this is really mostly virtue signalling (and probably well-meant). The fact that actually there is JS, there are trackable signals, your PII can and will be disclosed etc is sorta beside the point of sites like this.
If an organization or person is selling a product focused on privacy and there is a TOS that focuses on the org or person avoiding liability but lacks documentation or links to resources to help users to lower their liability and increase privacy, its a red flag to me.
Their servers are located in the Netherlands. Its good that they list that. It would be better to hoist information into something that is less policy/legal oriented and perhaps provide an overview of the laws of that region.
Other things that should be listed is how is the data stored, transferred, how is it protected, are there any steps to anonymize the data, hash the data, or provide a way to bring your on key for data encryption.
Is there any telemetry gathered or stored by the server? Is the code in the github project the same that is deployed in production or is there a private repo that augments the code?
Fyi, HN uses a limited version of markdown which doesn’t recognize standard markdown list syntax. If you want to make a bullet list, you have to put blank lines between each bullet point, like this:
——
- "No trackers, no javascript, no stylesheets"
- inline js.
- inline stylesheets.
- uses favicon which can be used for tracking.
- not self hosted.
- requires an account to sign up
- "TOS" > "Bear may disclose personally identifiable information under special circumstances, such as to comply with subpoenas or when your actions violate the Terms of Service."
Please don’t say HN uses any form of Markdown. It’s its own thing entirely with absolutely no foundation in Markdown—the only points of any similarity between Markdown and HN comment formatting predate both by multiple decades. HN’s formatting gives you paragraph breaks (by blank lines), linkification (with no delimiter, unlike stock Markdown which requires angle brackets, to the surprise of many), monospaced blocks (by two space indentation), italics (with asterisk delimiter), backslash escaping for asterisks, and that’s all. Every element of this, or a very slight variant, has been common in lightweight markdown languages since before Markdown, and all but the backslash escaping and hyperlinks (which hadn’t been invented yet!) have been in conventional use in communication since well before the web (and match some typewriter conventions from before the invention of computers).
Markdown is not the only game in town. Yes, for now it’s the dominant lightweight markup language (more’s the pity—it’s a right mess, thoroughly unsound and inconsistent in a great many ways), but a lot of stuff exists beyond its horizons; it’s only an instance of LMLs, not the whole class.
It uses styling in a style tag and doesn't make a second call to an external stylesheet. So it has styling (although very little of it), not stylesheets.
I think this is being pedantic. There are styles in a <style> tag (cause it turns out pure HTML doesn't read so well). It doesn't have external stylesheets, however.
I like the idea, but to echo another comment, the hardest part of running a blog is not selecting the blogging engine or how to host it. The hardest part is keeping new posts flowing through the engine.
What blogging platforms focus on this side of things? Which ones help solve the "What do I write next?" problem?
If you have nothing to write about, you should not write; Not write about nothing.
You should write about nothing though, it's a good writing exercise. Just maybe don't publish it? Publish what you write after that, when you know what to write about.
The hard part of forever isn't picking the right technology, it's keeping the content available online.
You can't self-host this. So unless your bank account is designed to pay for the URL, hosting, and keeping the project up to date forever, you're just lying to lock people into your platform.
Besides being exceedingly, aggressively negative and paranoid, this also doesn’t make sense at all. Why would they build this niche thing, make it explicitly privacy-focused, and target it to an audience who surely will notice any abuse?
The simplicity of this is awesome. I've vaguely wanted to start blogging for many years, but suffered from analysis paralysis on where/how to get started. This was so simple -- took me less than 2 minutes to get set up and start writing. Thanks for making this!
Big fan of Bear Blog. I'm just starting my own, and decided to modify some of the default Bear styles/web components by using Cloudflare Workers: https://blog.willswire.com
This looks really cool. No reason to switch from my self-hosted Hugo setup, but if I was just starting out with blogging I'd be happy to have this available vs the bloated Wordpress site I started out with in the beginning.
Why not host it for free through Github Pages? They only host static sites so it's technically quite different to your blog... but if you are only going to be blogging it may as well be a static site IMO.
Edit: I do like how neat it sounds to just query a user's public Gists though.
I've actually been thinking about different ways of adding exactly that to a static site - technically you could have something like a comments form that just writes to a text file somewhere (perhaps updating a Gist with the API you mentioned[1]), which the static site reads from upon page reload.
Sounds a bit inelegant I guess, but could be interesting to implement.
I went down this rabbithole. Comment systems suck and you will get an amazing amount of spam.
I keep a Contact page with various ways to reach me if you really want to chat about something. It's rare when folks chat me up but it's always a good convo when it happens.
Creator of Bear here. It was actually a design decision to not add comments as commenting on blogs is generally useless (the comments happen on the places where you post your content like HN, or social media). It is also very easy to be exploited by spammers so requires constant attention.
Creator here. You can technically self-host it, you'd just be self-hosting a blogging platform instead of a blog. There are options to self-host other tools with the same theme as other commenters have stated.
Also, "privacy-first" and "self-hosted" are not mutually exclusive concepts. By your logic all software you don't host yourself isn't privacy respecting, which is a fair belief on your part, but opinionated at best.
So what you’re saying is that you are offering a blogging service that happens to have an open source platform behind it that one could self-host if desired.
Even if the software development cost and labour were free, we still need to figure out revenue generation for hardware and network in order for it to last forever.
I expected custom domain to be paid feature, but that doesn't seems to be the case here.
So do we have a business model for it to last forever, or even if it is something like 50 years.
It looks to be using Cloudflare, Cloudflare Pages free tier is very good, I suspect its using it with workers, and maybe getting very small bills or its under the free limit.
Hugo in combination with the Congo Theme (see https://github.com/jpanther/congo) has scratched this itch for me. The theme is well thought out and has all the features I need.
There's the usual youtube and vimeo integration, but also
All of that's great... but wouldn't it be much better to render the latex, mermaid etc server side? I'm a bit baffled that apparently Hugo can't do that.
Client-side rendering works well enough for me, and has been for years (as a visitor). I don't see a benefit to integrate a custom Hugo patch to get server-side rendering for my simple personal blog.
Does Hugo have a cloud backend integration that you can create new post/edit existing post without redeploying everything?
There's an open source, self-hosted clone of BearBlog, called PolarBearBlog [0], that builds a docker image and run it on Google Cloud Run. It uses Google Cloud Storage to manage a single JSON file for the whole blog contents (yes all your blog posts are in a single json file, which probably will start to show issues when you have hundreds of posts, but then again it's just markdown text so maybe that won't be a big issue anyways), and you only need to redeploy it if you made code change or system level config changes, which really is really more convenient than the whole static approach.
I made a fork of PolarBearBlog to add some of the features I care about, like cactus comment integration and rending full posts in the RSS feed. [1]
Creator of Bear Blog here. Both Jan and Joseph (mentioned in the README) contacted me prior to publishing to get my permission to use the Bear theme and chat through the project :)
to name a few. The hugo site has a couple of howtos.
Some hosting solutions require that the entire website is stored in a separate branch, others regenerate the HTML through a CI pipeline and store it in an object store.
After years of analysis paralysis of choosing the right stack for my blog, I picked up Hugo, the Cactus theme[0], stripped lot of useless (for me) stuff, made some changes, published a new theme[1].
Thanks a lot for posting it! I wanted to blog for quite a while but am too lazy to finish some basic blog setup with my "own theme". Bear looked great and I was upset none of the Hugo themes I looked at were exactly what I wanted. This one does!
For a terminal based workflow, https://prose.sh is pretty great. Authentication happens via SSH so all you need is a key-pair to register. Uploading posts is as simple as `scp hello-world.md prose.sh:/`. This also means that you can bring your own editor and you control the source files.
Coming from hugo, prose.sh has been much easier to publish content since I pretty much live in the terminal anyway.
Mataroa supports markdown, with images (and you can store your images on Mataroa servers), and syntax highlighted code blocks (which is something they don't openly say). I normally don't use formulae in my blog posts, so I don't know that part.
In every case, Mataroa has a free tier, so you can always try before you buy. If you want to see, my blog is at https://blog.bayindirh.io.
I recall trying this a few years ago using my Telegram account, but I could never figure out how to edit a published post or delete it. There were also some other drawbacks that I don't recall now.
I have mixed feelings about generic names like this, but naming a blogging service “Bear Blog” when there is a pretty well known Bear app for writing, seems to be inviting confusion.
Or maybe someone will make a Bear theme for Bear? Or a Bear to Bear integration?
