I need to ask you guys/gals out there about a concept of website development that I'm not finding a whole lot of documentation about. Maybe I'm using the wrong vocabulary? It's basicly rendering the views (in a MVC type sites) on the client side vs server side.
Here's what I know so far. Commonly in a Model, Controller, View type website, the view is what the HTML/CSS/Javascript design gets programmed to. Now the idea is that the server processes all the HTML/CSS/Javascript, and what gets sent to the client browser, is the finished view. I believe this applies to C#, MS.net, Java, PHP, as well as Rails.
Now, the way client-side works is, the server stops at trying to render views for HTML/CSS/Javascript, and instead only renders views for raw XML data. In addition, a Javascript like program (handlebars.js and mustache.js, eg) is downloaded once, cached, and the XML data is feed through the javascript program which in turn dynamically creates the HTML/CSS/Javascript view. The idea behind this is that only XML data, the initial JS program, and media are the only things needed from the server. Instead of refreshing the page each time, only XML or JSON data is needed.
Now, I can see an advantage for a small business that wishes to advertise, blogs, resellers, etc. 1. Minimize the amount of raw data that comes out of the company server, and 2. Send media and precompiled code to a cloud serving site like amazon.com.
But what if all information needs to be served from the company's servers? It seems to me that a number of arguments towards choosing client-side have already been addressed in Rails 3+
How can I find out more information about this so I can make a more knowledgeable decision as to choose client vs server?
All comments are welcome! Thanks (^_^)
Servers only touch PHP, Java, ASP.NET(C# and VB.NET), etc. JavaScript is a Client Side Code. the MVC Model is more for the Server side code on how you break it up. It tries to keep the logic away from the design. a good example of how this works would be Magento.
Also, client-side code is vulnerable to hackers
http://php-html.net/tutorials/model-view-controller-in-php/
Related
What is the architecture difference between working with razor vs blazor?
Documentation suggest that I have to write an Web Api when using blazor - is it still possible to pass model objects like in traditional razor ?
0 Video with visual explanation
I decided to make a video, since several questions about Blazor were asked (also on other forums) and this format seems much better for me to visualize the differences - instead of reding my (longer) explanation. The video contains a bit improved version, compared to my first post (the text post is also updated) It's one of my first videos in this format, so any feedback is welcome. If you prefer to read a classic text without much visualization, you'll find it's content in the following sections. Of course without the demos, which I made to lighten the content up, but the basic information content is the same.
1. What is a traditional multi-page site or application?
First you need to have a basic understanding how traditional websites/apps works: For every call/request, you send a request to the server and the server responds with the complete HTML of the entire page. This can be dynamically generated like with ASP.NET Core MVC and Razor templates or Razor Pages or even some other technique like PHP, Java, Python and so on. Let's say you have a list of articles showing a preview.
To illustrate this, let's say you have a list of articles (for example blog posts) showing a preview. When the user clicks on read all, you usually have two ways to realize this in traditional web apps:
Load a page like /view-article?id=123 where the above happens again: Loading the entire HTML DOM of the article page
Using JavaScript to make an Ajax-Request, which loads the desired content from an API like /api/get-article?id=123 and manipulate the DOM to display it at the desired position
Without JavaScript, traditional sites are not interactive. This means: After the page is loaded and rendered, nothing happens any more – except the user load another page (with the entire DOM) by clicking on a link – for that reason, it’s called „multi-page“ application.
You'll propably prefer the second approach, cause it's faster and saves ressources: Instead of rendering the entire page again (where only a part of it has changed), you stay on that page and just load the new information you need (the article content in this example). Especially on large pages with many ressources to load and render, the JavaScript approach feels much faster to the user.
If you like traditional pages to be interactive, you need JavaScript. For example you can add an ajax call to some API that displays some data when the user clicks a button, without having to reload the entire page.
In short we can say, that most of the work happens here on the server side.
2. Where is the difference to single-page applications (SPA)?
SPAs have just a single page, in terms of a full rendered html page. If you navigate there like by clicking on article, they load a JavaScript application. It handles everything interactive there. If the user clicks on an article, there is NO complete HTML document fetched from the server! Instead, it only fetches the parts who are changed, in this case the article. Everything else (e.g. navigation bar, footer, widgets etc) will remain - in opposite th multi-page apps, where this may be reloaded if no js/ajax is used.
You often have modulary components there and two-way data binding. This means, a variable is linked to some HTML element. When the variable changes, the element automatically displays the new value. In traditional apps, you'd have to create event handlers manually to handle this. It can be seen as continued development of a single page application with vanilla JavaScript, where you need more manual work to archive things like data-binding.
For the user, a SPA normally is much faster than navigating through pages on multi-page apps.
In short we can say, that most of the work happens here on the client side in the browser of the user. The server just serves static stuff (html, js, css) and provides APIs for e.g. fetching entries from the DB or save them.
3. What has Blazor to do with that?
A Blazor app actually is a SPA. But the main difference to other frameworks is, that Blazor lets you control both the client and server side with C# code. To show that benefit, let's look at other SPA frameworks like Angular: You can build an Angular SPA with ASP.NET Core. In this case, you write your client side in Angular with TypeScript. If you need to access data, it will make API calls to the ASP.NET Core server, which is C#. It will be similar with other frameworks like React, but here with JavaScript instead of TypeScript.
This make it hard to share code between those two: If you have an article model, it needs to be defined in C# on the server and in TypeScript on the client as well. With Blazor you just define it once in C# and re-use it on both sites. In other words: You just write C# without having to care about JavaScript*
*That’s the basic idea behind Blazor: Use C# everywhere, without the need for JavaScript as second technology. But it’s worth mentioning that you need to work with Blazor components to accomplish this. If you need some library not being ported to Blazor yet, you still have to handle a bit of JS. However, there are still benefits like the data binding. Using it on an entire plain JS stack would be some work, so I’d recommend to start with an UI library that offers Blazor components.
3.1 Blazor WebAssembly and Blazor Server
Now you know the basics and you need to decide between two flavours:
Blazor WebAssembly
As the name suggests, it basically uses WebAssembly to run your C# browser directly in the browser. It requires a relatively recent Browser and is not yet supported on all platforms/browsers. Also major engines like Chromium or Safari doesn't support all standardized features yet.
Let's say you have a button with C# code as handler like this:
<button class="btn btn-primary" #onclick="IncrementCount">Click me</button>
IncrementCount is a C# method. The code got transfered to the client and would be executed in the browser. Imagine it as .NET Core runtime inside the browser, like Silverlight BUT without any external plugins. There is no need to even have ASP.NET Core on the server-side! It can be served from any webserver, as long as you don't need things like DBs from the server side. This makes the app larger (and slower, at least on the first load).
The example Visual Studio template has a size of more than 17 Megabyte! With compression this can be reduced to 7 Megabyte – still a lot for a hello world application. By publishing the application in release mode, this goes down to about 7 MB and 2.4 MB with gzip.
At least subsequent requests are faster. Those DLL files are stored in the browser cache, which avoids further requests.
But it can be used offline (at least the main logic without API calls). For that reason, it's sometimes called real SPA – it’s compareable to Angular, React and other client-side frameworks.
Because of the WebAssembly-Usage, Debugging can be harder here, currently it just support Chromium based browsers.
Don’t know WebAssembly? It’s a relatively new, open standard that generates bytecode to improve loading and execution time to realize more powerfull web-applications – independent of the language. You’re not forced to use specific languages like JavaScript: Since Bytecode is generated, also other languages like C++ or Rust can be used.
In a nutshell, WebAssembly can be seen as next generation JavaScript for feature-rich webapps, where Blazor WebAssembly is the C# implementation. Because of the browser runtime, there are some APIs which can’t be used here. For example sockets or I/O access, like File.Open or File.Write.
Blazor Server
The app runs on the server and just transfers the output (like the result of a click event, that increases some counter in another HTML element) to the browser using SignalR Websockets. This makes the app smaller and faster, but requires more ressources on the server-side cause you have a SignalR connection and it's virtual DOM also on your server - making it harder to scale in large setups.
On the other side, this reduces the requirements on the clients: They don't need to support WASM, so it could run on older browsers or browsers with restricted WASM support as well as low-end devices. But since every action ends in a SignalR call, the app won't work offline - if this is a requirement, choose Blazor WebAssembly over Blazor Server.
What to choose?
It depends on your needs, as pointed out above. For example, if you need offline support, Blazor server wouldn't be a good choice. If you're unsure I'd prefer Blazor Server and only really worry about this if you're planning to deploy a very large application.
Imho, Blazor server is currently smoother and more flexible. Blazor Server also got stable before WebAssembly. This recommendation may changes in the future, when WebAssembly has developed further and got more widely supported.
But in this case, you can migrate later!
Both Blazor WebAssembly and Server use Razor components. This means: You can change between both, without re-writing your entire code. Some migration work is only required for things like data-calls outside the browser when migrating from Blazor Server to Blazor WebAssembly. The reason is, that Blazor WASM runs entirely in the browser, so you need a server part like an ASP.NET Core API projekt to handle them.
Further information
I recommend the Introduction to ASP.NET Core Blazor in the official documentation. Also the other chapter describing a lot of information about the platform and offers tutorials. They go deepter in detail to topics like data binding or event-handling to just name a few, and illustrating them with examples. I tried to kept it shorter here for a basic overview.
See also: Blazor WebAssembly 3.2.0 and ASP.NET Core 5
Looking at this question:
SO question
The accepted answer by Darin Dimitrov looks appealing (.NET 4.5 version). I am just wondering how this compares performance wise with client side solutions (e.g. using knockout/angular/jquery) to assemble the HTML given some JSON from the web api endpoint. Did someone ever do some perfromance tests on this. What are the pros and cons of the 'client side solution' vs the 'razor server side' solution?
You should have to define performance.
However there is a very big difference between the two options:
if you do it client-side (with ko/ng/jQuery) the server only executes the API controller action and returns the formatted data.
if you do it server side, apart from execution the API action, the server has to execute the MVC controller action, so, undoubtedly, the server does more work.
The only conclusion is that the server has less work to do in the first case. And, usually, the network traffic is reduced (a JSON object is usually lighter than a rendered partial view).
If we're speaking about the user experience, in general client side technologies (jQuery, ko, ng) offer a much better user experience becasue the page is much more responsive: it's easy to show/hide elements, set the focus, make trivial calculations, remote validations... And if we use modern libraries, we can go further on improving the interface resposiveness. For example breeze.js allows to cache data in the client side to avoid making extra ajax calls to the server, giving a much more responsive experience, specially if you anticipate what data can be needed and cached it before hand. You could even persist data in HTML5 storage, so that it's available for other sessions.
Then, from the user viewpoint, I think it's much better the second option. And the server has less work to do, which can make it also more resposive in high-traffic sites.
Even so, I don't know what is "more performant" or even what it is "to be performant".
Whatever it is, using client side technologies is a much better option. But it takes some time to master the associated technologies.
I'm creating a PoC of an ASP.NET MVC 4 mobile application (tablets) for field operators that needs to support offline capabilities. It's a relatively simple data entry application with a WebAPI backend that will use a SQL database as persistent storage.
This is the first time I'll be implementing offline support, so I'm a bit unsure of which is the best way to design this. Right now I can think of two ways, and not sure which one is better or more correct.
What I want is that whenever there is internet connectivity, the information is retrieved from the server. If the connection is lost, I want the latest information to be cached/served and available to display to the user.
Based on a few tests that I've made, the way the HTML5 offline support appears to work is that as soon as any of the Views is loaded, the browser will check the manifest and cache the version of each page at that moment of time. If my understanding is correct, that means that if the user adds new entries after the browser downloaded the manifest files, then those records would not show in the offline version.
One way I can think to work around that is to change the manifest version (since I'm generating it dynamically) every time it is served, but i feel that would defeat the purpose..or at least be incredibly inefficient bandwidth-wise.
The only other alternative that I can think of is not using regular MVC (not passing the records/db information as the model property or a ViewBag property) to display the records, but just retrieve the json for the page information needed and save in local storage. Then, generate the view using a template or javascript based on the information in localstorage. That would work either online or offline, wouldn't it?
I'm not sure if I'm approaching this the wrong way. Would building an SPA or a simple HTML/javascript application be more appropiate? Maybe using a JS framework? At this point I have some ability to determine what technology or framework we'd use.
Any guidance is greatly appreciated.
Based on a few tests that I've made, the way the HTML5 offline support appears to work is that as soon as any of the Views is loaded, the browser will check the manifest and cache the version of each page at that moment of time. If my understanding is correct, that means that if the user adds new entries after the browser downloaded the manifest files, then those records would not show in the offline version.
This is why you shouldn't use server side rendering. When the server mixes data with formatting before sending to the browser it means that the browser can't tell the difference between the two. HTML5 and Javascript are perfectly capable of handling templating on their own so why not let them?
Write your MVC application as nothing but a series of controller methods. Do not use "views" per-say. Instead use straight HTML files that use javascript to make AJAX requests to the server for data. Populate the HTML view with the data and you're golden. Then you can cache the HTML files because they're static and you can save the data separately for offline mode.
Adding to the accepted answer, there's a thorough post in this matter titled:
Build an HTML5 Offline Application with Application Cache, Web Storage and ASP.NET MVC.
The guy explains everything using a sample/complete app and do a great job explaining each and every point.
Besides that, if you really want to get the crème de la crème from modern web dev with offline capabilities, I'd suggest you take the 2 parts course by extraordinaire/star developer John Papa. It uses the SPA = Single Page Application UI paradigm.
The course is available at Pluralsight:
Building Apps with Angular and Breeze - Part 1
Building Apps with Angular and Breeze - Part 2
Enjoy as much as I'm enjoying it. Make sure you check this keyword/feature in the course: WIP = Work In Progress.
If you're interested, here's is a repo where I keep the updated course's code:
https://github.com/leniel/SPACodeCamper
I was wondering this for quite a while and haven't really found an answer for this yet.
Why would you use Backbone.js exaclty inside a Rails application? Is it to extend functionality, have a more MVC pattern for your JS, build better API's...?
At the moment I can't see a reason why you would want to use it for something, because I don't think I understand the concept of Backbone.js
The big advantage of rails is that you have one platform and one language that you use that will handle the server-code and can generate the client-code (using the views).
Undoubtedly this theoretical advantage quickly starts slipping once you want to improve your user-experience with javascript and jquery. So actually you still have to learn two languages.
But still: all your models, business-rules, ... is handled on the server-side in Ruby. This also means that the server always has to be reachable.
What a javacript/client MVC (like Backbone.js, Sproutcore, ...) can offer you is a more native application feel. A single web-page application, like e.g. Gmail.
Depending on your requirements there are some very valid use-cases for such a platform. E.g. in places or devices with low connectivity it could be very useful (with HTML5) to have a web-application that does not need to be "online" all the time. It could save data and edits to the local storage and sync back to the server/database when the device is back online.
But, there is a big disadvantage when developing client MVC applications in combination with Rails: you will have to do some double development (it is the same when you are using flex/silverlight). Your models will need to be defined both on the server and on the client. I can imagine that some improvements could be made, like on the client MVC you are actually using presenter-classes, which on the server-side could be stored in different models/tables. But still there will be duplication of logic, models, ...
So that's why I think that for most applications, at the moment, it is not wise to switch to some client MVC framework. It will be a lot more work.
But when you do need the look and feel of a real native application, or a one-page-web application, then a javascript client MVC framework is the way to go. And if you do need a client MVC framework, I would propose Sproutcore.
To simply ajaxify your current rails application (reduces load-time of every single page), take a look at pjax-rails.
(better late than never - hope this is useful to someone)
The description on backbonejs's website seems like a lot of words thrown together without much meaning. There is a big hype around it but what's all the fuss about?
The premise behind backbone is that modern day, single page web apps (think gmail) quickly become a very complex interaction between syncing dom elements, UI events and the backend. You could easily find yourself storing data within the dom elements, and then having to somehow extract the data again to update the database. If you don't structure your code very carefully, you'll quickly end up with spaghetti code full of complex bindings, or code without backbone.
Using backbone's models, collections and views gives you a well thought out structure to work within, allowing you to build large apps without being overwhelmed by their complexity. What's more, it ties in beautifully with a restful backend.
Isotope lets you write templates in javascript. These templates can then be rendered by either the client (using plain-old javascript) or on the server (using Johnson).
The benefit is DRYer code. When updating the DOM on an ajax or web socket update, you can don't have to write a new partial...just point it to the one you already wrote.
Has anyone used this?
Interesting, I would have to try it, however , and I know not a lot of people do it, but I actually use HAML to template .js files. Although there is still that problem the author mentions , of each request being templated on the server and sending back html, unless you are sending loads of kb, or you have really, really high load site I don't think it's such a big deal.
Also ideally you shouldn't be even sending html data back and force, just JSON objects, which are rendered on the page by your ajax request. The only legitimate use I can see for this is if you have heavily ajax website, such as where you load a page once, and the you just keeping doing ajax requests for all interaction and javascript to manipulate view.
So it would help if you would clarify the final goal. Is this for some internal app where you control user environment ( you know for sure which browsers they will use, and that they will have fast enough computers to manipulate all this javascript?) Or is it going to be an app targeted towards 3rd world, where people don't have yet resources available to use all that fancy javascript.
All that said, it's an interesting concept, and I will try it our myself, to see how well it works.
This uses Johnson, which last I checked did not work on Ruby 1.9. So that might hint at some of the immaturity of this particular solution. Eventually the community will come up with something that works really well.
One approach I have used is to make 2 completely separate templates, but try to make them as similar as possible so that it is easy to port changes from one to the other.
This seems like a bad idea. In an Ajax application, I believe that the server should be responsible for rendering all display text. This makes i18n easier, and concentrates everything in one place. The JavaScript should simply receive data from the server, with all display text already rendered, and put it in the appropriate DOM object.
In other words, I believe that in an Ajax application, the need for a JS template engine is itself a design smell.
The situation is different in exclusively client-side JS applications, of course.