Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all.
Fuck spending 3 hours working out why you’re not able to use relative image paths in MDX files and have to shove everything in /public.
Fuck fighting five layers of configuration and bundlers and libraries and GitHub issues to try and load a WASM file without having the whole thing break.
Fuck some half-assed play at being a static site generator and a backend framework, that conveniently works best on your overpriced cloud service.
> This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
This is gold level comedy. I am not sure how no one in the tech industry is seeing this.
It really is counterproductive. If projects are going to take months to work on critical issues, they need to change the definition of "stale" to match, or just not auto-close issues at all.
It accomplishes nothing and obscures the sign posts that would help the next developer that encounters the same issue.
I recently tried to rebuild my Jekyll blog with Nextjs. This felt way too hard for something that was basically a nunch of static pages, but I pushed through and ignored that feeling.
This, though? It's confirmation that my type of use case wasn't a priority for this library.
Ah this was me when I moved to next 13 and finally said fuck it and moved back to plain templates and some webpack (for ts for doing non ajaxy js). Even as a backend/platform I actually gave the modern JS ecosystem a really decent try (about 2 years on next/react alone). And before that I had written fairly complex fe code in typescript (granted these weren't doc oriented apps but were more like IDEs). The moment I had to serve static-ish sites the complexity just ballooned!
No that's not true! Svelte is a standalone project. Rich Harris, the founder and face behind Svelte, is paid by Vercel to work on it full-time.
From the same link above:
>> "Joining Vercel enables Rich to work on Svelte full-time, giving the project its first dedicated contributor. The governance of Svelte does not and will not change – it's still the same independent, open-source project and community. With Vercel's backing, Svelte can get even more ambitious."
I know Rich Harris explicitly says, at least when Vercel ownership comes up, that he has a lot of leeway and total control of the project; is there any reason to think that Vercel will force Sveltekit to adopt similar things as Nextjs?
The image component works fine when self-hosting, I use it on several production sites. What is it that doesn't work well without their cloud service?
The default bundle size is also nowhere near 1MB. Next 13 and server components entire point is to reduce the bundle size by not shipping JS that is only ever called on the server.
How do I optimise and convert all my static image files to webp with a PNG fallback, then render them as a srcset so the client can pick the best image?
I.e everything that’s done here[1]
Oh no. You can’t. You need to set “images.unoptimized = true” and be happy about it if you’re not using a cloud image service.
I'm not sure why this is your experience, but the site I am referencing does exactly that. The images are even being pulled from an external domain. They are not PNGs but I am not sure if that makes a difference (they are 100 quality .webp), they get optimized to a lower quality and have srcset, no vercel involved because I do not want a dependency on Vercel.
You just use the image component and specify the sizes. The png fallback is provided via the server looking for the Accept header so when it supports webp it gives you webp, otherwise you get png (or jpg depending on the original extension)
It allows you to build full-SSR apps with Tailwind and JSX, has support for SQLite and HTMX, and is in general a great return to how web dev used to be / should be.
Fuck 1MB of JS to render a static HTML page.
Fuck the image component, and not being able to optimise your image unless you use their cloud service for no reason at all.
Fuck spending 3 hours working out why you’re not able to use relative image paths in MDX files and have to shove everything in /public.
Fuck fighting five layers of configuration and bundlers and libraries and GitHub issues to try and load a WASM file without having the whole thing break.
Fuck some half-assed play at being a static site generator and a backend framework, that conveniently works best on your overpriced cloud service.
Use Astro. It’s what next.js pretends to be
https://astro.build/