Typemill V2

[trendschau]

Just a collection ticket for those who are interested in typemill development and roadmap.

There is php 8.1, slim 4 and vue 3 now. Typemill is about 5 years old now. I would love to start with a Typemill Version 2 this year if there is enough time. From my feeling it is a separate project from scratch that uses the good parts of Typemill 1. To use Typemill 1 and improve it step by step would result in a long chain of deprecations and breaking changes, so it is probably not a good strategy for typemill users.

Some long planned improvements for Typemill 2 could be:

• Cleanup and improve architecture generally.
• Update code syntax to php8.
• Switch backoffice completely to Tachyons CSS-Framework.
• Switch backoffice completely to Vue, but keep routing in the backend (I simply dislike SPAs and frontend-routing).
• Switch nearly everything in backoffice to an json-api like it is for the editor right now.
• Optionally make the api public with api-keys so the jamstack-people can use it like they want (tbh it is a rare case).
• Backend formbuilder should only be used for public forms in future.
• Frontend formbuilder should get repeatable feature for all field types.
• Maybe add interface for building forms, although use cases are rare (see individual forms for register plugin).
• parsedown has a newer version, investigate if makes sense.
• slightly refresh design of backoffice.
• Probably much more

Big big project, not sure when there is enough time and will probably take a year or more, let me know your thoughts...

[MysterieDev]

Have you thought about switching to Laravel?

Inertia or livewire could help you making the Frontend part easier.

I don't know how much overhead that would be.

Also is Tachyons a safe choice for future design? I honestly never heard of it besides this project.

[trendschau]

Thank you for the feedback!

I think Laravel is way to big and slow for a small project like Typemill, I don't see another option than Slim for it right now (lumen is also deprecated, other micro-frameworks are not very well supported as far as I see).

I like Tachyons, but you are right, it is not very wide spread, so maybe a switch to Tailwind makes sense. Regarding Inertia and livewire: I did not work with them so far, not sure how deeply livewire is connected to laravel, but will have a look into Inertia for sure.

The problem with more dependencies is that many of them require updates quite often. Slim 4, Vue 3 (, inertia, ...) => a lot of work for little outcome. If you have very limited resources then you might loose focus with technical stuff and then you don't have time to solve user problems. Always a difficult decision...

[MysterieDev]

ok i get that update hustle for laravel, which is dependent on symfony mostly.

On another perspective - have you thought about not using frontend and webapis to create your ebooks? I've encountered breaking performance problems, if the book surpasses 100 pages. Sometimes the browser crashes with the window.print() function.

With Parsedown you theoretically have a html version of your markdown file. So could it come in handy to generate a pdf version with mpdf or tcpdf?

It would render serverside, so it could weigh on the website performance while the book is generating.

Just brainstorming: You could also make the ebook-generation itself a separate hostable webapp. In the end you'd have to export content and media as folders and then import it into the ebook-app. That would theoretically lower the complexity of your web-application running the website.

[trendschau]

Thank you again, any ideas are welcome !! :)

Yes, parsedown is already used to create the html in backend and then pagedjs is used to generate the book-layout. I am not sure if any open source backend library is really able to create book-layouts of the quality that pagedjs does. I worked with mpdf and tcpdf for simple documents so far, but in other context it turned out that even tcpdf (which is the most advanced I think) is pretty limited when it comes to modern css and book features, for example flexbox is not really supported and get a lot of trouble with different versions and wrappers. Other publishing startups like pressbooks use the (pretty expensive) enterprise software princeXML for reasons. So I don't think that backend-technology will really help in the case of Typemill.

Like you said, another option could be to create a central service, for example with a headless-installation of pagedjs with node and maybe a headless commerce plattform like sylius for distributing. So somekind of leanpub but with decentralized content creation. But I have no experiences with that and this is probably a very big project that is out of my scope.

Anyway, I am working on other central services right now which have a working proc and a business case already, so in far future it would be great to go in that direction ...

[trendschau]

Well, or a completely different idea: use the html2pdf api from @azettl https://printcss.net/api who has already contributed a lot to typemill :)

It is not a problem to generate & send the html and the settings to an api, but you will of course loose all the features that the ebook-plugin provides (selection of layouts, all the settings ...).

But still an idea...

[MysterieDev]

@trendschau If you'd use node, that would broaden your range of possibilities quite a lot.

That however would require you to use a docker or cloud environment like digitalocean. Kind of goes against the easy process you got now simply putting it on a shared webspace or similar.

An compromise between both of these solution would be a CLI tool you can use locally via an private api key for pulling content. in the end it depends on how much technical affinity you assume about your app users.

[azettl]

Well, or a completely different idea: use the html2pdf api from @azettl https://printcss.net/api who has already contributed a lot to typemill :)

With my WordPress Plugin I tried to offer as much freedom as possible, from available APIs (like mine and docraptor) to the possibility to have a renderer locally installed (for ppl who do have more control on their server). This could be a nice solution for typemill too.

It is not a problem to generate & send the html and the settings to an api, but you will of course loose all the features that the ebook-plugin provides (selection of layouts, all the settings ...).

But still an idea...

Aren't all these features in the end not also resulting in a final HTML which could be sent to an API?

[trendschau]

You are right, only some features are javascript-implementations. But we could simply give it a try and look how it works. We even don't have to wait for Typemill V2 because the plugin is mostly a vue application and pretty independent.

I don't want to use another tech-stack like node for typemill v2, typemill has a focus on non-technical users and should run anywhere. So delegating tasks to external services might be a good step. It might also be easier to create business modells around those services in future, so typemill can stay open source and some kind of fremium services on top.

So it is already a very cool discussion with new ideas here, thank you for that :)

[trendschau]

This is work in progress now :D

[trendschau]

Thank you for all your cool ideas, Typemill 2 is out and when everything is running smoothly, I will (hopefully) start adding new cool stuff. Unfortunately the whole code update was immense work with thousands of decisions to make, I hope most of the decisions where fine. Plan is to integrate license, api-services, headless-mode, and KI-integration for this year. Let's see :)