HEEx is HTML aware, so I don’t think we can even compile a malformed HEEx.
And I’m talking about Elixir & Phoenix developers creating their blogs. Not for others.
It’s not about creating a blog engine for others to use. It would take too long to make something close to Ghost. The same reason there’s no Elixir forum made with Phoenix!
I saw 5 or 10 blogs by Elixir developers, who have chosen to go the Markdown route, or database route. So I asked, why not keep it straightforward.
A blog can be as simple or as complex you want it. Likes, comments are not something that a self-hosted blogpost site needs, this is why you are most likely better serving static assets than building something from scratch in phoenix.
Same reason electricians still use light switches to turn on their lights, and plumbers still use the toilet to get their waste into the sewer. When writing a blog it’s much easier to use a blog interface than a programming interface. Some specifics:
- Simpler/quicker publishing mechanism (hit a button vs a deploy)
- Copy-paste support for code/etc
- Drag/drop support for images
- Auto-adding of the publishing date
- Auto indexing of the content for search
- Auto linking of the post from some main menu
- Auto broadcast of new posts on various social media platforms
Basically, all the features people build into blog tools that are specific to blogging.
Yes I’m aware of those benefits. I’m using Ghost Publishing platform myself.
I was just asking why programmers of Elixir & Phoenix community build their own blog, don’t just keep it vanilla HEEx.
Right, yeah, and that’s the question I was answering
I briefly considered it at one point, but very quickly dismissed the idea.
A few months ago I decided to revamp my business and personal websites, including a plan to do some blogging. Since I have been writing a lot of Phoenix related code, the question: “why not use this for these sites?” was definitely considered… Phoenix was front of mind and I’d save having to learn a different technology to do something that ostensibly Phoenix could do if you ignored a lot of stuff that comes with Phoenix. I also was looking for how I’d provide my end user documentation for the application I’m building with Phoenix; some percentage of the potential users would be in scenarios where internet access to their internal staff isn’t allowed and so the ability to host the documentation locally from within the application release was a plus.
In the end, while doing all of the above could certainly be forced into the Phoenix paradigm, it really didn’t make sense for all the reasons others have already added to this thread. I’d be inventing some basics, like what to do/how to treat the metadata associated with a given content posting. I’d be spending a lot of time working problems already solved by tools more dedicated to the problem of blogging and what is really static content generation and management… I would lose time solving the problems that I’m best qualified to solve and to which my application is dedicated: business management software.
So the cost/benefit analysis favored heavily dedicated static site generators for my websites and blog as well as for my end user documentation which will ultimately ship with the Phoenix application. I haven’t regretted the choice once. When I’m writing for my sites or my documentation I’m mostly focused on the content and its metadata, not on how that content will be managed or digested. Sure, I had to learn the ways of my static site generator, but that was far less overhead than having to figure out my own bespoke solutions… which I would also have to remember how it worked. The real burden of the static site generator is deciding which of the many features it has to take advantage of or to ignore.
I landed on Hugo for static site generation and for the end user documentation, I create that as a Hugo site, run the Hugo build process, and then include the built site as static assets in my Phoenix application. I’m sure other static site builders could do things similarly.
So in closing… Elixir/Phoenix may be good choice to build the tools which manage mostly static content, but are not the tools with which to do that job directly. I could see Phoenix being compelling choice for creating a content management system a’la a Drupal or WordPress does (sorry I’m old… I don’t know what the current hotness is in the CMS space)… but for the just the content management piece by itself I’m looking elsewhere.
You’ve received a few answers, can you elaborate as to what about them is not addressing your question? If you understand the benefits, the answer is that Elixir & Phoenix bloggers also value those benefits. What is missing?
All my questions are answered.
I wanted to figure out if I should move my blog from Ghost to Phoenix.
I saw some blog posts on how to create a blog in 15 minutes with Phoenix, and that made me want to move my blog as well.
But now, I feel like I might just stick with Ghost.
I would say long form writing in HTML is painful after experiencing markdown. I tried it recently. I used some really simple PHP (which I forgot how painful that was) for routing and layout and then wrote my posts in HTML. It quickly became cumbersome so I moved over to Hugo. At one point I did have it in LiveView (database-backed). I’m thinking of switching back to that as Hugo isn’t exactly a walk in the park either.
I did also have a version that used Surface with the
<#Markdown> component. That was probably the best in terms of writing right in a LiveView but it didn’t feel like this massive revelation or anything. Nothing quite beats markdown with front matter so typical content.
Also, if I’m going to be keeping likes and comments (possibly tags and possibly other things) then it seems more complex to not also store my blog content in there.
However, if you are going to be storing inline LiveView content then that’s a different story. Like LostKobraKai’s blog does. I would be interested to know how he does it.
This is what I wanted to know.
If an elixir developer is going to create a blog, that revolves around Elixir & Phoenix, why not keep it in HEEx, that way we have more control, and can embed a live example as well.
If we go Markdown route, then we have to have some black magic with custom element in Markdown, to be able to embed an interactive element.
@LostKobrakai, tell us your secrets. How did you modify the nimble publisher or the earmark parser to embed a live view in a page?
How would you do syntax highlighting that’s not supported by the elixir tooling?
Also, why didn’t you just stick with HEEx?
My site isn’t blog-centric and as far as my blog goes, I only have a three posts, one of them is essentially blogspam, and I otherwise have like a million drafts I don’t only write about Elixir and code highlighting was a major factor. Hugo has JS-free code highlighting for pretty much everything.
EDIT: Wasn’t 100% sure if that was directed at my but it felt like it was, lol.
The code is open source: GitHub - LostKobrakai/kobrakai_elixir
Tableau static site generator in README provides with an example using Temple, but it also allows to use the builtin EEx, or use HEEx, Surface, or HAML
I have successfully used it with HEEx
I went through your code, and it seems you are using NimblePublisher to go through the
.md files and render them as blog posts.
Also, you have added a comment within
.md files to embed some live elements as well.
Is it possible to use LiveBook to write Blog Posts? and Nimble Publisher will just parse
.livemd instead, and we get a cool live blog editor as well?
This is quite an interesting idea, in theory you should be able to copy the render part from livebook itself, even though it depends on how tightly it is coupled to the other functionality of the application.
.livemd are still valid markdown files, so NimblePublisher will work. You however won’t get any interactivity that way. Code will become static code blocks. If you expect them to render back like they do within livebook than that’s likely on the opposite end of the complexity scale.
I was converting your blog post to a LiveBook:
# One-to-Many LiveView Form
## Interactive Example
<!-- [KobrakaiWeb.OneToManyForm] -->
## The schema
To start from the beginning – we'll need a schema to power our form. There
are schemaless changesets, but the `Phoenix.HTML.Form` implementation for
changesets don't support nested forms using schemaless changesets. Given
the example shown here is in memory only we'll be using an embedded schema,
but a database-backed schema works just as well.
Phoenix 1.7 added support for plain maps powering forms, which seems like a
viable alternative as well. That option won't be discussed here as part
of updating this blog post though.
defmodule GroceriesList do
embeds_many :lines, Line, on_replace: :delete do
It gave similar output to the
.md file, however, the metadata was getting removed or I have to put it in some markdown block, which placed it away from the top of the file.
title: "Unnest for runtime sorted results"
How to get a dynamic list of items into an ecto query without storing it in the database.
I don’t know if Nimble Publisher can read this metadata if those values are placed anywhere else.
Oh no, I won’t dare to do that yet.
I was just thinking if I can do basic live component integration like you have done.
And perhaps later we can have Kino-based Smart Cell to enable blog editor-like features.
The format I’m using doesn’t do anything in Livebook. I’m also using yaml based frontmatter due to the conversion from a previous static page system.
Generally I don’t think there’s a good livebook workflow around developing live view or live components atm. At some point I setup phoenix.livemd · GitHub, but that would be a lot nicer if setup as a smart cell and doesn’t deal with assets or any core_components one might want to use.
phoenix_storybook it currently a better tool to foster liveview development and iteration.
In terms of static sites, blogs, etc., I have fallen in love with Eleventy/11ty. It’s versatile enough that it can do pretty much anything I throw at it (except talk to a database ).
For blog posts specifically, you can can use Markdown templates. There is even headless CMS integration so it can be used by non-programmer types. (I haven’t gone down that road yet, but I know it’s there!)
It’s a really great tool and I can’t recommend it enough.