Add: babel-loader for ES6+ & service workers & manifest.json

[olegkorol]

Changes 1

• Added babel-loader to webpack.config.js in order to allow the use of ES6+ features in the .js files.
• Dropped use of var declarations in favor of const/let in the whole project.

Changes 2

As part 1 of my PWA proposal:

• Add service workers capability.

  • Theservice-worker.js is generated using Google's sw-precache package with options given inside sw-precache.config.js.
  • The SW registration process itself can be found inside main.js:

  export function main() {
  return platformBrowserDynamic().bootstrapModule(AppModule)
  // Checks if the browser supports service workers. If yes, it registers one.
      .then(() => {
      if ('serviceWorker' in navigator) {
          navigator.serviceWorker
          .register('/service-worker.js')
          .then(registration => console.log('SW has been registered with scope: ',
              registration.scope));
      }
      })
      .catch(err => console.error(err));
  }

  Following assets are set to be cached as part of the app-shell:

  'dist/**.html',
  'dist/js/**.js',
  'dist/css/**.css',
  'dist/img/*'

To test it, execute npm run build-sw and you will create a build with service workers.

You can also run a server with the productive build using npm run build-sw-serve. Note: For that you will need to have live-server installed globally (npm i -g live-server).

You can see that after killing the server or going offline the app is still getting loaded and works :)

Another note: Service Workers are intended to be run only using HTTPS.

Changes 3

Added manifest.json and some icons.

When the app is opened from the browser the user gets directly asked if he/she wants to save it as an app in the home screen, which gives a slick user experience.

There are many other options that could be added additionally to the manifest.

This makes the app PWA compliant (not super-performant yet).

Check it out here :)

---

In order for the app to be much more performant, AoT compilation should be added, which will reduce the load time around 50-60% and make the bundles smaller in comparison to JIT compilation.

I will get to it in the next few commits. Suggestions are welcome.

[Foxandxss]

I will check it soon. But why babel? Node also support lots of ES6 features without transpiler.

[olegkorol]

@Foxandxss: Babel is there just to make sure that using the newest features in the .js files doesn't break anything. But you are right, it is not that necessary.

Service Workers and the manifest, from the other side, are quite important in my opinion :)

[Foxandxss]

Angular has its own packages for service workers.

But I am not even sure if I want that right now here. In fact I am not too sure of what I want. The CLI is the ultimate solution and this starter is not that useful anymore.

[GaryB432]

This was a great starter while the CLI was coming up. I learned a lot. Thanks for all your work on it.

[Foxandxss]

I always wanted to add more features, but the CLI started to be better and better.,always having the latest good stuff so I started to lose motivation

[olegkorol]

I still see some projects exiting the CLI and doing the configurations directly with webpack, because the CLI is not perfect (yet) and has some restrictions. But yes, it is getting quite close to it and hopefully it does soon. I totally support it. Meanwhile, such a starter is not that bad I think 🙈

[strictd]

@olegkorol I agree with you on the cli. I've felt it's gotten a bit of tunnel vision. There are pros and cons to the reasons. Anyways I've been looking for like minded people who want to touch and feel the configurations.

All of my inspiration has come from this preboot/angular-webpack repo over a long period of time. Thanks alot @Foxandxss !! anyways, not to hijack this to badly, checkout my ngx-mono / ngx-mono-core repos. I've just implemented AOT this weekend. The public_website branch of ngx-mono-core is the simplest. Sorry for the lack of docs, thinking about making an animated gif for compiling examples.