There is a lot of beauty in a simple HTML + CSS application with a sprinkle of Javascript mixed in.
I'll cover some points I like about this syste...
For further actions, you may consider blocking this person and/or reporting abuse
It certainly depends what you're doing with it. When I'm building something small I never want to go through the effort of setting up something like Vue or React, as in small projects I think the downsides often outweigh the ups.
That being said, I have 2 big reasons I like them. One is they keep the frontend and the backend separate which is nice sometimes. Especially in big projects, I prefer to keep the clients separate from the server-side. It also means if I have someone helping me who is not familiar with the backend languages/services, they can still easily work on the frontend, requiring nothing more than API documentation.
The other reason is in a lot of my projects I like providing an API that is accessible from mobile apps, discord bots, etc. If I build something serverside rendered it often means I then need to build API endpoints separately to provide the same services. If my whole backend is an API from the start, it makes it easier to stick any number of clients on top of it, whether they be mobile, web or other services.
Really depends on what you're doing. I wouldn't use them for small projects or anything where an API is generally unnecessary. But certainly useful for very large projects or anything where you're going to have a lot of clients attached to the one backend service.
Well i think you have good points. I agree on the having APIs part but i usually do server side rendering and it just consumes the APIs.
And working with other people isn't hard because at least for me. I use ejs. So the templates are pure js as well. And the frontend people can do whatever they like as long as the server can return it.
Would you have a separate serverside project that consumes the API or just abstract it in such a way that the SSR and the API endpoints call the same services in your code?
Usually, when I think of SSR I think of templating (An example is my personal site, written with ASP.net Core and Razor templating. No API's are present there and the front-end is part of the back-end code in that it uses ASP's templating engine).
Just curious how you would usually go about it!
So what we currently do is yeah if I want to get all the documents I have a model for the documents API uses at
GET /documents/{id}uses and the view uses.The views are ejs templates. The frontend is part of the backend code but the way its set up it's in its own folder and has its own build process with parceljs.
So it's a big ol monorepo basically.
I fixed SSR pages for you:
:D
But seriously, the benefit from SPAs is not speed but the amount of downloaded data. About 95% of your page can be cached and reused, the JS will only download a small piece of data to check for possible updates, and update the dynamic content of your page.
And I do get the benefits but I just think SPAs are heavy especially on inital load. Plus A JSON payload isn't that much smaller than just sending the HTML page of it. We also use turbolinks so we still get the caching etc. Of the page while sending back pure HTML.
And I think whatever you gain in "speed" you can lose in productivity. I think SPAs are actually really great for large teams as well. Where you have a frontend team and backend team and they don't have to collab at all.
But when you are just a single developer or just a few having SSR apps can save you a lot of time.
I guess if you want to replace entire page content, and you've got to download it from the server then sure, you'll have to download a lot of data (about 80% - 90% if your entire page) because the actual content is what weights the most. Devdocs does a very good job at saving downloaded pages in IndexedDB for later access.
When it comes to productivity, I guess it comes to everyone's individual experience with them. I actually found SPAs faster to make than SSRs, but then again, I REALLY enjoy making websites in React, so my point of view might be a little biased.
SPAs maintain state of Html Page, SSR unnecessary cause entire page to reload and user feels lost as many things on page changes, especially the scroll position !! And SPA is called (Single Page Application) the word Application implies it is for an active application where user interacts and performs an activity. SSR is only useful for SEO and applications don't need SEO because most applications will always require an authenticated session.
Well that's what turbolinks is for. Loads the entire webpage in the background and merges it with the current one. I don't see your point about many things on the page changing. If I go to a new page isn't that expected? And shouldn't the scroll position go to the top of a new page? Plus a pretty big web app, GitHub, uses many of the techniques I'm talking about.