patafemma

I don't specifically like Windows. But for me, it's the best option of the three. Every Linux distro I've ever tried have had some user experience issues or bugs with the user interface. Also, there's a lot of commercial software like PowerPoint and Excel that are not available for Linux.

I don't like Mac keyboard layout, keyboard shortcuts or window management. I like the hardware but I cannot get over this stuff.

Windows gives me WSL2 so I can basically use Linux with Windows user interface. I've heard a lot of complaints about Windows user experience but personally I like it way more than Mac. It has it's issues but I can live with those. So Windows it is.

I used to work with a Linux laptop daily. Mostly Linux Mint, but tried some other distros as well. I got frustrated with UX issues, problems connecting to external monitors and also sometimes I need to use PowerPoint and Excel.

Now I'm happily running Windows 11 with WSL2.

Thanks for the feedback! You're absolutely right: simple cases like rendering lists, tables or key-value pairs are straightforward and can be done with many different tools without much effort. But the devil is in the details.

Where it gets tricky is handling more complex data structures: deeply nested objects and arrays, different date formats, varying element types and adapting the layout based on the structure. SnazzyPDF's layout engine automates those decisions. The configuration options are still limited but that's what I'm focusing on improving next.

Thank you for the feedback! I agree, the niche seems pretty small. But I think there are not so many other options for this use case. At least I feel that creating a template and fitting your data into it is a different use case than throwing an arbitrary JSON against an API and getting a PDF document out straight away.

Open sourcing the project is not something that I have decided against. Maybe it could drive more adoption. I've found Chrome to be the best tool for PDF creation in this use case, so the API is actually running a pool of Chrome instances that are used for the rendering. This makes self-hosting slightly more complicated.

Thanks for the feedback! You're right, many technical users could likely roll their own solution, and for one-off projects, that's a valid approach. However, after working on this for a while, I've found that building a more generic and flexible solution is definitely not a simple task. The goal with SnazzyPDF is to hide the more complicated bits like the layout and consistent formatting of deeply nested JSON, without the need for maintenance. It's aimed for the people who value saving time over building from scratch. I know, maybe it's not really for the most hacker-minded.

Regarding the page/file size limits, that's helpful input. I have set the current limits based on my own experience but haven't had much opportunity to validate them yet. I’ll definitely take another look and try to find a good balance.

Well done! Basic functionality feels pretty smooth and polished. One thing that I found myself very quickly missing: being able to snap shapes to each other or to the grid.

I guess it depends on how you define consciousness. I think by most definitions, we definitely are unconscious when we are asleep.

Really interesting question. I haven't really noticed any difference in programming styles based on education. But in my experience, you can often see by their programming style if a programmer has worked more in larger corporations or in startups.

Congratulations on the launch! Please, consider putting up a screenshot at the top of the README. When I see visual products such as games or GUIs showcased in HN, having a good screenshot or two is often the deciding factor in whether I try it or not. And probably I am not the only one. A picture is worth a thousand words.

This is a very good article: it explains each point clearly and also includes clear and appropriate code examples. I personally love using modern CSS as much as possible, as opposed to javascript, since it allows separating the visualization and functionality from each other. Of course using pure CSS can also offer noticeable performance benefits.

The thing the article seems to be missing is an explanation about when not to use CSS. In my experience there's a lot of scenarios which could be solved with pure CSS in theory but in the end will be implemented in javascript.

The first reason is browser compatibility. If older browsers need to be supported (unfortunately IE is not completely dead yet), many CSS based solutions are just not possible.

The second reason is changing requirements and future-proofing. Often only the simplest requirements can be fulfilled with a pure CSS solution. When more requirements are added or the feature needs to be extended in any way, the only possible solution is to just completely scrap the CSS solution and re-implement it in javascript. I feel this happens so often that most web developers just prefer implementing the feature in javascript straight away because they know it will be easier to change later if needed.