I am new in React js. Previously i used JSF framework for building the web application. According to my knowledge in JSF actually what does is, from the server side it will generate the html code for the corresponding JSF tag and send it to browser and display it. If you are using JSF 2 the corresponding front end html portion can replace through AJAX also.
I think the same thing we can done through React framework. In react JS you can generate the client side html code from server and it will render in frontend by using some Javascript Engine (Nashorn Javascript Engine).
So in both case the working is almost same (The response created from the server). Now a days everyone talks like the React JS is a high performance framework. So can anyone explain how it provide better performance?
I repeat i am new in React JS
I believe performance all depends on the implementation, you can get both React and JSF to do the same thing. JSF came before React, and React in my opinion adopted many concepts of JSF anyway. React has not made any breakthrough that hasn't already been there with web templating engines since JSF 1.2. JSF is a templating technology which React recreates with Javascript.
For a mobile device its better to get the complete HTML to save on battery initially... both React and JSF can do Single Page Apps (SPA) to use Ajax and update only a portion of the DOM while the User is interacting with the application.
For pages with user interaction, JSF will send the Javascript needed that will interact with one DOM directly, for React it will use its shadow DOM and the browser DOM.
Both can define custom UI components, JSF speedier sends the rendered HTML directly to the client, while React will have to build it using the client computer cpu.
We can compromise performance for faster UIs, changing UIs faster, software engineers vs scripting folks salary. For any large scale, I'd prefer JSF because of reusable Java libraries in microservices, AI, Machine Learning, Android, and other things that has a JVM. For the UI, maybe we can let a scripting person whip up a UI in React while we focus on the bigger solution?
Internally, ReactJS uses a virtual DOM that will be "mapped" to the "real" DOM. In React you give your variables as state or props to the react component. React uses a special algorithm to detect changes in the components state or props and will only rerender the affected parts by synchronize the virtual with the "real" DOM.
JSF is an MVC framework that takes advantage of server side rendering and makes use of many markup files.
React is a library for building graphical interfaces for applications according to the SPA (Single Page Application) model.
The strength of React lies in its ability to update the dom very quickly because it has a virtual one.
The final app can fit all in a single file.
As said React is only a library, it is not productive to use it alone to create an application.
(Similarly JSF is just a spec, without Rich Faces, Prime Faces, Omni Faces, Boots Faces and 3rd parts libraries it would be difficult to create an application)
In the SPA model, the session is stored with the user, the backend is just a set of services that are called up by the frontend.
There is a first authentication call which produces a token (JWT) which is stored on the client side and which will then be used to
invoke the server's (stateless) REST services. This is how the server can understand that it is the same user.
The key information for the session is stored on the client side, this fact already makes you understand that the server is relieved of the task of
keep in memory the sessions of all connected users.
In practice, when the user interacts on a SPA application, what travels is the data, not the markup since all or most of the markup is already on the client,
this implies a nice saving in data transfer. The REST paradigm uses json to structure the data to be exchanged with the client.
A json object (Javascript Object Notation) that arrives at the client is a string representing a Javascript object, The latter offers native functions
to convert Json strings to Javascript objects and vice versa. React has nothing more to do than use this object to "go there to that specific point" and update the displayed data
and it does it very quickly.
JSF requires the presence of its own and third-party Java libraries on the server side (configured as a part of an Application Server) so it requires configuration time
higher and has a rigid scalability compared to a React application ready for deployment which consists of only javscript files (even one would be enough)
which only needs a web server like Nginx to run. It is easy to understand how easily this last solution is scalable since the configuration is reduced to zero.
To scale, just create a nginx docker image with our React app inside and we are ready to move from the development pc to the various cloud solutions on the internet
ready to replicate our image across multiple on-demand instances.
Related
I'm starting out on my Node.JS journey and I discovered a fantastic boilerplate over at https://github.com/azouaoui-med/pro-sidebar-template. I'm unsure though how to turn the static html into a web app. Just wondering how someone with more experience would do this?
Do I take the html and translate it into a PUG template file? I'm guessing to then make the onclick / links actually run some code, i'd need to point them at the routes setup in the web app?
Sorry to ask such inexperienced questions, web apps seem to take a vastly different approach to the desktop apps i'm familiar with programming
I'm wanting to create a web app that runs on a server, which I will later put on the desktop via electron.
thanks
The project you have is using browser-sync which indirectly uses NodeJS to run a local server and host the web application files.
Do I take the HTML and translate it into a PUG template file?
I am not sure about this question unless you specifically want to use server-side rendering I am not sure I would recommend this to start with especially if you plan to later convert this to a desktop application.
[Note* - Assuming you are referencing this library PUGJS in statements above ]
Now For this requirement I'm wanting to create a web app that runs on a server, which I will later put on the desktop via electron.
This will require you to make your data serving layer which is most commonly called backend separate from that of the data viewing layer which is most commonly referred to as front-end. Thus a case for using the same data layer across different types of clients viz. A web application and/or A desktop application ( electron if you choose so )
Step 1 - Define what sort of web application architecture you want to follow or use. This will be based on your project and business requirements. From what information I have so far I would suggest a simple client-server architecture where your frontend or web-application is the client which makes REST API calls to the backend (API Server) and thus produces a meaningful result.
Step 2 - Start with the creation of 2 projects a frontend where your HTML, CSS JS, etc will be and a simple NodeJS script to serve this static web app when deployed on the server. I am going with NodeJS since the context of this question is suggesting the same.
Step 3 - The other project which will only be an API Server or Backend. This server will provide only REST API to the frontend. This server will talk to the database and provide other services like authentication and logging etc. You can use expressJS for this also in the frontend project.
Here is a simplistic representation of the client-server model which you can reference.
Some additional links for you to digest.
What is the difference between a web application and a client/server application?
https://medium.com/codiumclub/web-application-architecture-part-1-guide-to-become-full-stack-developer-cc9526a3519b
Hope I'm not being to general but: I have been tasked with the job of "rejuvenating/modernizing" a monolithic Java EE (JSF/CDI/EJB/JPA) app. Since the requirements state that it should support multiple clients, I have split up the code in a server (JAX-RS interfaces) and a client part (not yet done)
The server is pretty straightforward but I'm wondering about the UI part. Nowadays (hope I don't sound too oldskool) various Node JS spin-offs seem to be popular but I'm under the impression that they have the most value to offer in the "scalable server" section. Does the various Angular/React/Node framework have anything to offer for the client if you have something more complex than a single page app?
It appears to be a really hard time to pick a UI technology nowadays. Sure, the server/DB part which contains most of the business logic are pretty future-proof but still, one would like to focus on one UI technology. There are various jQuery-based frameworks like Kendo, Vaadin & co etc. One option would be to stick with JSF + ICEfaces/PrimeFaces and just work with the REST interface. And then there is JavaFX which looks nice but the future looks a bit uncertain.
So. If the backend is not going to be Node JS, does Node JS have anything to offer for the UI part that can't be done more easily with other frameworks and does anyone have other insights on the UI layer in general. Predicting is hard, especially the future ;-)
Node.js is a way to run javascript on the server side, not client side. That said, npm (nodes package manager) or its wrappers (like bower) are quite often used to manage the client side dependencies - which is very useful to have.
Angular and react (among others) are client side javascript ui frameworks to help make writing ui much nicer. Neither depend on the backend being written in node.js and can work with any rest api (or other server side apis) - or no api at all if that backend injects all the data the page needs into the page itself.
Electron, which combines NodeJS and Chromium (render Process).
https://electronjs.org/
Formerly known as atom shell it was created by Github, it is the core of the Atom Editor, VS Code, Slack app, and a ton of “thick client” applications. https://en.m.wikipedia.org/wiki/Fat_client
There are several implementations which allow you to use Node.JS modules on a client-side (ie. web browser). You can then use html/css and call Node.JS modules directly from your DOM which is used to implement UI.
I'm most familiar with NW.js which I've used couple of times. Others would be for example Electron or AppJS
Now Airbnb have a tool Hypernova for server side rendering of javascript views. I would like to know if it can be used for enhancing SEO of Ajax based website like the tool Prerender is used for. If not then why?
A quick way to figure out the way how a tool works is to check its dependencies. It doesn't contain phantom or other adapter for headless browser, so it just evaluates client-side scripts in Node.js.
hypernova runs client-side scripts in Node.js and renders them to HTML. In order to make this possible, scripts should be universal and don't depend on browser-specific features. This allows to avoid the overhead that is caused by rendering in headless browser (like Prerender does).
hypernova documentation is focused on using React components because they are naturally universal and most time don't require real DOM when being rendered in Node.js, They are rendered with hypernova-react package, which is a thin wrapper over React's own SSR features.
AngularJS was developed to run in a browser and relies on real DOM. It is guaranteed to work properly only on client side. It's possible (at least in theory) to render AngularJS application in Node.js with DOM emulation (jsdom) or jQuery emulation (cheerio), but hypernova doesn't offer a suitable adapter for that.
I am building a website using nodejs and express. How to make divisions in a page dynamic? Is Jade used for that? if not how to do it?what is angularjs used for? Please help i searched a lot on google and i couldn't get a clarity in the usage of them.
Jade creates the html used in the browser on the server-side. The browser executes a request to the web-server, the web-server executes Jade, which will generate the html that will be sent to the browser. This server-side content generation has been very common in the last ~20 years, but it has quite some cons when building rich internet application. Mostly this has to do with performance and client state tracking.
AngularJS is a client-side MVC/MVVM like framework to build so called Single Page Applications (SPA), which allows you to have the complete user interface flow, all content generation and state tracking to be done at the client side. It even allows you to build offline applications. From the developer point of view this feels much more like building a desktop application where the client knows the state of the user interface. From the user point of the view the website will respond much smoother and snappier because the UI is all generated locally.
Note: SPA does not mean that you can only have one page in your website.
It's a technical term where the browser downloads one page (~/index.html), which contains the complete or partial web application. The user technically never leaves this page, but the content (pages) is dynamically swapped in and out from this placeholder page.
To most common way to provide data to a SPA is via RESTful web services. AngularJS comes with builtin support for REST.
Some developers combine server-side content generation techniques with AngularJS, but there's actually no real need for this.
Jade is used as a template engine on both server-side and client-side. Yes, it can update a page dynamically, you just have to compile your jade templates to a javascript functions (using jade -c or something similar).
Yes, you can use angular.js with it, but I see no real need to use two template engines in your project. Suggesting to just stick with jade, unless you know what are you doing.
Express JS uses templates for generating HTML and then server sends them to client in response. There may be several other templates from which HTML can be generated. The ones I was able to discover are:
Jade (http://jade-lang.com/)
EJS (http://embeddedjs.com/)
In my app, I need to use both ExpressJS and AngularJs. I am new to both technologies. While learning angular, I had to use it in pure HTML. After learning ExpressJs, I realized, in order to use angularjs, I need to use them in any of the above templates which will be converted to HTML while sending to client.
Now, I want to use expressjs as my server and angularjs as my client side app. For this, I think I have two options.
Option 1
I can stop using templates altogether and use our NodeJS server to respond by sending simple HTML files. These HTML files will then contain AngularJS coding within them. AngularJS then, on client side, will act as our application. It will demand other HTML documents from the server. Or it can also be used like AJAX, where we can only request the piece of information to update just part of the page rather refreshing the whole page for a minor change.
Option 2
I can use angularjs inside expressjs templates (jade or ejs).
Kindly, help me in understanding the pros and cons of both options. Which one will be your choice in such case.
This is very much an opinion question and Stack Overflow admins hate anything that smacks of opinion, but here's my experience and opinion nevertheless.
I've done a couple of apps now using purely static files (HTML, CSS, and JavaScript) with those calling a service on the back-end to deliver the data. It reduces the back-end, whatever it is (I've used both Java and Node.js), to just being a set of service URLs but it works very very well.
You've got a fantastic hard line between the responsibilities of the
two systems
It's very easy to work on and test each one independently
Bugs are usually very clearly in the front-end or the back-end (all
you have to do is look at the data transferred to know)
The back-end services are ready to be reused to support alternative UIs from the
command line or something mobile specific if you want
You can use one technology for the back-end to start with (say Node.js or Ruby on Rails) and then switch to something else later if you need to. As long as the API stays the same the front-end never knows.
I personally use AngularJS with Express/Jade. The setup is actually pretty simple and I find writing Jade much more enjoyable than writing HTML. I've also adopted writing my Angular code in CoffeeScript as, again, it makes for quicker development. If you are looking to save keystrokes then Jade is a great solution and its integration with Express makes it a no brainer. If you aren't worried about producing code more quickly then there is absolutely no problem with using HTML.
I will point out that one of the greatest benefits I have found to using Jade over HTML is the ability to develop a single page in multiple files, then use include to have them concated before compiling into HTML. This allows you to take larger pages and break them into more manageable chunks. Together with Angular's templating, this can relieve much frustration.
Really it is all a matter of opinion, but since I decided to give Jade a shot, I have not regretted it and I have never ran into a situation where my HTML was rendered incorrectly when using Angular.
I went with option 1 because I didn't want to deal with any potential issues with jade or ejs converting the template incorrectly and interfering with Angular. My app essentially has the index page (which is really just the basic page template with my css and js includes) come out of Express as jade and then angular takes it come there and all my angular templates are in a separate location than my jade template.