Because all Angular & React does similar type of templating behind the scene. So why use ejs..? Is that for project that do not use Angular/React and alike.?
React and Angular are tools initially built to create Client Side applications or Single Page Applications. This means that the client receives a single HTML file and one or more JS files that contain the app's code. All of the HTML that you then see generated in the website is actually built in the client (AKA the user's browser).
We now see both React and Angular being used for aplications that have their HTML built in the backend, either in run time (Server Side Rendering) or on build time (technically also Server Side Rendering but usually referred to as Static Site Generation, see Gatsby for an example).
EJS is a simpler tool, it basically just gets an HTML file (with the .ejs termination) and some placeholders {{data}}, and fills these with anything that we might want to use. What basically happens when you generate an HTML page to send to the client when using EJS is something along these lines:
index.ejs -> (In Node) Pass object with data values for placeholders -> Replace placeholders with actual values -> Output finished HTML file with value instead of placeholders
Notice that there is no special logic, state or any other complexity that you may find in a React or Angular application. It is a templating engine, it just does what was described in my snippet.
Related
I'm an android developer and about two years and recently I've been thinking about building web applications. So I started researching about spring boot and everything is great. Then, I came across this thing called template engines (thymeleaf) which by definition separate your code from presentation.
What is confusing me is how can a backend server have html? should the presentation be handled by html, css and javascript in the front end? I even saw tutorials where they actually type in html code in their controller as return values.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
THank you
the frontend will manipulate this data
What front end? You mean the JavaScript code in the HTML page? Where did that come from? Oh yeah, the server.
It is the server that serves the HTML pages to the client, as well as any .js and .css files.
The server could provide static pages, and anything dynamic is handled by JavaScript. Or, the server could dynamically build the HTML page, using ... you guessed it ... a template engine.
You generally don't want JavaScript to build the page initially, just to use JavaScript for handling any dynamic behavior. Some pages don't even need any dynamic behavior.
Unless of course you're thinking about single-page applications (SPA), where there is only one root HTML page, and everything else is built client-side with JavaScript and AJAX calls, but most web applications are not SPAs.
Thymeleaf replaces JSP by providing HTML pages using a template engine. The controller requests the HTML file and Spring Boot provides that template after building it using the Model provided.
Thymeleaf is great because it allows you to rebuild templates on the fly. Lets say for example you're showing a users points to them on the front end, but maybe the points increase or decrease.
What you can do is build the template in the background using a Model. The Model reference is magically provided to the template provided which parses it.
#RequestMapping(...)
public String request(Model model) {
model.put("points", 5);
return "my-template.html"
}
Then use the Thymeleaf language to provide your object to the HTML file to be processed in the engine during runtime.
<html..>
<head>...</head>
<body>
<h1 th:text="${points}"></h1>
</html>
Spring Boots Template engine will build this in the background and present it to the user, but it will show the actual points to the end user! Hope this helps a tiny bit.
I know this question has been answered pretty effectively so far, but I want to add my two cents in as I work with Thymeleaf often.
The easiest way to think about a template engine is that it allows some dynamic development of html based on information passed to it by the controller method. This allows you to put logic in that normally wouldn't exist, or say display a certain section if a user is perhaps logged into admin.
If web pages were houses, html is the frame, css is the walls, Javascript is the lights and electricity, and a template engine would pretty much just be the architect designing the plans on the fly before the frame was built based on desires of the buyer of the house (user inputs).
OK, newer Apps and websites may just load/boot/open once and then pull or push data via AJAX requests, this is good, it saves traffic and it is fast.
But it has not always been like this and some Frameworks still don't build everything on small requests. Spring in Java or Symfony in PHP are MVC Frameworks and use template engines to build pages. This may sound a little outdated but there is still a lot of websites using this.
And if you build a web app for a customer with slow PCs or other devices and the page contents are performance heavy you might want to do as much work as possible on the server so that the user does not have to wait for long. And also you can cache the rendered pages. There is even server side rendering of react pages to e.g. make the initial page load faster...
With Java and Spring I did just use JSP I don't know thymeleaf. Just use what you like and maybe what is most supported/documented.
And building websites like this does not mean you cannot use AJAX, but if you use templates you need to think about what makes sense.
What is confusing me is how can a backend server have html?
The "back end" must have HTML, because that's what's delivered to, and rendered by, the client.
It may just be that the back end "server" is just a CDN delivering, say, an HTML/JS SPA, but there's still something delivering content to the browser.
That said: server-side rendering is still a thing, and has had a resurgence lately--a React app may have its initial rendering done on the server so again the client gets a page rendered with both HTML and associated data, and then starts acting like a normal SPA.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
Because something needs to run the JS to access those APIs.
Some history:
Browsers used to suck. JS used to be a neat add-on, sites were relatively static, and essentially all rendering was done on the server. The back end would get data from wherever it got data from and generate complete HTML pages, and there was little happening on the client side other than some form fields, maybe some validation, and that was about the extent of it.
I have a web service written in Java using Struts2, struts controller returns jsp pages, now I want to rewrite frontend using react components, what is the best way to start?
TLDR, you can easily announce to your stakeholders, that it'll take few months/year or more depending on how big is your application/team.
This is huge shift from web application architecture point of view. Struts2 + JSP is doing HTML templating on back-end. So data are injected into HTML on server and HTML is also format that is returned from server.
On the other hand, React is client-side HTML templating library. So it is expected to communicate with server via AJAX calls and reading data (in JSON or other format) and inject that data on client using React.
So this will not be easy change. You would need to decouple all your JSP data inject points into services and expose them as JSON data via controllers (taking into account changing of authentication mechanism, input validation, ...). After that refactoring you can start moving your JSP templates into React (most probably JSX). But on that path you realize that you may want to use some UI state management (e.g. Redux). You also discover that you want to structure your components into more composable way than most of old JSP templates were. Didn't mention you'll need to also port over some JS that was embedded into these JSPs. Said that, you may end up wiping out all the JSPs altogether and creating UI application from scratch.
You will also discover on that journey stuff like JS testing, UI build pipeline, asset bundling and more goodies of modern UI web development, which will add to overall refactoring.
I am using Reactjs, webpack along with page.js (routing) to build a webapp. Webpack gives me a bundle.js which is loaded on the client side.
I found out the og Meta tags can't be crawled if I am loading them on the client so, I have to implement it on the server side (server side rendering). Is there any way to implement it ?
(I didn't find proper documentation about this on net).
A lot of people are rendering the "shell" of the html with another template language on the server (since only the server needs to render it). You shouldn't use React to render stuff outside the body using normal APIs (there are known issues with that). However you can use renderToStaticMarkup, which I think is a nicer way as you are not introducing another template language on the server just to render the shell.
Of course this means that you can't update something like the meta description or document.title in a normal React way, you would have to just do it with plain old JavaScript. Alternatively I recommend react-helmet (which can modify the meta and title when the server renders too).
I made an example here which may be helpful - https://github.com/DominicTobias/universal-react/
I have two HTML files: One acts as a template, supplying the navigation, sidebars, etc., and the other has the main content. I'm trying to figure out how best to insert the content into the template. I need persistent URLs, so my plan was to have the content page essentially replace itself with the template, plugging the text back into the resulting page. I'm really new to front-end programming and I'm suspicious that this may be an anti-pattern, so my first question is about whether I'm barking up the right tree. The problem seems universal, and I'm sure there must be a best practice, though I haven't yet seen it discussed. If this is an acceptable way to proceed, then what JavaScript function would allow me to access the HTML of two different pages at the same time?
[EDIT: It's a small page on GitHub]
Do not do this. At current implementation HTML is not designed to be template engine. You can use HTML import but it has not full support in browsers. (compatibility table).
Usually this problem can be solved with:
Use frontend framework. Libraries like angular.js or polymer.js (and so on) usually has support of importing HTML documents in different forms.
Build your application HTML. Task runners like grunt.js usually has plugin that includes HTML.
Use server side technologies to extend your HTML from base layouts
If your application have to be consisted from different HTMLs I recommend you to try polymer. It is polyfill for web components and designed to work in such way by default.
UPD:
About edit to your question. It seems like you just need template engine for HTML. You can google for it. I use nunjucks - javascript port of python's template engine jinja2. It is lightweight, simple and can be compiled right in browser.
Another way is to use special tools for building static web pages. You have mentioned that your page is blog build from simple HTML pages. Try to use pelican. It is the static websites (blogs) generator. It is simple and fast. You can build your HTML even on your local machine and just push your HTML pages to github.
I'm learning about single page application and after read document itself
I wonder that single page application pattern is just one page(e.g: html page) in web application using knockout with external template?
I mean ( i'm using MVC ):
-mywebsite
+ some js files
+ some css files
+ index.html
+ controllers
+ models
I hope someone can explain for me more about this pattern.Thanks.
Yes, you generally have a single HTML page that acts as a "shell" that has views of information loaded into that "shell". The JavaScript files act as the medium to call out to get this data, parse the data and apply templates to the data. Models, controllers, etc. allow for a module approach to the JavaScript structure, as opposed to spaghetti JavaScript code. CSS serves the same purpose as usual.
In my opinion, it is what pure AJAX applications were intended to be about 10 years ago, where a single page would load and then only requests to the server or services would load data, only performing partial page updates instead of posting back to the server to render (or re-render) the page (like WebForms does).
UPDATE:
The Single Page Application: KnockoutJS template incorporates KnockoutJS, but there are other options as detailed in Know a library other than Knockout?, which enumerates the features of each template in a grid for easy viewing.
Actually you can separate your application in to set of html files and java script files. What Single page application supposed to have is do all the application stuff without refreshing the browser. You can lazy load your views (html) and JavaScript whenever you need . I think you can start with a template or sample to get the idea of it.
you can get more details from John Papa
Here are some frmameworks which supports SPA
http://durandaljs.com/
http://www.asp.net/single-page-application/overview/introduction/knockoutjs-template
A single page application typically provides a shell in the form of a single page that invokes ajax calls to provide functionality. The key idea is that the shell doesn't refresh as a full page, but rather the content is refreshed through ajax calls that target sub sections of the shell.
One benefit of this model is that users don't have to deal with the disruptive user experience of refreshing the entire page and losing client side state.
Knockout can certainly be used as part of your design, but it's not directly part of the pattern.