I've been diving into Razor Pages, but also have a need to create PWA apps. Everything I see about PWAs are related to Blazor. Can a web application created with Razor Pages be converted to a PWA?
As I know, C# Razor Framework is a Server Rendering framework(SSR), so in any request from browser to server, html is returned. This feature is the opposite of PWA (Client side rendering (CSR)), in which just the first request from browser to server returns html. Consecutive request are performed to the related rest-api or microservice which returns only json
So, in Razor, if you manage to avoid html creation at server layer (which is the core of server rendering frameworks) and perform the forms creation and other UI tasks with pure javascript (like react, angular, vue, etc) instead Razor features, you could convert it to a pwa, adding the classic manifest, service-worker and other required files for a basic pwa application.
If you choose that, you could ask this to your self: Why I'm using a backend (c#) framework just to generate a minimal index.html instead of using the powerful Razor features?
Maybe it is time to move from classic web server frameworks which use server languages (c#, java, python, ruby, etc) to latest javascript frameworks like : react, angular, vue, aurelia, linkstart, etc
Check this resources:
Server Rendering vs Client side Rendering
Related
I know that astro js like a server that can use multiple front-end frameworks such as : react,...., but is astro.js need back-end framework ?
can anyone answer me
No, you don't need a backend framework to run Astro. Basically, for simple projects you don't even have to choose a front-end framework as well, and just use built-in functionality, there is a lot to choose from.
From the docs:
Astro is an all-in-one web framework that comes with everything you need to build a website.
Astro includes a component syntax, file-based routing, asset handling, a build process, bundling, optimizations, data-fetching, and more. You can build great websites without ever reaching outside of Astro’s core feature set.
If you need more control, you can extend Astro with over 100+ integrations like React, Svelte, Vue, Tailwind CSS, MDX, image optimizations, and more. Connect your favorite CMS or deploy to your favorite host with just a single command.
I've done almost all of my web projects using Java(Spring MVC + Thymeleaf) and it's MVC technologies. Recently I've heared about REST and started learning some stuff about it. I realized that it is one of the coolest things I've ever seen in my whole life!(I'm just joking around, it's definitely not)
All we need is just to parse data to json type and then return it to the frontend. And in frontend we no longer need to use Model and it's objects. Frontend can get all required data in nice-to-work-with json type using one single GET request!
We don't need to use some weird Thymeleaf constructions to handle errors or to iterate through the list in our template! We can handle all events and process all data using javascript and it's frameworks. It is much more powerful.
Does there exist something I missed? When to use Model? When to use json-type data?
These are two (somewhat overlapping) approaches to frontend development: generating pages on the backend and on the frontend.
Using a backend model and Thymeleaf templates (or any other HTML templates), you generate your web page on the server side. This means the following benefits
you can write frontend and backend logic in one language (Java);
you can enforce data and security constraints in one place - on the backend, using Java code or configuration;
in many cases, it's faster for the user to get their first page, since the rendering happens on the server, and the user gets an already rendered page;
But this approach has the following drawbacks:
the server has to render the pages, which means more load on the server;
most of the modern web sites and applications use JavaScript anyway, so you'll have to write at least some JavaScript;
server-generated pages don't even come close to what's possible to render in the browser.
Providing a REST API for a JavaScript frontend, you have the following benefits:
you unload your server, since most of the UI related work happens on the user's device;
you can achieve much more with modern frontend frameworks;
navigating on an already rendered UI is faster, since you don't need for the server to render every page, you only need to get a relatively small JSON response and then update the page dynamically.
But this approach has the following tradeoffs:
the user generally waits longer to see their first page, as the browser needs to download a lot of scripts and then spend time on dynamic rendering of the page;
in a large application, you need to either have a full-stack developer team, or two teams working on frontend and backend separately;
you have to write your UI logic in JavaScript. Make of it what you will :)
you have to sometimes duplicate the constraints both on the frontend and on the backend: e.g., if a user can't edit a field, you have to both show it as read-only on the frontend, and add validation in your REST service, since the user may try to access your REST API directly and bypass the frontend validation;
you have to be more aware of securing your REST API in general.
I am new to REST and watched few videos and read few blogs on REST webservice and I came to know that generally people are using REST for supporting multiple devices like mobile and computer etc.
Now consider I am developing order management system and I want to support both computer as well as tablets. If in m traditional web application, I am using Spring MVC at front end, how REST will fit here so that it will support both the kind of devices.
One more doubt is, whatever examples I have browsed, it return html or json data. I want to develop the application the way spring MVC or struts works like returning name of jsp and jsp will be rendered with dynamic data (instead of returning string represented html).
I hope my question is clear. Please bear me as my questions are vague but I am looking from implementation and design point of view.
Just to start REST isn't anything to do with supporting mobile browsers. It is the architecture pattern HTTP follows. The Web had been REST since the early days.
I'm guessing what you mean is a server that returns light weight JSON that the client renders into HTML rather than the server returning HTML directly to browser. To do that you can use a java script framework that expects JSON data and that has a template engine to generate HTML on the fly in the browser. I think Anglar and Ember work like this.
Though I would only do this if you need to, and you don't need to do this just to support mobile browsers, you can support mobile just by making sure your CSS is responsive.
have anyone come across a complete GWT app with registration/sign-up page to start with--unlike with PHP. Until now I haven't find such app that have the ability to register user, have the user a 'user page' and so on. With integration to MySQL and other db to persist user data. Does anyone know such code to start with.
A GWT app is quite useless without an appropriate backend (Java, PHP, Python, etc).
In the end GWT code is only compiled to client-side javascript code. With client-side javascript you can't access any database on the server and thus any GWT app also requires a backend in order to access a database like MySQL.
So in order to create a registration/sign-up app you have to write both backend and frontend code.
For the frontend and the UI respectively you can use GWT. For the backend you can use any server side technology. The tightest integration with GWT can be achieved with a Java backend but you can also use non-java backends like PHP, Ruby, Python, etc.
GWT will communicate either via RPC/RequestFactory (Java) or RequestBuilder (non-java backends). Fore more information refer to the GWT docs.
So I recommend following steps:
Decide which backend technology you are going to use. Java offers the tightest integration (RPC,RequestFactory, etc). However for small/simple apps sometimes it is easier to use non-java backends like Python or PHP because they can be setup/implemented faster/easier.
Implement the business logic on the server-side. In your case this includes among others "adding new users to the database", "signing up users", "retrieving user information", etc
Design and implement the UI with GWT. In your case this will be the user-page and the form to fill in details for signing up, etc.
Write the communication part between frontend and backend in GWT using RequestFactory/RPC (Java) or RequestBuilder (non-Java)
What kind of application are you going to develop? If your project is a public website and you plan to run it on GAE, you could use Google App Engine User Service.
http://code.google.com/appengine/docs/java/users/
For enterprise apps this is probably not a valid option...
I want to develop a Web Application by combining Spring Framework, GWT, Servlets, JSP........
I plan to develop Server side using Spring,Servlet ,JSP....
And for Client side, GWT....
The Output page(Response page) of my Application, will given by JSP only....
Then what is the use of GWT at client side....
please clear my doubt....
Read the following
1) AJAX - http://en.wikipedia.org/wiki/Ajax_(programming)
2) RIA - http://en.wikipedia.org/wiki/Rich_Internet_application
3) GWT - http://en.wikipedia.org/wiki/Google_Web_Toolkit
The problem with using purely jsp to create a web application is that each user interaction typically requires the entire page to be reloaded. Depending on what you're doing this approach is considered outdated. GWT is built on top of javascript and xhttp requests, allowing user interactions to affect only relevant portions of the page. This generally results in a faster and smoother user experience.
If you have already decided that you want to use JSP, then you don't need GWT. Although you could use it to create custom dynamic components and embed them on your page. Or to create a part of your application where you find JSP not sufficient (which would be probably a part that should be more 'dynamic' and would require a lot of javascript).
http://code.google.com/webtoolkit/overview.html#how