Twindle: Modularize Handle bar Templates

Created on 26 Nov 2020  路  6Comments  路  Source: twindle-co/twindle

Most helpful comment

I and @Mira-Alf looked into it and we both agreed: Bad Idea.

Partials are horribly complicated and wouldn't solve any problem, rather create new ones.

Mira partially solved the page break problem using a CSS property. It can't be completely solved without imposing some restrictions on image sizes and embedded tweet sizes or so. Big enough entities will break.

@tolgaerdonmez is working on replacing handlebars templates with svelte SSR'd components. These components will be agnostic, and can be composed easily and flexibly for both EPUB and PDF code. Thanks to Svelte, we'd be able to develop and design the templates just like we do web development: Running a dev server.

We have both looked into pdfkit and we don't think we are capable of writing scalable, future-proof, and overall capable-enough implementation. Here's why:

  • Working with pdfkit is like working with the Canvas API. It prioritizes drawing objects on the pages rather than making documents the HTML way. You have to calculate and assign manual coordinates to every single thing. That alone makes it highly unfavorable.
  • For the above purposes, we'd need to do lot of calculations for every single thing. Make our own Text, Image, components, and these are highly likely to be very inflexible
  • Chances are very high that the code outcome would be tightly coupled with the template components, and if I and Tolga leave this project, any customization would be nearly impossible and would require a lot of professional touch
  • Doing this will take time. Way too much time. We'd rather add more features and shoot more bugs in the CLI itself rather than re-invent the wheel.

I favor this approach:

  • Replace Handlebars with Svelte rendered to string. We all hate the Thread.hbs file anyway.
  • Keep using puppeteer for rendering it.

Tolga and I discussed about Puppeteer on AWS Lambda. We think it is feasible.

  • I have done a project before that compiled Handlebars and printed a huge 30 page document using puppeteer on Firebase Functions, and implemented all the wild optimization methods.
  • We found some resources which download chromium once and cache it on AWS itself efficiently (AWS Lambda, if it's similar to Cloud Functions, doesn't charge on node_modules size. Not sure on this point. Research required).
  • Combined with the global variables hack, we should be able to minimise costs by reusing the same chromium instances when traffic is too high.

All 6 comments

I and @Mira-Alf looked into it and we both agreed: Bad Idea.

Partials are horribly complicated and wouldn't solve any problem, rather create new ones.

Mira partially solved the page break problem using a CSS property. It can't be completely solved without imposing some restrictions on image sizes and embedded tweet sizes or so. Big enough entities will break.

@tolgaerdonmez is working on replacing handlebars templates with svelte SSR'd components. These components will be agnostic, and can be composed easily and flexibly for both EPUB and PDF code. Thanks to Svelte, we'd be able to develop and design the templates just like we do web development: Running a dev server.

We have both looked into pdfkit and we don't think we are capable of writing scalable, future-proof, and overall capable-enough implementation. Here's why:

  • Working with pdfkit is like working with the Canvas API. It prioritizes drawing objects on the pages rather than making documents the HTML way. You have to calculate and assign manual coordinates to every single thing. That alone makes it highly unfavorable.
  • For the above purposes, we'd need to do lot of calculations for every single thing. Make our own Text, Image, components, and these are highly likely to be very inflexible
  • Chances are very high that the code outcome would be tightly coupled with the template components, and if I and Tolga leave this project, any customization would be nearly impossible and would require a lot of professional touch
  • Doing this will take time. Way too much time. We'd rather add more features and shoot more bugs in the CLI itself rather than re-invent the wheel.

I favor this approach:

  • Replace Handlebars with Svelte rendered to string. We all hate the Thread.hbs file anyway.
  • Keep using puppeteer for rendering it.

Tolga and I discussed about Puppeteer on AWS Lambda. We think it is feasible.

  • I have done a project before that compiled Handlebars and printed a huge 30 page document using puppeteer on Firebase Functions, and implemented all the wild optimization methods.
  • We found some resources which download chromium once and cache it on AWS itself efficiently (AWS Lambda, if it's similar to Cloud Functions, doesn't charge on node_modules size. Not sure on this point. Research required).
  • Combined with the global variables hack, we should be able to minimise costs by reusing the same chromium instances when traffic is too high.

cc @johnjacobkenny

I am okay with sveltejs as long as it doesnt cause any new issues and everyone is onboard with the idea. Like @PuruVJ mentioned, handlebars doesnt solve all the formatting issues - I just solved the pagebreak issue but even that some of the linkboxes still cause some issues. And newer issues might crop up for github and hackernews formats as well. If sveltejs is AWS lambda compatible then I am all for it.

I'll have to catch up with these!!

I also agree with @PuruVJ about handlebars to svelte transition. It would be much better to handle things in a more code splitted, more controllable with bare js logic and such. 馃憤馃憤馃憤

I suppose this can be closed as Mira has introduced Partials and we have agreed on Svelte as an experiment.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

vasudeveloper001 picture vasudeveloper001  路  4Comments

tusharkandpal picture tusharkandpal  路  3Comments

proful picture proful  路  4Comments

johnjacobkenny picture johnjacobkenny  路  8Comments

proful picture proful  路  6Comments