I mean, you can be completely sure that the website works offline by unplugging the cable/turning off your wifi connection after it's completely loaded. But that's just a functional test, not something you can expect users to do during a normal browsing session
My initial plan was to replicate the functionality of tools like tinyjpg, thus just offering users a simple interface with good defaults. But I already had in mind the lossy/lossless re-encoding functionality, as well as the quality slider, which I plan to add sometimes in the future
In my (quite small) experience, developing with NextJS has been a breeze.
Some time ago I've decided to rewrite a landing page, written in Node + EJS templates + JQuery, using some kind of static generator. I have always heard good things about NextJS as well as Gatsby, but after some exploration I decided to go with NextJS, since Gatsby seemed more complex and better suited for CMS/other complex websites rather than a simple, light landing page.
The developer experience has been amazing. Plus, I've found an awesome library[0] for dealing with i18n, which completely absorbed the pain of dealing with multiple languages: getting SEO right, make links work, and so on.
Plus, pairing NextJS with PReact, brought my pages first-load size down to ~40KB (external resources excluded), which I didn't think it was possible for something built with React.
The only things that I missed from CRA-like apps were environment variables, which have been added with this release, and a good integration with third-party tools like eslint, typescript and prettier. I did not use typescript because it was just overkill for a simple landing, and I'm launching eslint by hand and in the CI, so I really miss how good the integration is when developing a normal React App bootstrapped with CRA (which has all of this awesomeness out of the box).
I'm currently using Elm at my day job, and I agree 100% with what you are saying.
Elm lacks extensibility, tooling, and documentation is not that great. The biggest pain point however is the people who run the Elm language. The design decisions they took hurt the language and the users a lot, breaking more and more with every version bump, restricting freedom and creating a walled garden that people are getting tired of.
What you say about JavaScript libraries is not 100% technically correct though. You can still access any native JS library you like, but you got to use ports. You can't hook into native elm functions bound to the global scope, but that's always been a very shady, undocumented and terrible thing to do.
The following reasons are what, I believe, really ruined elm adoption:
1) You can't create so called effect modules (like the http module of the standard library, and so on) if your package is not within the `elm` namespace.
2) As a company, you can't have shared, common elm modules if they are not published in the Elm package public registry. You can't install a package from GitHub without resorting to ugly hacks like ostracized elm package managers written in Ruby.
3) No development timelines, no companies publicly endorsing or using Elm to develop open source libraries besides the one where the language founder is employed.
I've never tried anything purely functional and typed to do frontend programming, so I'd like to hear if Purescript, ReasonML, etc share the same struggles with Elm
It seems like the fix is in the making, and could be out in a few weeks.
Meanwhile, there is a forked version of the compiler with a hotfix for the debugger that works for most applications, even medium and large ones: https://github.com/elm/compiler/pull/1850
I mean, you can be completely sure that the website works offline by unplugging the cable/turning off your wifi connection after it's completely loaded. But that's just a functional test, not something you can expect users to do during a normal browsing session