To make sure i don't push temporary local changes to production, I used to have a github workflow that rejected code that contained the word "TODO" or "console.log". This way, i could add TODO comments that actually need to be done before deploying. Now i'm usign github less but my deploy script does the check, and you can probably make a pre-commit hook with this, or pre-push
I've set this up for my parents, they have a small bed and breakfast in the countryside, and they love it. It's much more responsive then their past WordPress install when editing, because their desktop is faster than a cheap PHP hosting. Some things are needlessly complicated in publii though, I'd like to make a more minimal version one day
I use this at work (Enterprise SAAS web software) and we had to implement a backup "polling every 5 seconds" for clients that would not support it. It's quite rare though. We assume that some caching proxy might be waiting for the GET request to be fully done to cache it and then give it to the user or something like this. The SSE would then never get updates, while every normal HTTP request would work
I've read that this does indeed happen with some HTTP proxies. In some environments that includes HTTPS because some environments intercept HTTPS traffic too. It's enough for me to consider SSE too unreliable to use if my application needs to be reliable with events, and it's the first thing I thought when I saw the SSE spec the first time.
Back beore SSE, I recall seeing some server-to-client event protocol specification inserted extra padding bytes after events in the middle of an HTTP response stream, just to convince some HTTP proxies to forward the event in an incomplete HTTP response, but I don't recall which protocol now. It was never entirely clear how much padding would be enough, or if any amount would be.
When cometd and the Bayeux publish-subscribe protocol was designed, this is why long-polling was always used, instead of streaming partial responses inside a single HTTP response. With correctly designed overlapping long-polling requests, it's possible to get event latency very similar to SSE, without this issue of lost events due to proxies. So that's a good, reliable choice, if you don't use WebSockets. In fact it's more reliable than WebSockets (which can also get stuck at some proxies), so if you value very reliable event delivery long-polling or just periodic polling are the way to do it, but with much higher overhead.
In theory SSE provides the option for mobile device power saving described at https://html.spec.whatwg.org/multipage/server-sent-events.ht... Using more active protocols almost certainly defeats this. In theory a mobile network and network stack (modified inside the mobile browser where cleartext is available) could implement that power saving strategy for mostly-idle WebSockets too, which is another argument for WebSockets.
I keep thinking something must be "wrong" with my scrollwheel, as all those experiences are super annoying but keep getting published by some people. I think it's not as bad if you're on a Mac or something. Anyway, I agree, it's just bad ux
Funny how they went through that much effort to render everything client side, but then restrict the whole thing to a (quite frustrating) one dimensional control with the scroll wheel. In the end, a pre-rendered video would have worked much better for this UX. Many WebGL "experiences" I see fall into this trap, they want full control of what's shown, wasting their technical effort.
Good point ! I'm on firefox on linux, and after 1 min of loading the thing it barely could run on my machine, so I didn't explore every possibility. If you can look around I guess it could be replaced by a 360° video but those are really heavy, probably more than the 3D experience itself.
As a JS dev, I have no idea what I'm looking at. Maybe add a description at the top of the readme telling what the framework is for, in layman's terms ?
Much better than what I expected to see. But i'm not sure what the use case here. Who wants to see absolutely all comments posted in real time ? I didn't really see a login button, or filters. At least it's (very) compact
I use the main page to view New Stories, Top, and Hot stories without needing to refresh the page. Latest Comments are nice to have on the side to see what people are discussing. Hide columns if you are not using them. I think the main feature though is the Story view, I like collapsed top-level comments and clicking on comment body to easily expand/collapse (works well on Mobile), and getting notified with link to new comment while in Story view. You can leave the page open and come back later and see new comments. I just added new feature: tab title gets updated with new comment count so you can see how many new comments while in other tabs
Login was going to add if people like the page. From what I understand there is no HN OAuth, so people would need to enter username/password which is a negative. There is a nice search feature but it is hidden, I want to integrate it better with the site. Feedback is appreciated
I didn't completely hate the abuse of JavaScript in this. But still it's not as enjoyable as a simple responsive page of static HTML and images you could scroll.
