I have a SPA here and I´m wondering what should I do to get it properly indexed by Google bot.
I read a lot on multiple views angularjs apps (hashbanging and that stuff) but my app has just one view / controller.
Should I create an html copy for each of the items being shown and link them together?
Thanks in advance,
Ariel
In AngularJS, you can compile templates & cache them using a variety of techniques - you'll need to write a process or build into your runtime logic building these templates & binding them to data, writing them out as static files.
Google allows for special handling based on user-agent. I have a friend who says, "This was called cloaking, before Google owned Angular." This is true. You need to setup server logic that re-directs any Google-bot user agent (or other search engine agents you care about) dynamically to one of these static "Search-Bot Friendly" pages.
Although this is more work, there are obviously bonuses to being able to maintain a set of content that search crawlers "see" and a (potentially different) set of content consumed by real users.
This is also the reason why AngularJS as a client-side framework quickly falls down the rank list when search visibility is a primary objective of the project.
Related
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
I’m in the process of building a new webapp which uses Wagtail. This is an architecture question.
There will be the standard About, Terms of Service, and Blog pages. All of which fit in with the Wagtail paradigm very nicely. The rest of the site content is location-based information about specific types of businesses. Think of a FourSquare type app. The data for these pages will be very structured, be updated via user-facing webpages and a mobile app, and be JavaScript heavy.
For the regular Wagtail pages, there may be hundreds over time. For the location page types there will be (hopefully) tens of thousands of pages that will be nested to a max of four levels.
From a site-wide feature perspective, I’m looking to leverage Wagtail features like sitemaps and Elastic Search.
My question is, should I use the wagtail Page class for my location based pages?
Pros:
Easy integration with Elastic Search and Wagtail sitemaps
Leverage Wagtail editor on the admin side.
Consistent model and api structure throughout.
Cons:
Potentially more overhead for location pages.
Need to utilize more hooks to manipulate the view output (Lots of JS, so will be inserting non-model info into the template).
Potentially limits the use of some third-party modules.
If I went the non-wagtail route, is it possible to add non-wagtail models to the search index?
Are there other issues I should consider in this choice?
Any Django model can be indexed and searched by inherit from index.Indexed and defining search_fields onto the model.
As for using pages or not, as always it depends on many things. However, it looks like it would make sense to keep your location model as such, not make it a page and expose in in the admin (either Django Admin if you need some extensions that already exists there, or Wagtail's modeladmin otherwise). Then you would create a LocationIndexPage which implements the RoutablePageMixin to dynamically serve the LocationPages. The page won't exists in the admin tree but will be reachable anyway.
Take a SaaS company that wants to pack all its services into a single, uhm.. Single Page Application using Angular (1). Now there is a public area (landing page, etc.) and an internal area. There are various layers of protection in the backend. There are different user groups with different privileges.
If the complete app is compiled into a single javascript file, hints for all routes can be found in the JS file quite easily. Then, there are services / $resources for interacting with the API, which again contain quite essential information on the functionality of the application.
Now the question: How could someone put modules on a certain non-binary protection level, and only load this particular module when the user is authorized to see it, all while not reloading the page?
I can find a way to lazily add modules to an angular application. I can also protect single files server sided and only send them to authorized users. But that seems like an unscalable hassle when there are more and more user groups.
Do you know any generic libraries for that purpose, ideally in sync with koa, which do not create a vast overhead? Do you know of some grunt / gulp / whatever processes, which help with that?
Thanks!
You can use latest ui.router which allows you to lazy load routes.
https://ui-router.github.io/ng1/docs/latest/interfaces/state.statedeclaration.html#lazyload
Also you can use web pack and use multiple entry points to create seperate bundles. https://webpack.github.io/docs/multiple-entry-points.html
By following above steps you can optimise the app but I don't think that this will add any protection to the web assets. You can minify to make life bit difficult to understand what your JS code is doing.
I am starting to develop a business spa application (mobile/desktop web app) with Play Framework 2 and AngularJS. Right now I am tending to go with following solution:
Play behaves as a RESTful application
Play also pre-processes partials
AngularJS handles the rest
My arguments for pre-processing partials are:
Play can remove parts of a partial for a more compact mobile view
Different user roles see more/less content of the partial
Correct language will be loaded into the partial
Are there any disadvantages with this approach? Do you think this would be the best solution for the project's requirements?
Server-side templating is usually what you want to get rid of when building an SPA. In general this should work, but there are a couple of disadvantages:
You are mixing two template languages, Play and AngularJS, so you must be careful not create an unmaintainable mess
Your display logic will also be distributed or duplicated between Angular and Play; in a pure RESTful approach Play would mostly be concerned about access control and JSON (input, output, validation)
You must create a route for every partial instead of just using the assets route
Server side templating slows down compilation speed
Returning different content depending on roles and desktop/mobile might mess with Angular's $template cache
Different user roles see more/less content of the partial
This should be handled by Angular IMHO, Play would just make sure to only serve the appropriate JSON to the right users.
Correct language will be loaded into the partial
How would you reuse Play's Lang in Angular? Build an inline variable? Again, just load it via JSON when the app bootstraps.
We are designing a complex web app which runs in multiple browser windows .will use AngularJS
(note it has to look/feel like one app – just that it is spread across several browser windows)
Javascript allows a parent window to reference the objects on other windows as long as the parent retains references to the other windows. Those objects can be accessed either by the native accessors or, for example, by jQuery.
Is a multi-window app something that's been done with Angular before? How would such an app be structured to be scalable?
(I have seen the big 'angular-app' reference app which is a template for large scale apps (if I could only get it working!) but haven't found anything on using multiple browser windows...
Probably not the answer you're looking for, but from my experience w/ AngularJS it seems what you are looking for in an anti-pattern for angular. Specifically, angular is big on scoping - so a controller and view would only 'know' about its own stuff. Any other controllers/views on the same page, or other windows, etc. wouldn't necessarily have references to each other. Rather, an application on a page would have a $rootScope which can serve as a message bus w/ $emit(), on$().
So, perhaps look at this as loosely coupled parts with a centralized message bus that figures out which windows get what events. Then each part (app/controller/view) is just responding to those events.
Note: We had a test app that simulated multiple UIWebViews in a mobile app by hosting each angular app in and iFrames and used this approach successfully. Very composable, very testable.
HTH