I am creating a single page app (mobile/desktop) using AngularJS. Based on the limited knowledge I have of AngularJS, I think the routing for the apps/websites is based on urls and $location/$location.path directive is used. However, in mobile or desktop apps, there is no browser. So how does AngularJS routing work in this case if views need to be switched?
Thanks
If you are talking about an Angular application by itself, it will always need something to be interpreted by something. Angular is written in JavaScript which means it will have to be interpreted by something which understands JavaScript. I am using the word interpreted instead of compiled, because JavaScript is not a compiled language.
But then how does something that interprets JavaScript display it on my screen you ask? For this you'll need a bit of background information.
The DOM
This is where we got to the Document Object Model DOM. From W3c:
The Document Object Model is a platform- and language-neutral
interface that will allow programs and scripts to dynamically access
and update the content, structure and style of documents. The document
can be further processed and the results of that processing can be
incorporated back into the presented page. This is an overview of
DOM-related materials here at W3C and around the web.
To dumb the quote above down:
you have a document (web page) which is being displayed and the DOM allows you to change this document which is being displayed.
JavaScript Engine
The link between JavaScript and the DOM is provided by an Engine. Every browser uses a JavaScript Engine. For example Chrome uses the V8 JavaScript engine. From an introduction of V8:
JavaScript is most commonly used for client-side scripting in a
browser, being used to manipulate Document Object Model (DOM) objects
for example. The DOM is not, however, typically provided by the
JavaScript engine but instead by a browser. The same is true of
V8—Google Chrome provides the DOM. V8 does however provide all the
data types, operators, objects and functions specified in the ECMA
standard.
How does this translate to your question?
Everything that wants to display a JavaScript application, needs to have a JavaScript Engine and a DOM. This could be a browser like Chrome, but could also be any other application.
A simple explanation of what a router does, is change the DOM to display different "documents". So plainly said: any application, be it a mobile or desktop application, which has a DOM understands how to use Angular's routing system.
Outside the browser means only application you are speaking about?. angular is tied to HTML pages in general. So its a framework for managing(not exactly appropriate word) the html pages to make them into Single Page Applications so that browser does not need to reload the entire the web application on request of a single page, it helps to invoke the html pages into the main html pages, this makes the application not to reload the entire, but to make available requested pages. this is where the routing comes.
Angular will work just fine there. In fact there is an Ionic project that is based on top of angular. E.g. if you are using Cordova, then the app is rendered inside a browser (or at least with the browser engine). So as far as I know it will behave exactly the same way with the exception of user not being able to type in URL or click back/forward.
Moreover I build an application for browser where I do not user URL as much as possible. E.g. I transition only between states and don't have direct url's in my application at all. Of course I need to support to the extent that a user can type in the url, but the ui-router does that on it's own if you map routes properly. But it seems much more beneficial not to rely on the urls at all for SPA (for internal stuff as you still have the edit url as I said before).
Related
Hello guys i am new to React Js i often hear and see posts regarding react is single page app but never understood what is SPA and many say that it doesn't reload the pages but i didn't understood why so could you guys please explain me with simple examples.
A Single Page Application is a web application or website that interacts with the web browser by dynamically rewriting the current web page with new data from the web server, instead of the default method of the browser loading entire new pages.
This means that the URL of your website will not change completely (page will not reload), instead it will keep getting content and rewriting the DOM with it instead of loading a new page.
The goal is faster transitions that make the website feel more like a native app
Example: Netflix
This is the dashboard, and when we click on any movie, it changes to /watch and the content is rewritten.
In Technical Terms:
When building your react-app, you can see that there is only one
App.js from where your entire web-app is loaded in fragments and
components. This behaviour of rendering components and pages on a single page and changing the DOM( is a single page behaviour and hence the name), instead of loading a new page with new content, this makes it feel like a single application.
As mentioned in Glossary of React Terms:
A single-page application is an application that loads a single HTML page and all the necessary assets (such as JavaScript and CSS) required for the application to run. Any interactions with the page or subsequent pages do not require a round trip to the server which means the page is not reloaded.
And about "Why is React Js called as Single Page Application":
Though you may build a single-page application in React, it is not a requirement. React can also be used for enhancing small parts of existing websites with additional interactivity. Code written in React can coexist peacefully with markup rendered on the server by something like PHP, or with other client-side libraries. In fact, this is exactly how React is being used at Facebook.
A single page application has one single page e.g. www.google.ch. It is exactly one HTML file (with all its required dependencies) loaded into the browser. You'd navigate between paragraphs only using hash-router, but never ever visit another page like www.google.ch/maps (that would then be www.google.ch/#maps, which references / -> index.html) (tho google may not be the best example, it is more about URIs).
ReactJS is an open source JS library for building UI and used for SPA, and it manages the views of web apps. Reactjs can help you to modify your data without reloading of a page. It is a popular library in the market trend because of its scalability & fast performance.
Single Page applications are different from multiple page apps that we see everywhere because the SPA doesn't move into new pages; instead, it will load the pages inline within the same page.
In traditional websites, when we go from one page to another, the whole site is loaded. e.g - if you go from "www.example.com/hi" to "www.example.com/hello" the whole website is reloaded. No matter how much portion of the website is really changed. Let's say, the website has "Sidebar, logo, menu" on both of its pages, then the full reload doesn't make any sense. This takes too much time and decreases the performance.
Single Page Applications, as the name suggests, have only one single page that is loaded the first time you open the website. After this, no matter where you click, it is not gonna refresh the website fully.
browser reload button
The loading icon of the browser doesn't load when we move from one page to another on SPA site, as it does on the traditional websites.
Cons- SPA sites are great for UI UX but they are not the best when it comes to Search Engine Optimisation, it creates problems with rankings.
I am learning MEAN Stack. I started from learning Angular(from angular.io) now I am learning node.js and express.js
My question is, if there is angular for front end in MEAN Stack then why there are views and template engines in express.js at back-end? Are they alternative for each other or complements each other? what is the boundary for the role and responsibility of these two?
I am looking forward for someone's help in clarifying of my concept for role these two technologies(express' views and angular) used in mean stack.
In order to answer your question, let me explain what is angular and what are template engines in express?
What is Angular?
Angular is a platform that makes it easy to build applications with the web. Angular combines declarative templates, dependency injection, end to end tooling, and integrated best practices to solve development challenges. Angular empowers developers to build applications that live on the web, mobile, or the desktop.
what is template engine?
A template engine enables you to use static template files in your application. At runtime, the template engine replaces variables in a template file with actual values and transforms the template into an HTML file sent to the client. This approach makes it easier to design an HTML page.
Some popular template engines that work with Express are Pug, Mustache, and EJS. The Express application generator uses Jade as its default, but it also supports several others.
So,
Angular is a framework with a templating component baked in. You use it to create Single page Web Applications which means that DOM modification is happening on the client side and the app exchange with server only data. If your concern is template it is plain HTML.
Whereas, template engines' rendered views are sent to client each time by server whenever request is made each time a new page is rendered on server and sent to the client which is Great for static sites but not for rich site interactions.
If there is angular for front-end in MEAN Stack then why there are views and template engines in express.js at back-end?
This is because not every time generating views from angular is recommended sometimes it is better to use Template Engines to generate views and send the rendered page to a client, generating views at client side has its own pros and cons and generating views at server side has its own.
Generating views using template engines (i.e. at server-side):
pros:
Search engines can crawl the site for better SEO.
The initial page load is faster.
Great for static sites.
cons:
Frequent server requests.
An overall slow page rendering.
Full page reloads.
Non-rich site interactions.
Generating views using angular engines (i.e. at client-side):
pros:
Rich site interactions
Fast website rendering after the initial load.
Great for web applications.
Robust selection of JavaScript libraries.
cons:
Low SEO if not implemented correctly.
The initial load might require more time.
In most cases, requires an external library.
So, after knowing the pros and cons, you yourself can better decide that in particular case which one is better for you. Mean Stack has provided options for developers.
As far as your question regarding the role of these two technologies is concerned, Angular is a lot more view generator only, It has features like routing, it as services two-way data binding etc while the template engines are meant to render HTML so that it can be sent to the client.
I hope you will find this answer useful.
References:
what is the template engine?
what is angular?
pros/cons
Angular is a full-fledged front-end framework that comes with its own way of doing templating, using angular-specific markup in your HTML. If you use Angular as your framework, you're more or less stuck with their way of templating within the Angular portion of your application.
Angular Features
It is a framework written in Javascript language
Manages state of models
Integrates with other UI tools
Manipulates DOM
Allows writing custom HTML codes
It is meant for javascript developers to create dynamic web pages in a quick time
NodeJS
It serves the web
It is runtime built on javascript engine in google chrome
It can be considered as a lightweight server which can serve client requests in a more
simpler way than java does
It performs communication operation with databases, web-sockets,
middleware etc.
Why we use angular for Tempting not Express/Node tempting Engine
Server-side rendering is the most common method for displaying information onto the screen. It works by converting HTML files in the server into usable information for the browser.
Whenever you visit a website, your browser makes a request to the server that contains the contents of the website. The request usually only takes a few milliseconds, but that ultimately depends on a multitude of factors:
Your internet speed
how many users are trying to access the site and
how optimized the website is, to name a few
Once the request is done processing, your browser gets back the fully rendered HTML and displays it on the screen. If you then decide to visit a different page on the website, your browser will once again make another request for the new information. This will occur each and every time you visit a page that your browser does not have a cached version of.
It doesn’t matter if the new page only has a few items that are different than the current page, the browser will ask for the entire new page and will re-render everything from the ground up.
How client-side rendering works
When developers talk about client-side rendering, they’re talking about rendering content in the browser using JavaScript. So instead of getting all of the content from the HTML document itself, you are getting a bare-bones HTML document with a JavaScript file that will render the rest of the site using the browser.
This is a relatively new approach to rendering websites, and it didn't really become popular until JavaScript libraries started incorporating it into their style of development.
See Examples HerePratical Example
Basically template engines in Express are mostly used for displaying 404 and other server error messages. I find them ideal for such use cases. Using template engines for complex front end rendering is bad and not a good practice.
Express JS is a web framework on top of nodejs http module. Whereas Angular JS is a front end framework which doesnot depend on NodeJs server to run. Conceptually both are similar in few features like routing whereas implementation is different
The Scenario
I'm developing the front-end (CSS only) of an Angular SPA.
I'm not especially familiar with Angular routing.
I'd like to add a standalone page containing Bootstrap components just for development purposes (yes, I know this means it won't be a single page application anymore). This way I have one unified view with all the components so I don't have to switch back and forth while working on the CSS. It also acts as documentation for the Bootstrap for the other devs to refer to.
What I've tried
I originally added a bootstrap.html page to the app folder, alongside the app's index.html This worked at first, but has now stopped working. What would be the best/standard way to achieve something like this?
Update: I've managed to fix some of the JS errors, so the page is up and running again. My question remains though: "is there a way of adding a standalone page that is considered standard/best practise, or is it literally just add a separate HTML page at the app root?"
If you use a target='_self' in your linking anchor tag, this should force a full page reload, and that will avoid the angular routing - which is where I expect your request is getting hijacked (by design).
e.g.
link
Answering your updated question
Not to my knowledge, since (as you correctly pointed out) this mixes the SPA design pattern.
URLs shall be without hashbang
It shall fall back for older Browsers which don't support the History API
Using Angular or Ember
Question: Is there a need to use the history.js?
If yes, read on.
On teamwork.com or soundcloud or other modern websites there is a mechanism to have links loading just a part of the website and at the same time, the URL changes (there is no hashbang). I want to implement this as well and also want to support older browsers and read that history.js can do this. Here is a related question to this where I found that this uses the History Api.
At the same time I want to uses Angular or Ember. I know they have their own routing and there is for example a tutorial to remove the # here.
I read that the different browsers handle the history api differently and that the history.js is a way how to tackle this issue.
So is there a way how to combine those front-end frameworks with that api? I'd start somewhere in the routing but get stuck thinking about what to do...
A new implementation should have cross-browser compatibility including handling older browsers. On one hand I want to have a front end framework to separate front from the backend, not sure about which one to use, yet. On the other hand I like how i.e. teamwork.com handle links that they only load a part of a page (including an animation) when you click on it. At the same time the URL changes and if you type a URL directly the page is loaded correctly. It seems that they do it with jQuery.. not quite sure.
Anyone knows how to use both, routing and the history.js?
I would just use AngularJS with UI Router. It combines routing with history.js like features. It has a HTML5 mode which you can enable which will allow pages to update via AJAX without the use of a hash #.
It should automatically cope with older browsers and change the URL format accordingly.
I have a single page AngularJS app and I want the initial page render to contain all relevant info as HTML so it is crawlable with JavaScript disabled.
For simplicity I was thinking of just adding an alternative HTML version which is hidden when the Angular app loads.
<div>
<!-- Static page content for crawlers, hidden when Angular app loads -->
</div>
<!-- Angular app -->
What are the drawbacks to this approach (serving a complete pre-rendered copy)? The angular app draws data from a JavaScript object rendered as part of the page and I am happy to live with the data being sent twice.
Google have defined a specification that lets you serve snapshots of your page's HTML after all necessary Javascript has run to search engines.
This is supported by Google, Bing, Yandex and even some social network bots: Here are the details of who supports it: http://blog.ajaxsnapshots.com/2013/11/googles-crawlable-ajax-specification.html
Implementing this youself is a fair bit of work, so several companies including https://ajaxsnapshots.com (who I work for) provide it as a service that you can plug into your web server without making any changes to your app.
A search engine bot doesn't really care whether the content is hidden/ visible.
The search engine bot would crawl through almost the entire content of the page.
Therefore its highly recommended to have only the relevant content in place.