6 ms·

This makes for a quite compelling case relating to the Casey Muratori video around clean code that made the tech community rounds recently. The developer of Sum

by _hao 4y ago

This makes for a quite compelling case relating to the Casey Muratori video around clean code that made the tech community rounds recently. The developer of SumatraPDF has rolled his own implementations for a lot of things in order to reduce bloat and it shows! The app is lightning fast and does its job perfectly. Wish we had more native projects like that!

mananaysiempre 4y ago
Notably, the roll-your-own parts do not include core PDF parsing and rendering, which are outsourced to (possibly a fork of?) mupdf.
- hedora 4y ago
  This makes sense. PDF is (was originally) a stripped down version of postscript, and postscript ran well on embedded processors by the late 80’s.
- tormeh 4y ago
  Mupdf is the key. Sadly there's no user-friendly mupdf wrapper like Sumatra on Linux.
  - olddustytrail 4y ago
    What about zathura mentioned upthread?
    - tormeh 4y ago
      Doesn't have a ToC sidebar, which I consider pretty much the absolute minimum of GUI necessary. You can use a keyboard-driven menu by pressing tab, but in my experience it just takes you to the last page of the pdf. Maybe there's a bug or maybe it's user error. Regardless, this isn't what I'm looking for.
badpun 4y ago
100% agreed! I’ve switched go Sumatra PDF roughly 5 years ago, after Adobe Reader became just absurdly slow. It’s crazy how a hobbyist can make product that’s vastly better than a multibillion dollar company.
- taneq 4y ago
  Adobe’s goals for Acrobat Reader are almost diametrically opposed to yours.
  - badpun 4y ago
    Wouldn't it further their goals to make their software not abysmally slow? There can't be any competetive advantage in making something this slow, unless they did it with extremely cheap, unqualified programmers - then you could argue the cost savings were worth it.
    - jasbur 4y ago
      They’re in a de facto monopoly position with Reader, they don’t have to worry about users leaving for a faster product. Probably, all of their best programmers are working on revenue generators, not performance.
  - flumpcakes 4y ago
    You would think "reading PDFs without annoying the user" should be the first and golden goal. So much software in the modern era has horrible UX because the vendor's goals aren't aligned with the users' goals, where really the users' goals should be the only thing you care about as a company. At my $DAYJOB you could fire 80% of the R&D staff and refocus efforts onto what our users actually want, and we would probably have a better product which less major incidents. This is for a company only in the ~$100m revenue. Of course, we're not $WEBSCALE so maybe things are different for the $1bn+ revenue companies.
    - taneq 4y ago
      You'd hope so, but I'm guessing their actual top priority is making Acrobat look cool in passing to the execs that they want to choose it for their company signed-business-document needs. These execs don't use Acrobat themselves.
kerpotgh 4y ago
[dead]

by _hao 4y ago

mananaysiempre 4y ago

Notably, the roll-your-own parts do not include core PDF parsing and rendering, which are outsourced to (possibly a fork of?) mupdf.

hedora 4y ago
This makes sense. PDF is (was originally) a stripped down version of postscript, and postscript ran well on embedded processors by the late 80’s.
tormeh 4y ago
Mupdf is the key. Sadly there's no user-friendly mupdf wrapper like Sumatra on Linux.
- olddustytrail 4y ago
  What about zathura mentioned upthread?
  - tormeh 4y ago
    Doesn't have a ToC sidebar, which I consider pretty much the absolute minimum of GUI necessary. You can use a keyboard-driven menu by pressing tab, but in my experience it just takes you to the last page of the pdf. Maybe there's a bug or maybe it's user error. Regardless, this isn't what I'm looking for.

badpun 4y ago

100% agreed! I’ve switched go Sumatra PDF roughly 5 years ago, after Adobe Reader became just absurdly slow. It’s crazy how a hobbyist can make product that’s vastly better than a multibillion dollar company.

taneq 4y ago
Adobe’s goals for Acrobat Reader are almost diametrically opposed to yours.
- badpun 4y ago
  Wouldn't it further their goals to make their software not abysmally slow? There can't be any competetive advantage in making something this slow, unless they did it with extremely cheap, unqualified programmers - then you could argue the cost savings were worth it.
  - jasbur 4y ago
    They’re in a de facto monopoly position with Reader, they don’t have to worry about users leaving for a faster product. Probably, all of their best programmers are working on revenue generators, not performance.
- flumpcakes 4y ago
  You would think "reading PDFs without annoying the user" should be the first and golden goal. So much software in the modern era has horrible UX because the vendor's goals aren't aligned with the users' goals, where really the users' goals should be the only thing you care about as a company. At my $DAYJOB you could fire 80% of the R&D staff and refocus efforts onto what our users actually want, and we would probably have a better product which less major incidents. This is for a company only in the ~$100m revenue. Of course, we're not $WEBSCALE so maybe things are different for the $1bn+ revenue companies.
  - taneq 4y ago
    You'd hope so, but I'm guessing their actual top priority is making Acrobat look cool in passing to the execs that they want to choose it for their company signed-business-document needs. These execs don't use Acrobat themselves.

kerpotgh 4y ago

[dead]