The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

221706 (3) [Avatar] Offline
#1
Hi, Jeremy,

I read up to page 61 now but, alas, it does not become very clear to me what runs when and how the parts are interconnected: we have TypeScript to be transformed into JavaScript, we have the bootstrapper, somehow, webpack comes into the picture. I would assume bootstrapping and angular compilation synonymous (?). It would be fine to have an overview about all the possibilities, preferably also with some graphs:

a) What is really loaded from server to browser?
b) Which distinct possibilities (client/server task sharing) exist possibly thereby (and how are they steered).
c) What kind of files gets produced in every step.

Some sample code would also be helpful. I tried with the chrome and firefox debuggers but it remained a bit enigmatic for me.

Thanks a lot. Uwe.
jeremy.wilken (208) [Avatar] Offline
#2
Hi Uwe,

Thanks for asking and let's see what I can do to help clear it up. I've tried to focus primarily on the pieces that are truly Angular in the browser, and skim over the development tooling that prepares a few things before it hits the browser. The last chapter will cover more about the dev tooling, but I probably can add some more detail here. I would suggest you focus first on how Angular itself executes once it is loaded into the browser, and we'll cover the concepts of the CLI and building the application assets later.

Let's start with the role of the Angular CLI, which uses webpack (or other types of tooling that could be used). TypeScript does not run in the browser, and must be compiled into JavaScript. So the CLI is really just an intelligent build tool that can be configured to compile TypeScript, bundle files and optimize the resulting files for the browser to consume. During development, the CLI also acts as a basic webserver and serves static files to the browser (again using webpack). The CLI only generates the static files when you edit source files if you are running `ng serve`. There is no backend server essentially, just a static file server like apache or nginx. To address your specific questions:

A) Only static files are sent to the browser, which were generated on time by the CLI build process. If you reload the page over and over, you'll get the exact same assets each time and they will not have been generated on the fly.

B) There is no crossover between the static file server and the web application. If you have a backend or API, you'll have to build that separately.

C) Files are produced once, at build time. If you run `ng serve`, the CLI watches for file changes and will rebuild the assets again and reload the application.

Something I haven't covered yet is how you would take your Angular application and put it into a production environment. Again, that is a later chapter, but essentially you'd take the static files that the CLI generates from the `dist/` directory and put them somewhere to serve to your users.

You can use the chapter 2 example for reference to inspect how the stages happen. You can add console.log statements at various files to see when things are fired for example. That might also help interactively understand things. Let me know how you get along!

Jeremy
221706 (3) [Avatar] Offline
#3
Hi, Jeremy,

thanks for your clarifications. I was irritated a bit by chapter 1.1.2 "Universal Rendering and the Compiler". As far as I understand your answer, currently we are only dealing with browser side rendering (whereas I would (eventually) also be interested a bit in server side rendering and its implications to the client / server communication / interfaces). But that's presumably an advanced topic still to be covered.

In each case your reply was very helpful and chapter 2 is enlightening of course.

Kind regards, Uwe.
jeremy.wilken (208) [Avatar] Offline
#4
You are correct, the book so far only covers rendering Angular in the browser, and not server side rendering. There are several things at play here. To be honest, I'm not entirely sure yet how server rendering will play out, as it is a fairly complex arrangement and using it today is certainly a journey into unsupported software. Server side rendering is challenging because it requires not just compiling the Angular application into a smaller package, but also running Angular and resolving data on the server. This is not easy, and requires a lot of backend work. Essentially server side rendering is more like running Angular on the server and then sending the result over the wire rather than sending the whole application assets and running it in the browser.

Now AoT and JiT compilation is another aspect that is similar, though distinctly different. AoT compilation is a way to speed up the the browser's ability to execute the application, but it does not actually run Angular in the process. Its largely an optimization of the rendered code, not execution of Angular itself.

Hopefully that helps a little further. I know I skimmed over server side rendering, largely because I'm not certain when it will become stable and supported, but also because its probably would require its own book to implement.