That said, I find server-side rendering to be more difficult when faced with the problem of creating the type of UI that people want these days. Generally I like the server to just be an API that a Javascript client talks to, because unless you want no dynamic/asynchronous features you're going to have to write that anyway. Now you're maintaining two apps, which is twice as much work. Sometimes it's necessary to do that, sometimes it's not... I always aim for only writing one UI, because it's like twice as fast as writing two. But no doubt people will reply to me saying they browse with Javascript disabled to get an extra 15 minutes of battery life out of their laptop, so there's that.
Now, I may not be the target audience for your app, and that's fine, but it's unfair to dismiss people browsing without JS for strawman reasons.
Adblockers generally do two things: block specific domains and change the rendering of certain elements.
Browsing with JS disabled handles things like stopping certain kinds of code -- even loaded from the primary domain -- from running.
Layered defense usually works better than a single method, and advertisers, privacy violators, etc have shown a willingness to enter a full on arms race. So I responded in similar measure.
The honest truth is I just don't want to do business with most people trying to run code on my computer, so if that's a sticking point for them on using their product, I just don't use it.
Check out https://github.com/StevenBlack/hosts
If I'm expecting some kind of webapp then I'm fine with whitelisting your domain, though if you're basically just a content just I usually just browse away.
I confess I don't really understand your point though: In what sense would you be maintaining two apps? Aren't you ultimately maintaining exactly the same amount of code, if not more, the case just being that yours isn't as tightly coupled across a network?
I browse with Javascript turned off because it cripples ads and reduces memory usage of my browser significantly.
I don't care what you think is necessary to serve a page of information. It almost certainly isn't. You have to earn the right to have javascript enabled or I'll just click away.
My two cents (to the OP) is that you should consider the people or teams building the thing. If you have one team doing all frontend and backend, doing it (almost) all server side makes sense. If you have a dedicated person doing the frontend, commit to a js framework and make a good API to the backend. Certainly don't make a frontend JS guru render html in Java or .NET.
It has the added side benefit of being a quality filter: if the site won't load properly or fallback gracefully without JavaScript enabled then it probably isn't worth my time.
For example, I work on a large, enterprise webapp, it has the frontend UI, which users interact with heavily: this, we have built out using clientside Javascript which interacts with the Rails backend via an API.
However, we also have an admin area -- many of those pages are used very rarely and are quite complicated. I initiated a change to build these panels using traditional server-side rendered ERB views. In the context of our codebase, it takes less code and it's easier to iterate on these without bothering with the Javascript framework.
In other cases, like my personal blog, I use Jekyll to generate a bunch of static HTML and, essentially cache all this on Github pages.
Javascript frameworks are amazing and can provide a much richer, much better experience. But, I don't necessarily think they're appropriate for all problems. One other big reason why, it just the inherent "experimental-ness" and, the churn / quick obsolescence you may find in this area. Some problems don't need to be re-solved every year or two. :)
I think this is the point worth inspecting if you're considering server side rendering. If you're making a page that just displays content, I don't see any reason to throw Javascript in front of it. Just render your HTML and send it. If you want to make changes to the content dynamically, if it's going to take super long to load and you want to show users a loading screen, if they can interact with the content, etc, that may be a case to throw Javascript into the equation.
I was travelling with 2G and using most client side apps was near impossible. One app sent down a 1.9MB `components.js` file, and because it was a JS app, all scripts had to be loaded until anything rendered.
Obviously server-side apps are in no way immune from this, but by default, unless you really do need a rich client experience, it's often not worth the bundle size and CPU load. Just send down HTML.
You know which website works fabulously over 2G? Hacker News.
That said, this is not the direction the industry is moving in. Sadly.
Razor views in ASP.NET Core are really nice (disclaimer, I wrote a book on this so I'm obviously biased). However, if you are making a Single Page App then you will need to stick to HTTP APIs (returning JSON, not HTML). The controllers in Core can easily do both now that MVC 6 and Web API 2 are merged and the same thing.
The only exception to this is for an initial rendering of your app server-side, so that the browser gets populated HTML on the first load and there is something to see immediately. For example, using ReactJS.NET you can load the same model into your Razor view that you return from your API and pre-render it using view helpers.
If you're interested then I wrote more about this today: https://unop.uk/react-and-asp-net-core/
P.S. Has this whole thread been hidden or flagged?
That being said, server-side rendering will continue to be a great fit for cases where you ingest data and produce a deterministic, non-interactive (or not-too-interactive) result.
Remember, the issue is that in AJAX you'd receive some async result from the server and would have to splice it into the DOM, so you're throwing these contextless snippets of data on the wire and relying on your client-side JS to do the right thing; all the while you have an entire different server-side application spitting out complete well-formed HTML documents.
In a modern, virtual-domming JS MV* framework, these two functions become the same, and you don't have to architect two different solutions.
Make SSR Great Again - "Swinging the pendulum back to server-side rendering"
https://www.evernote.com/shard/s17/sh/08a3fdd5-7ff7-40ea-b2d...
"- https2 server push is anti-pattern. Doesn’t consult browser cache."
This is an odd claim, as server push is built to respect the browser cache and can even be used to populate it. In usual cases the server can know whether to push the dependencies of a requested resource based on the ETag header, working under the true-enough assumption that if a resource is in cache, its dependencies are also likely to be.
I can think of a thornier case where two resources have a shared dependency, and the server pro-actively pushes the shared dependency in response to a request for the second resource, oblivious to the fact that it's already in cache from a request for the first resource. I don't believe this case is enough to call server push an anti-pattern, though: the browser can cancel the push midstream if it already has it in cache. Although the server probably has already sent all of the dependency at that point.
Used appropriately, server push interacts nicely with caching and can even improve cacheability: I think servers can push 304 responses, for instance.
Currently, I'd opt for using either an existing CMS like Wordpress or Shopify, depending on the needs, with a layer of React.js on top of it. Or a full stack React.js + Node.js custom build.
You'll find plenty of resources saying Google can index JS SPAs but regardless of what you think about that, the no JS user should not be left out in the cold.
If you're building an internal application where you can dictate the browser support I've actually found that I'm fastest completing projects building a JSON API with an Angular.js front end. React.js would work just as well of course, just depends on what you are more comfortable with.
Lastly, PageSpeed. Some clients don't care about this, but some do. If you're deciding on a stack, try running your build through Google PageSpeed Insight once in a while during the early stages to make sure you're not getting any road blocking red flags.
I personally don't care much for PageSpeed's reports, I have found them to be buggy or bizarre at times. But having your client rip your masterpiece apart just because they hired a marketer that's blaming all their shortcomings on a less than perfect PageSpeed score isn't fun.
I hope that helps! Let me know if you have any questions. I would be happy to clarify or elaborate.
Maybe some people just don't care about this, and pure JavaScript works for them.
But then you need validations, and server-side checks for availability, then dynamic forms based on previous input choices, and data synching to preview the profile on the right, and then - might as well use React or similar instead of jQuery with DOM manipulation.
I'm working at a EMS company. Most of your web tools are developed with ASP.NET WebForms. New projects are developed with MVC or Web API but it is always more overhead than WebForms. You have to configure/develop more to get the same result at the end.
No, it's not! But it's discouraged to use it as the only rendering layer.
Server side rendering has its unbeatable advantages - speed. That's why you can view content on https://huu.la within second, similar methods are used by Google, Twitter, etc. A lot of people might say, we have faster networks now. Believe me, even at Bay Area, it takes time to, first, download your powerful client-side library, second, bootstrap your powerful client-side app, and third, call XHRs to fetch your data. Not to mention there are so many mobiles, with even less capable networks.
So from my experience developing Huula, I would recommend using a combined approach. For places where speed is critical, for example your landing page, help page, use server side rendering; for places where a lot of user interactions will happen, use client-side rendering since it gives your more support for componentization if that's a word and user interactions.
If you render your pages and snippets on the server, a small amount of JS on the client can hotswap content. In the extreme of this idea, you get turbolinks from Rails where no real pageloads happen, but pages are rendered on the server.
But in the small, it can let you do a sprinkling of async calls where they make the most sense, and still keep all rendering of responses on the server.
Thoughtbot wrote about it recently:
https://robots.thoughtbot.com/how-we-replaced-react-with-pho...
So unless you're making a community/social network for developers and the picky type are somehow your primary audience, it doesn't matter what you pick to code your site in or how its rendered.
The average Joe doesn't care whether it's something purely server side (like old school Perl) or React.
If you are building a web application that is behind login or you just don't care about SEO then ... No, you don't need server-side rendering.
If you are building a website with JavaScript functionality for making it easier for the user, then you probably want a JS-free version, so yeah, better do some server-side rendering and use JS as a progressive enhancement.
Here's a good example: https://github.com/erikras/react-redux-universal-hot-example
Are you building an app for a doctor's office with low-tech ability users and low tech-level expectations, but extremely high reliability and speed expectations?
Or are you building a dating app for millennials who are going to expect the app to be shiny & cool?
As usual, the intended users' needs will inform your decision.
That said, use whatever solves your needs/requirements/etc. in a timely fashion. Literally nothing else matters.
Personally, I would default to server side rendering unless there's a very good reason to be rendering on the client instead (and there often is).