Currently the webdev world is in a kind of flux. The "FE Way", as some would call it, involves some mix of libraries like angular and vue for things like browser based routing (using hashes) and creating an MVC, plus some other libraries like react, material-ui, prime-ng, etc for handling the views. The backend is just a REST API and free to be implemented in any language you want.
The "BE Way", on the other hand, involves some old (but still proven and stable) libraries like jquery, bootstrap, etc. coupled with a backend language like php or python for handling web requests and HTML templating.
Which of these two ways is your preference and why?
The fe-way appears cool because you've separated your backend logic entirely into a REST API, now it doesn't matter whether its python or php, django or laravel. In a sense, its future-proof, isn't it?
Yet, I don't see many people moving to the fe-way, they are still using laravel, django, flask, etc., so what's holding them back still in the be-way? Is it just fear of the unknown or are there any genuine concerns with doing things in fe-way? Some basic issues I can think of are browser incompatibilities, lack of a robust and stable framework (angulars & vues keep coming and going, or keep reinventing themselves), npm problem of too many packages, etc.
If these issues were resolved, I don't think there'll be any major bottleneck for moving towards the fe-way.
Top comments (12)
I believe there are more options than that. Building a server side rendered app doesn't mean you're "stuck" with jQuery and Bootstrap. You can use any of the modern solutions, be them the mainstream frameworks or tools like Stimulus or Svelte and whatever CSS frameworks you're into.
The main reason to do a SPA, aside from riding trends, is the offline capabilities it gives you.
Building a server side rendered app also doesn't mean you can't have a REST or GraphQL API.
What you call "future proofing" I call "premature optimization" and "complexity brought along by trends". Do you really need a SPA? If the answer is yes, then do it. Otherwise you're perfectly fine without it and your architecture will be simpler to handle.
Reminds me of the microservices vs monolith debate. People saying "well, if you split your app in 10 microservices you can scale them independently". Sure, but you also introduce 10 new problems. Do you need microservices? If yes, go for them, but they are not a better solution in all cases, the same with SPAs. They are great but they have their sets of issues, same for the other options.
I disagree with the equivalence between "old school web apps" and "being held back" nor that we have to move to use SPAs all the time.
They are an alternative, not a replacement or "the better way".
Insert thank you gif!
There is no default, and it will never be. Simply because SPA is not better than multipage apps, also vise versa. They are two different software approaches and both will live along side each other.
I completely disagree that every app should be a SPA, and I don't like that people are forcing this so much in 2019. In most cases new developers go for SPA because its "cool and new".
Cool, appreciate your views. I understand that both approaches are unique and different, I was just pointing out the advantages of SPA vis-a-vis backend centric apps. The most prominent advantage is that you are simply being future proof with a REST API backend - you can tear apart your flask/code-igniter and replace it with django/laravel tomorrow with zero impact to your front-end! You can't do that with backend centric app.
Another advantage is less server load. As you move more business logic to the user's browser than your own, your server will be lighter and thus equipped to handle more requests instead of wasting RAM or CPU cycles.
I understand your point that some apps could be non-SPA but I don't get the reasoning for it. Why should you still put up with backend-centric apps when even android browsers have support for ES6 these days?
About the server load, what you see as an advantage I see as a downside. The average phone price in the US is 200$, can that phone handle a 1000 rows of table manipulation? This is my problem with SPAs the most people don't get the price of JS. Don't get me wrong I am a JS developer, but I specialize on performance. What most people don't get is 500kb of images are not the same as 500kb of JS.
And the most common problem is SEO and analytics tracking. I implemented all the possible solution that exist by this days and either they make my team want to kill themselves because of the development complexities or they can bring same results as MPA.
Note: I don't hate SPA, on the contrary we use them but for a specific case where it makes sense like dashboards or apps like github. There is no advantage of using a SPA for a presentation, company or in most cases Saas sites
Totally get your point! The way I envisage things, the manipulation of rows will still happen on the backend itself through SQL queries (or nosql equivalent in case of mongodb, etc.). Where front-end can play a part is things like url routing and DOM rendering. Right now, these roles are also played by backend with frameworks like flask/laravel and template engines like jinja2/twig. Aren't you better off by moving all that logic to the client browser instead?
Nowadays I'll go with static MPA generated with SSR Framework like Nuxt and Sapper. Or just go with the newer kid JAMstack. Cheap like SPA but faster for the first paint than SPA and if I went with plain SSR. Implementing auth in static sites will be a problem, tho.
It seems you are referring to the issue more on the conceptual level which is fine but is limited if you don't have exposure toward the real world scenarios, which are many than the above cases. One is that nowadays you can use JAMStack with static site generators like Gatsby and have a web app transition between paradigms, if you would call them so, start as static assets or sites and transition later on into SPA. You can use server side and client side rendering together and combine both benefits.
The trend seen so far is into the JAMStack + SSGs + GraphQL + Apollo etc. Rather than focusing on the this versus this there is another level of application that is much more efficient and effective.
Thanks, appreciate your views! Yep, I was talking on the conceptual level, I know a lot of other permutations and combinations are possible too, especially these days.
JAMStack is good but you still need something on server side to handle the GET/POST/PUT requests, right? Its immaterial whether I use Gatsby, Jekyll, Pelican or even create a custom one for my own app, the fact that whether or not the front-end is separated from back-end (which rules out server side templates using twig, jinja, etc.) is the main discussion point at the conceptual level.
I know about all these trends, except SSG. Never heard of that, are you referring to SSG Solutions Pvt. Ltd.?
You use graphQL which is far better than rest api. SSG is static site generators.
Some thoughts I have about this topic:
The server has the advantage of being under your control. The more computation you move to the client, the less certain the environment your software runs on becomes.
You can go pretty far with server-side-rendering in terms of snappy and performant sites. If you build a shop and want instant cart-updates and the like, you can use approaches like turbolinks/PJAX/Phoenix Live-View.
If you have a "normal" site, but there is one page with real-time-updates and state-heavy things, you can insert React/Vue/… into that page only. No need to go full SPA.
If you're building actual apps, like photo-editors; jira-like-tools; games; audio/video-platforms; e-mail-clients; chat-tools; analytics-tools etc., then I wouldn't think twice and pick whatever SPA-framework you and your team are most comfortable with.
If you have all of those concentrated in one huge app and multiple teams, you could make multiple front-ends, and switch between them via subdomains (vulg. "micro-frontends", DAZN does it this way)
Thanks, appreciate your views! The client-side environment is a very dynamic thing right now. Its true that the client-side is fragmented but there has been an extreme push for standardization (ES6, et al.) and upgrades of browsers even on low-end android browsers.
On the server side, the most important determinant is perhaps cost which seems to be going against the Moore's law right now! Since the last decade or so, the prices of storage, memory and processors seem to be going up rather than down (or at least not going down in proportion to the Moore's law). If this trend continues, server-side processing will become even more costlier and SPA will rule the future (let the client browsers handle the costly memory and processing stuff!).
Right now, server side processing on AWS/Digital Ocean is seemingly affordable but when it comes to scaling, only the large MNCs like Google, Facebook, Twitter, etc. can do that, not the plebeians like us. The only way for us to scale is to move as much logic to client side as possible. My understanding is that even DEV.to is primarily a client side app?