What is the true purpose of the namespace in technologies such as web services? I can understand in something like XHTML where it's potentially used by the browser to determine the intended rendering mode, but these URL styled schemas seem to be used in a multitude of places, not all of which make sense to me?
Related
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.
I'm learning node.js thesedays and new to back-end.
One thing that I'm confused is why do we have to use View Templates?
Why don't we just use HTML form on server side?
Templates are used in most of the language platforms, not just NodeJS. There is a school of thought in software development that says "Your data/business logic should be separate from your presentation" and templates are used to achieve that. This is ofcourse the right concern for software development and it's benefit are most visibly seen in Model-View-Controller frameworks like Rails, Laravel, and Symphony to name a few.
There are many benefits to keeping your data/business logic separate from presentation:
Developer and Designer roles are vastly separated and their responsibilities are well defined.
Your application user interface becomes modular that is it can be changed without involving a developer.
Your application business logic can be altered by developers as long as they provide the data required for template rendering.
Code consistency is vastly improved as the templating language provides uniformity and you do not have to use dynamic language constructs with raw markup(in case of web projects but you get the idea).
For a practical example of these benefits, you can look into many open source projects like Ghost, October CMS etc.
If I use Jades template engine with NodeJs will the app be crawlable by search engines and Facebook without using the _escaped_fragment_?
If your application outputs HTML, it is no different than if you had written that HTML in a file and simply served the file. The wider Web doesn't generally know or care what you're using to generate your HTML.
(It is possible to infer what tech a page is using by inspecting headers and looking for common idioms that are unique to a particular technology, but these are just clues, not a fundamental difference in what your Web page is.)
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.
Imagine a service that already has a full ecommerce catalog and purchasing etc back office with a RESTFUL API that developers can use to connect to remotely to create ecommerce websites from it. I have already built this. What I was hoping for is some advice in implementing a RESTFUL EJS service on top of this that would allow for a developer to specify an EJS template file via http resource URL and a typical catalog query in the same call such as:
http://mywebsite.ecommerceapi.com/catalogid/products?query=sunglasses&ejs=httpurl
The resulting service would then return the rendered EJS template (using caching etc for the query and EJS template). This would be primarily for SEO purposes and allowing the developers to create the same solution client-side in terms of templating as they do in server-side so it eases development in simplifying how client-side and server-side templates are done regardless of the technology used to setup the websites.
Your suggestions? I also have no problem with you saying "this is a bad idea" but please give reasons.