Totally agree that creating something to reproduce the issue is a big turn off when it comes to reporting bugs; what else can one do though? In your case though, I guess it was a pretty simple thing

Well-written and valuable for insight whether you have similar personal experience or not. As someone who does hardware and software as well, I relate to the challenges of making something you can hold; it's very easy to underestimate the challenge difference between the two. Your Murphy's law references are spot on; I feel comforted reading I'm not the only one this happens to! Misery does love company, and it's important to hang on that I think, so that you don't lose hope :)

When I read the "I had no prior experience in hardware; I was counting on being able to pick it up quickly with the help of a couple of mechanical/electrical/firmware engineers" I was ready to curl up into a foetal position... the fact that the author actually got something like this manufactured and shipped is nothing short of miraculous, it's not just a board off JLPCB and a plastic case, this involves custom manufacturing of metal parts and whatnot, and I take my hat off to him for managing it.

This is also why so many crowdfunded projects fail, people go into it with no idea of how hard it is to get something to market and waaaay underestimate the time and cost. Years ago for the first project we did we took an absolute worst-case estimate, then doubled the time and cost on that. We came in on time and under budget, but only just.

Looking back I agree it was miraculous lol, I don't know if I'd do it again...

Thanks :) It turns out "hardware is hard" isn't an exaggeration!

Congrats on the first batch shipment! What an accomplishment. As someone who just crossed 10 years as a first time foray into HW, I'd like to tell you it gets easier. It doesn't but keep going anyway! Good luck.

https://blog.iotdef.com/celebrating-10-years/

Service workers solve the cache issue; web apps can run permanently offline after initial load. You may be a bit out of date on the state of the web.

No, I use them but loading and unloading the app in the tab still happens when the browser flushes the app from memory because the OS killed it or the browser eviction policy hits.

This loading is not nearly as seamless as a regular app starting back up.

For a regular app, you have the app loading, and the os cache helping with it. If you do your job half correctly, it loads as a block almost instantly.

For a web app you have the web browser loading, the the display of the white viewport in a flash, then the app loading in the browser (with zero os cache to help with so it's slower). It needs then to render. Then restoring the scroll (which is a mess with a browser) and the state as much as you can but you are limited with persistence size so most content must be reloaded which means the layout is moving around. Not to mention JS in a browser is not nearly as performant as a regular app, so as your app grows, it gets worse.

Service workers allow you to control cache in web apps; you may be a bit out of date.

There are hardware APIs for some stuff that only works in native (cors, raw tcp), but 99% of apps don't need those.

I think the parent may be referring to the fact that safari/webkit will evict all localstorage/indexeddb/caches etc after 7 days of not visiting a site. And apparently this now extends to PWAs making it a pretty big blog to building any infrequently accessed PWA that needs to persist user data locally.

I store my data in the service worker cache, so I guess I'm immune to this issue

I do but I feel it's long overdue for replacement. I've been working on a new protocol that includes timestamp filtering, real-time notifications, and optional things like 'likes' and 'comments'. I use it everyday and I load it with content from RSS feeds. Not ready for sharesies yet though

A self-hosting ecosystem with apps and services to do everything from file sharing, to email, and dynamic DNS. It's Javascript based and runs in node, but I've also got it running under Android and in a regular web browser (the web browser one needs requests forwarded to it). The whole goal is to make self-hosting really easy, cheap, but also capable. It's got a long way to go, but I've already posted a few articles on HN that are hosted on it.

I'm not sure I can accept the findings of this article. It seems to me that all the concerns and issues can be summed up to bad design. A mini framework should be designed to be easy to adapt and extend, and any layer on top should be just as easy to further adapt and extend. That to me is the crux of this, "avoid frameworks that are difficult to adapt and extend".

I feel like “bad design” is too reductive. The article is an attempt to explain why it’s bad. What are the practical problems it introduces?

I think it could go a little further in explaining what I think the root cause of the issue is: the people developing this mini framework do not have the time or focus to turn it into a full framework. Compare to Django, Rails, React who, whatever your opinion, clearly have time and mission to build, test and document a framework for others to use.

The very nature of working for a SaaS company means your true goal is to build shit for your customers. Any internal tooling has to overcome this large hurdle to get the attention it needs to be able to truly thrive. And rightly so.

You don't need React or HTMX; just put onclick= on your element and make your call with vanilla javascript. Use these frameworks if you want, as they're both neat, but frankly I think people forget that there are other options

Depends on what you mean by "native". Like do you mean same look and feel, or just launch and performance?

I disagree overall. While good points are made, a client could simply pass state data when reconnecting SSE. Tell the server the last message that was received, and you're good to go. Long story short is that SSE isn't the problem, it's how you're using it that might suck.