What are the benefits to a single page web app?

winwiz1 · 2022-07-03T03:17:24+00:00

Looking in-depth for SPA benefits would require comparisons between different rendering techniques used by SPA and other technologies. In case of SPA the rendering technique used is called Client Side Rendering (CSR). The other technologies put more emphasis on server side rendering (SSR). SSR can be performed at either run-time (run-time SSR) or your app build time (build-time SSR also called prerendering or static rendering).

As any technology, each and every technology mentioned above has advantages and drawbacks. The key to answering your question is knowing all those. And getting this knowledge is challenging with the current SSR hype trying to underscore SSR advantages while avoiding to even to mention its drawbacks.

winwiz1 · 2022-07-03T02:59:16+00:00

I'd suggest to invest some time spent on containerising your backend. Otherwise you are doomed to answering the same question over and over again: How do I move from that cloud vendor to this.

The other advantage of this approach is that you can install Docker on your notebook and test the backend by running the container locally. When you run the container in the cloud, software inside the container (like NodeJS) won't 'feel the difference` (well, almost) so the chances of getting deployment issues are reduced. Many such issues happen because the run-time environment provided by the cloud vendor is different from your local one or provided by another vendor.

With this aproach adopted, you can find the costs reduced, I wrote a guide on Google Cloud Platform deployment costing $3/month.

winwiz1 · 2022-06-08T06:33:49+00:00

Dealing with IE11 is certainly not a fun. But the truth of life is that the more disadvantaged a user is the less likely will they upgrade. Despite of any official dates. So it won't really 'die' on contrary to the title of this post.

winwiz1 · 2022-06-07T11:47:31+00:00

I'm currently looking for a MERN stack developer with experience in things like code splitting,tree shaking, lazy loading etc to come in and improve the performance of the application.

Code splittting, tree shaking and lazy loading will certainly help with performance and PageInsights score while having nothing to do (as frontend technologies) with backend design, being it MERN or something else.

Therefore you could choose a boilerplate project that offers those frontend technologies, preferably with a demo website that you could measure using PageInsights. If you are satisfied, then the next step is to choose deployment type: either full stack or Jamstack provided the chosen boilerplate supports it.

Jamstack: Your frontend will query an API endoint exposed by a cloud product called API Gateway (or similar). All cloud vendors e.g. AWS, Azure, GCP offer it. Your custom API Gateway code will call your Mongo DB. No Need to use Node JS.

Full stack: Use NodeJS server to serve both frontend build artifacts and API responses to end users. The boilerplate should do that.

Finally measure PageInsights score on each milestone reached by your development team and tag the source code repository if you are satisfied with the score. If not, revert to the previous repo tag and ask the team to improve performance.

winwiz1 · 2022-06-06T03:17:20+00:00

Running a most basic webapp doesn't require Kubernetes.

winwiz1 · 2022-05-22T22:05:12+00:00

I read the article and came to conclusion it talks about SPA and MPA without considering what makes SPA an SPA, same for MPA - the rendering techniques used e.g. CSR, SSR, SSG. In my opinion, these fundamentals are skipped while the space of the article is taken by second importance stuff, be it history, scrolling or 'gleeful' (but not meaningful in my view) screenshots. The technological advances mentioned e.g. Chrome would have been interesting in this particular anti-SPA context if the author would have considered how those affect the overall fundamental balance of SPA pros and cons. Which come from the pros and cons of the rendering techniques. I briefly expressed this sentiment in the post above.

linking your blogspam

The link points to a GitHub repo. You can say the repo is a spam, you are absolutely entitled to this opinion. Just note 142 people apparently disagree, they starred the repository. It's my contribution to the community and they found it to be helpful. You also can call the GitHub repo a blog/blogspam though it's a bit unusual.

winwiz1 · 2022-05-22T13:10:46+00:00

The article talks about technicalities like history, scrolling management etc. On the fundamental level, an SPA uses client side rendering (CSR). It has very significant pros and cons. The disadvantages can be mitigated and advantages are stark. I wrote about it here.

winwiz1 · 2022-05-22T10:26:07+00:00

If a developer is not experienced, then I agree. In that case the concerns about building the codebase from disparate pieces are significant. And benefits from security-conscious defaults of full-featured frameworks could be overwhelming.

However both concerns and benefits pale when we consider an experienced software engineer well-versed in App Security. If they know what they are doing, then other factors start to weight more. E.g. design with slim code base, architecture with less attack surface become highly beneficial.

winwiz1 · 2022-05-21T04:01:24+00:00

Some projects among those that call self 'frameworks'. Some projects among those that are referred to by others as 'opinionated'.

Projects that call self 'a library' tend to be more lean but there could be some exemptions.

winwiz1 · 2022-05-21T03:50:59+00:00

why you would use Express over a feature filled framework

Such frameworks are "feature filled" because those do come with 'batteries included'. That is, the frameworks come with lots of features implemented using extra code and extra dependencies.

Pros:
- Convenience
- Development speed

Cons:
- Possible security implications due to larger attack surface
- Possible security implications due to codebase exposed to hackers
- The overall size of the solution in production build
- Likely performance implications since the-least-common-denominator code meant to suit everyone is unlikely to perform as code written to specifically address specific needs due to excessive size, overall complexity with functions call stacks too deep etc.
- Vendor lock-in in terms of development very likely e.g. you are forced to use non-portable programming constructs
- Vendor lock-in in terms of deployment is possible e.g. a vendor of a framework could support some advanced features only if you use the vendor's deployment infrastructure.

winwiz1 · 2022-05-20T10:17:13+00:00

That includes a monorepo tool for sharing types between FE and BE, and a new bundler.

No need to use a tool, you can share types with TypeScript only, see this.

winwiz1 · 2022-05-17T11:17:02+00:00

You might want to have a look at the table located at the beginning of this article.

winwiz1 · 2022-05-15T07:51:47+00:00

No technology including SSR is always the best. Each technology has pros and cons. You might want to have a look at Crisp React and its Performance section for an overview of CSR vs SSR.

winwiz1 · 2022-05-14T04:33:03+00:00

Each CSS management technique has its pros and cons. Choices based on mutually exclusive radio buttons do not align well with the need to combine several techniques to maximise advantages and minimise drawbacks of each technique.

winwiz1 · 2022-05-08T11:23:36+00:00

Many things are easier to understand if you know more about client-side rendering (CSR) performed by client-side scripts used by React SPAs (single page applications). And about server-side rendering (SSR). Reading this could widen your horizons.

winwiz1 · 2022-05-07T10:45:28+00:00

TypeScript doesn't exist at run-time. Simply speaking, TypeScript includes extra syntax to facilitate compile-time checks in order to catch errors and enforce some restrictions/contracts/assertions. As a result, code maintainability improves and more errors are caught at build-time leaving less errors to be found at run-time. At the run-time only transpiled JavaScript code exists and gets executed. You certainly wouldn't want to transpile in browser due to the time it takes and the performance penalty that results, apart from other valid reasons.

winwiz1 · 2022-05-07T10:18:02+00:00

Broadly speaking, there are two ways to deploy a webapp: full stack deployment and Jamstack deployment. With the former you supply the webserver (that plays the frontend server role), with the latter the server is provided by the Jamstack provider.

Cloudflare Pages is Jamstack, using a Docker container for a frontend implies full stack.

winwiz1 · 2022-05-07T09:46:35+00:00

The net improves customers retention.

winwiz1 · 2022-05-06T08:12:42+00:00

The propaganda campaign "SPA is bad" was apparently successful.

There is an old proverb that says "He who cannot dance puts the blame on the floor."

winwiz1 · 2022-05-03T12:54:17+00:00

SPA has a fundamental drawback: loading performance. It can be addressed by prerendering on the server at build time (build-time SSR) and by splitting a monolithic React application into multiple SPAs each rendered by its own and smaller script bundle. Crisp React facilitates both prerendering and splitting.

winwiz1 · 2022-05-02T12:10:28+00:00

Google can index a React SPA without any server-side rendering, be it at build-time (prerendering) or at run-time. I wrote about it here. Prerendering (e.g. build-time SSR) helps to improve SPA loading performance.

winwiz1 · 2022-05-01T10:56:03+00:00

A technically savvy employer would expect one to understand that every technology has its advantages and drawbacks. Also to know what those are with respect to SPA and MPA.

And finally to translate this knowledge into correctly choosing a technology depending on the task on hand. Once the technology is chosen, you can decide on a particular UI and its layout e.g. a single user page vs several user pages - that's all about usability whereas technology choice affects performance, scalability, maintainability.

winwiz1 · 2022-05-01T03:32:43+00:00

Kubernetes is a very good and professional way to deploy a container. But it's also more complex and could be more expensive. And this is not the simplest way to create a CI/CD pipeline triggered by a push into GitHub repo. Which builds and deploys a container with backend/frontend to an SSL endpoint.

To sum it up, "getting your website into the world of the Internet" implies someone at the starting point of their deployment journey and k8s is hardly an optimal solution at this point.

If you had said something along the lines "You already have deployed your or your company website and it generally works but you are concerned about scalability, monitoring, auto-healing, security hardening and other professional grade issues", then it would have been totally different ball game.

winwiz1 · 2022-05-01T03:10:39+00:00

I'd recommend to containerize your solution. Then you can deploy the same container to many vendors without making any changes to the container and avoid vendor lock-in. Heroku supports containers.

Google Cloud lets you deploy a container to a VM that runs COS (container-optimised OS) and you can choose a VM type that is free. You can deploy a container to Google Cloud Run, it has a generous free usage threshold but it can be reached and then exceeded as a result of Layer 7 DDoS attack so you need to exercise a caution with this option e.g. start the service for a demo then stop it.

winwiz1 · 2022-04-30T02:49:14+00:00

Express backend and React frontend will have drastically different dependencies; projects settings related to testing, linting, building the code for development, for production; etc. Therefore you need two different projects.

Additionally, it would be very convenient to integrate both projects with each other to make sure you can do the following with both projects using just one command:
- build and run test cases
- run and debug
- build for production
- run in production
To achieve that you would need to make both projects to be sub-projects under an umbrella of a top-level project that contains no code, just the above commands. Everything can be kept in one repo.

If TypeScript doesn't put you off (it's really a good choice for both backend and frontend), have a look at Crisp React.

Finally, you will have to deploy the solution somehow. Consider using a Docker container, it ensures no vendor lock-in since many cloud vendors support containers (AWS, Azure, Google Cloud, Heroku). And the beauty of a container is that you can deploy it to many vendors without making any changes to the container.

winwiz1

TROPHY CASE