13 ms·
I am wondering why the author didn't opt for a language/platform with a mature PDF and GUI library? If I read the article correctly, it would have halved his d
by ToJans 9y ago
I am wondering why the author didn't opt for a language/platform with a mature PDF and GUI library?
If I read the article correctly, it would have halved his development time...
- pjc50 9y agoWhich one would that be, then?
- zokier 9y agoJava? If it got one thing going for it, it is maturity.
- pjmlp 9y agoYep. https://itextpdf.com https://itextpdf.com
- INTPnerd 9y agoYeah, I would have recommended Kotlin. Runs on the JVM, so benefits from the matureness of Java, but is a more modern, and better designed language. A reason to choose Rust over this is if you actually have reason to believe you will need some extra bare metal performance over a garbage collected language, or you will need multiple threads. From what I can tell, the author did not really have good reason to believe any of those things, they just wanted to stay clear of whatever was wrong with the software they used at work, which a JMV based solution should have done. I am glad it worked out for them though, and knowing Rust is a good asset to fall back on, whereas learning Kotlin should be pretty easy for them. Even so, I like that with Kotlin you can take advantage of the most mature IDE ever made InjelliJ IDEA. I think they would have completed their project faster with this. That being said, the program they ended up with sounds very fast and it probably is faster than if they wrote it in Kotlin. It was the "right" move in the sense that it seems to have worked out well for them. Was it the "best" move? Most moves are not, and they don't need to be. Whether or not Kotlin would have been better probably depends on if it was better to finish faster or have an even more blazingly fast program at the end. I don't think a Kotlin version would have been slow or had any of that wait for 30 seconds nonsense, but it probably would have been a little slower. Would that a "little slower" have mattered? It depends on who is using the program and how they are using it. It always feels nicer to have a program that feels like instantly responds to your every whim.
- nyir 9y agoAny browser. The article has no detail but I suspect that doing it all with a web stack, or even just PDF output with wkhtmltopdf (or a similar solution) would be much quicker than writing a PDF generator from scratch.
- fschutt 9y agoThe concern was quality, too. Yes, I thought about Electron, hell I even made a prototype for that. But in the end quality counts (to me), not speed of development. I knew that I had lots of time on my hands (no investors or anything, just my own money). I didn't have anything to lose. So if you have the chance to make it perfect (versus taking some off-the-shelf tool and possibly ending up with a PDF that isn't quite what you want), would you risk it?
- dbrgn 9y agoSelf financed, quality before speed of development, no investors that need to be impressed. Awesome, more people should do that!
- IshKebab 9y agoC++. You could use Qt and there are probably a bazillion PDF generation libraries - it's not that hard to make your own really depending on what you need to output.
- fschutt 9y agoWell, I expressed my opinions on C++ libraries in the first few paragraphs. None of the C++ libraries I looked at support PDF layers for example (and as a graphic designer, you need that when working with maps, as maps are separated into layers). QTPDF (used in QGIS) supports it, but the output quality is sub-par when working with Illustrator, at least in my experience. This could be a bug in QGIS, yes. But I didn't want to invest time into something that would probably fail (if the QGIS team failed using it, I would probably do so, too).