alt Hacker NewsNo one should need JS to see the soups when that could be handled perfectly fine with CSS. I wish restaurants would just make their homepage a PDF of the menu.
Replies
I agree with no JS, but why PDF over HTML? Hard-wrapping for letter-sized paper (ok, a PDF doesn't need to be letter-sized, but most menus are approximately that) with crapshoot reflow options for soft-wrapping in certain viewer apps is pretty dicey on a phone, mitigated only slightly by rotating the phone sideways.
The only benefit I can think of is if it leads to more frequent updates by the restaurant, due to limited skillset.
What an exhausting solution to a made-up problem. This is exactly the kind of functionality JS was made to provide. There's a lot more JS in the PDF.js renderer modern browsers, and if you're not using a modern browser it likely wouldn't render at all. As others have pointed out, you're asking restaurants to throw away mobile traffic, screen readers, anyone not on a mainstream desktop browser to save ~20 lines of code in a programming language you don't like.
PDF:s are not great on mobile. And you can’t easily translate them (I often translate restaurant menus when they are on a website with just 2 clicks)
To be fair this project uses zero 3rd party npm modules for runtime. The total runtime JS it uses is 1.76kB in size.
I agree. There are lots of free AstroJS themes for restaurants that generate static html that you can host somewhere like Firebase hosting for free.
- https://astro.build/themes/details/astropie/
- https://astro.build/themes/details/astrorante/
- https://astro.build/themes/details/tastyyy-restaurant-websit...
I wish restaurants would just make a homepage with menu _and_ opening hours.
In my area most restaurants have no website.
If they have a website it's often very hard to find their opening hours. Under 'contact'? Nope! At the footer? Nay! Maybe somewhere hidden in the menu PDF? With luck... Outside their homepage at google maps? Maybe. On their Tripadvisor page? Hahaha! Funny! Not.
PDF is an enormous pain in the tits to view on a phone and has significant accessibility issues for people using assistive technologies.
It's not even about blind people. People with ADHD or dyslexia use assistive technology, which frequently makes an absolute horlicks of interpreting PDF. It's one of the reasons I'm trying to move a lot of documentation at work away from PDF and onto just straight HTML.
Plain old HTML, with thin CSS on it to make it not be black-and-white Times New Roman. Kicking it oldschool.
A PDF can't get the user halfway through the delivery process before seeing the soups.
Remember during Covid where every restaurant's menu was a QR code on the table that linked to a PDF in S3?
No one is browsing the internet without JS today (within margin of error). Whether or not this "should" be the case, it is.
PDF is a terrible experience on mobile
Nobody should need a PDF renderer to see the soups.
Actually, nobody should need an XML parser to see the soups either.
The soup shows for me without JS.
No one should need PDFs to see the soups when they can be handled perfectly fine with CSS scoped to print and save to PDF....
/s
No one should need an entire PostScript interpreter to see the soup of the day, either. A restaurant menu is text and images. HTML and CSS are perfect for text and images.