winwiz

The library customers can install app called "Google Authenticator" provided they own a smartphone. It works without network connectivity.

Just use the app to scan QR code when creating a Gmail account. Or do it anytime later. Then never use network connectivity to generate the 6-digit 2FA code.

Repeating references to the same CSS framework are mildly annoying, especially in the given context.

Typo, meant to say: ... that Workers are running on V8.

One of the substantial sticking point issues, likely to be discovered by a developer who just made a dive into the Workers ecosystem, is the lack of full NodeJS compatibility. Taken for granted by people who didn't realise at first that Workers are not running on V8.

Hopefully open sourcing will stimulate the community, and maybe Cloudflare, to address the incompatibility issue. For example, to develop a shim emulating some filesystem APIs with underlying storage being as scalable as people expect from a filesystem and backed by either KV or upcoming R2.

Outstanding effort. However, and as usual, some improvements can be suggested. For example, users are asked to execute npm and webpack commands as a part of some lessons. What is npm is explained (by supplying a link), any clarification related to webpack is missing. Those topics could have been expanded upon, perhaps taking the whole space of the lesson devoted to building a browser extension. This subject feels to be more marginal whereas knowing what bundlers do and why is more fundamental.

Would be nice if the presumed scope of the article (CF Pages & its not-previously-public Azure-based implementation) was reflected in the title. Or mentioned closer to the beginning of the article to let a reader decide if the article is of interest to them.

Also Pages was facing criticism related to the long building environment allocation time. E.g. you start a build and get a report the build is effectively frozen (usually single digit minute delay) until the required resources have been allocated. In response, CF revamped the Pages building pipeline in order to cut the waiting time. This is currently available as non-public Beta, users can ask to join and start using it. Again, would be good to know if the article applies to the revamped building machinery or not. I didn't know the Pages GA builds use Azure and I don't know if the Beta builds keep using it.

Overall, the Part 1 looks like a useful reminder that any piece of information supplied by a user should be treated as malicious until proven otherwise. And of course, limiting the scope of any privilege/right as tightly as possible is a must.

SPA loading performance can be improved by splitting React app into multiple SPAs each rendered by its own smaller bundle. Additionally, for many websites, the landing/index page of a SPA can be prerendered at the build time. The result is the best performance ever achievable for many (but not all) websites.

Once SPA has been loaded, it switches to SPA internal pages faster than "like we did in the 90s" because for static pages there is no network round trip and no delay called TTFB. For dynamic pages, making API call and fetching API data (to use it for CSR) likely takes less network bandwidth than fetching HTML generated on the server (as a part of SSR).

Also server rendering uses server CPU and it's never totally free. Especially if server side needs to be scalable.

The supposed complexity of SPA can be addressed by splitting a monolithic React app into multiple SPAs each rendered by its own and smaller script bundle. It helps with SPA loading performance as well. E.g. an app can have Login SPA, Main SPA, Reporting SPA, Audit SPA etc.

Additionally prerender the index/loading page of SPA at build-time to improve loading performance even further. For many (but not all) websites the resulting performance would be the best it can ever get.

Crisp React facilitates both splitting and prerendering.

I agree, the author doesn't seem to grasp the fact that CORS always waters down security. That is, CORS is the way of security weakening. Although the author correctly notes that only browsers respect CORS, there is no mention that this happens because CORS relaxes security built into browsers.

When you avoid frameworks for the sake of simplicity, maintainability, security (the attack surface is less), you still don't want to start with a fresh page. At least when dealing with React.

You need a slim boilerplate to create React script bundles, achieve performance and do a few other tasks. That is why I wrote Crisp React: https://github.com/winwiz1/crisp-react

SEO can be achieved with SPA and without SSR. I wrote an article on this subject: https://hackernoon.com/single-page-application-dispelling-se...

Remix uses Server Side Rendering (SSR) done at run-time. As any other technology, it has not only advantages but also drawbacks: https://github.com/winwiz1/crisp-react/blob/master/docs/benc...

Tailwind is powerful, consistent and comprehensive but again the advantages come not without a drawback: In order to use it effectively one needs to learn/memorise yet another CSS. I have better things to do and think it's more efficient to use a set of CSS management approaches: https://github.com/winwiz1/crisp-react#css

Again, each approach has its advantages and drawbacks so one can try to minimise the latter and utilise the former. While leveraging the knowledge of only one CSS: W3C CSS.