No 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.
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.
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.<p>The only benefit I can think of is if it leads to more frequent updates by the restaurant, due to limited skillset.
If the restaurant doesn't have anything besides a menu, /index.pdf is fine—no web design required; reuse the menu they're printing anyway.<p>The trade-off is that they'll have to pinch/zoom if they have a small display. It's a minor inconvenience to make the exact information they want available instantly.
The complexity between the modern web and a pdf is marginal. PDFs do get printed for menus. Editing a PDF and uploading it to the site, integrating prices and syncing between the site, online ordering, PDF menus is just part of the business. There are lots of platforms that help with this such as Slice.
Because they can make one nice pdf formatted to get printed out in the restaurant and then reuse it to display on the website
I vastly prefer looking at a PDF menu over an HTML one nearly all the time. PDFs are usually nicely formatted, and I don’t mind zooming and panning to see everything. HTML is frequently terribly formatted, interspersed with ads, slow, etc
> HTML is frequently terribly formatted, interspersed with ads, slow, etc<p>You can put ads into terribly formatted PDFs too
In theory, yes, but the parent comment is talking about what they've frequently encountered in practice. Maybe there's reason to expect that having a lot more PDFs of menus might not result in a similar experience, but it doesn't seem obvious to me at least
Yes, and you can strap jet engines onto horses at the race track.<p>No one does either of those, IRL.
PDF is an enormous pain in the tits to view on a phone and has significant accessibility issues for people using assistive technologies.<p>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.<p>Plain old HTML, with thin CSS on it to make it not be black-and-white Times New Roman. Kicking it oldschool.
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.<p>- <a href="https://astro.build/themes/details/astropie/" rel="nofollow">https://astro.build/themes/details/astropie/</a><p>- <a href="https://astro.build/themes/details/astrorante/" rel="nofollow">https://astro.build/themes/details/astrorante/</a><p>- <a href="https://astro.build/themes/details/tastyyy-restaurant-website/" rel="nofollow">https://astro.build/themes/details/tastyyy-restaurant-websit...</a>
All of my static sites that I've built lately have been done on Netlify. Super easy to hook up to Github and the form handling is a breeze. I've known Mathias going back to when he was personally answering emails and promoting JAMSTACK so you can say I'm a bit biased. lol<p>Netlify is a great company that I'll always support.
I love Astro; there is so much you can do with it.
I was going to recommend the same! Astro + Astro theme + an LLM will get you very far these days.
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.
Remember during Covid where every restaurant's menu was a QR code on the table that linked to a PDF in S3?
A PDF can't get the user halfway through the delivery process before seeing the soups.
No one is browsing the internet without JS today (within margin of error). Whether or not this "should" be the case, it is.
This is the wrong way of looking at it.<p>Making a website's basic functionality work without JS isn't just for the random users who switch off their browser's JS runtime.<p>It's also for the people who have a random network dropout or slowdown on a random file (in this case a JS file).
> It's also for the people who have a random network dropout or slowdown on a random file (in this case a JS file).<p>Does that really apply when the javascript is only ~2kb?
Do the end user should troubleshoot if that was a network dropout, some browser incompatibility or just a crappy code by a crappy coder?<p>> the javascript is only ~2kb?<p>It can be even 200Mb if it's not loaded properly and now a website doesn't even function.
Yes, any request can get stuck at any time.<p>That is what's happening any time you've seen a website that randomly decides to load without styles, or with a missing image.<p>The good thing is that it's very apparent when that happens and you can just reload the page.<p>But it's not immediately obvious when it happens with a JS file.<p>That's half the reason why you shouldn't re-implement css features in a js file. (the other half is performance)
Then why does that same logic not apply to the CSS file?
From a business perspective you can go further: the people who are browsing the internet without JS are people who are going to cost you more to support than they'll ever bring you in revenue. Just like trying to support Linux gamers, excluding them is a net positive.
PDF is a terrible experience on mobile
I wish restaurants would just make a homepage with menu _and_ opening hours.<p>In my area most restaurants have no website.<p>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.
The soup shows for me without JS.
Nobody should need a PDF renderer to see the soups.<p>Actually, nobody should need an XML parser to see the soups either.
As an embdded engineer I'm always disappointed at how much processing power and RAM is needed just to display websites with just images and text. The vast majority of them do not need javascript
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....<p>/s