This feature currently doesn't work well for me, as I tend to write long-form posts with a larger amount of headings. The generated table of contents would take up the entire screen in that case, unfortunately. I'd fix it with CSS, but the one person I got to sign up here didn't use my referral link, so unfortunately it's not an option for me 😅 It would be really cool if you could make it (optionally) collapsed by default as plain sticky element (like how it appears when you scroll down), or better yet could instead display it off to the side while the page is wide enough. A few notes about the current implementation: There's currently a styling bug where some of the clickable header styling still applies even while the list is always-visible, like the pointer cursor and "button" here. It would also be great if, instead of using nested <div> s, you could use a <nav> and <details> element. That would work without JavaScript and is better for accessibility by default (though since you'd have multiple <nav> s then, please consider labelling them ).

There are some off-site discussions about this post: The Rust Programming Language Forum Hacker News I get notifications about new posts in the RPLF topic, so feel free to comment there if you'd like me to see it. If you add a comment on Hacker News then I likely won't notice at this point, since I don't use the site regularly.

Thank you, this gave me enough pointers to look the terms up properly . I've (hopefully) corrected the post in this regard, by switching from "higher-ranked type alias" to "type alias to a polymorphic function pointer type". The changeset can be seen here .

Ali Dhuniya It's good. The server software there does everything I mentioned and it's definitely enough for relatively light apps. It's also good to see that best practices are the default and it doesn't support allowing all ('any') domains without changing its code. When you build heavier apps, for example if you need dynamic <meta> tags for link previews to your pages from social media or have the user log in to your website directly or anything like that, then you'll still have to build a custom backend, though. An exception would be OAuth (i.e. "Log in with Twitter" and the like), which will still work with that server in many cases. Personally , I would likely build the server in something more lightweight than Node.js, but I don't think it's much of a difference in practical terms, if any.

In the interest of maybe improving the situation in general: Where do you think a warning should have been so that you would have seen it earlier? I.e. which resources are teaching how to make API calls to other services from the client without mentioning that this only applies to unauthenticated endpoints? I haven't looked into it very deeply, but from what I can tell, you can use Firebase to build client-consumable APIs, which then are fine to hit directly from the frontend. You will have to set appropriate CORS permissions in that case (see below), though, and you should still only transmit the data that the client actually needs to display. Doing the processing in a separate proxy may be cheaper in terms of hosting costs, but I haven't looked into the pricing enough there. The apps I worked on were generally self-hosted, so we fortunately didn't have to deal with those questions. All that said: Calling third-party APIs with authentication from the client actually mostly shouldn't work in the first place, due to CORS security. Modern browsers won't issue requests to other domains unless the target service is properly configured to give them permission for it, which isn't the default. Since you haven't run into that problem, I suspect you haven't deployed any web app/API key like that online yet. If a service is CORS-permissive but requires a secret API key, then in my opinion they're partly to blame for any misuse that happens. There's usually a warning not to publish them next to any keys/tokens, but that doesn't mean they should make it easier to have them in the client than to secure them properly. Occasionally, a (usually very new) developer sets up an open CORS proxy (without a domain whitelist). These are often misused by malware, since they disable one of the fundamental building blocks of web security that a lot of other safety mechanisms build on. I'm mentioning it here because that's probably the most important point to be wary of when creating a backend service for your projects: Always limit it so only the same domain (default) or a specific set of trusted websites can make requests. A Referer whitelist causes issues with certain privacy add-ons, so unless your service is available without TLS (CORS doesn't always apply over plain HTTP.), it's better to avoid using that feature.