npm version and webpack build

[Tugark]

Hi there

(Beware, this could be a longer posting ;-))
As mentioned e.g. in #28 (comment), I worked on a webpack-friendly version of the library. The first version is done; however, I cannot easily open a pull-request since in order to have a working, clean library, we need to seperate the client from the library. See below for some thoughts about future developments.

What I've done is that I created a module of the library itself; this is prepared to be published as an npm package. As such, we would be able to use the 3dcitydb-web-map by using npm install 3dcitydb-web-map and develop it just like other libraries out there. You can find the module repository with a brief README here: https://github.com/Tugark/3dcitydb-npm

Since we also have the basic client (inside ./3dwebclient, mainly script.js), I also created this client as a webpack build. I exchanged the "official" script.js" with an index.js which includes all required node_modules as well as the above npm-version of the 3dcityb-library. This can then be compiled to app.js through webpack, while also copying the webworkers to the correct repositories. Please find the client and a README here: https://github.com/Tugark/3dcitydb-client

This is of course more a proof-of-concept and can certainly be optimized in various ways. I suggest that, should you find the time, checkout the repos, so we can work on this further. For getting ready, follow this approach:

• Clone the npm-module
• Rename the folder to 3dcitydb (or change package.json in the client later on)
• Run npm install
• Clone the client into a directory next to the 3dcitydb (or change package.json to point to the cloned npm module)
• Run npm install
• Run npm run-script build, this creates a webpack build within the /dist/ folder.
• Access index.html inside the /dist/ folder, if it all went well, you should see a working version.

Should you need assistance, I can help you out.

---

As for the advantages - using such an approach (npm module, webpack) has several advantages:

• Separation of library and client, making it more easily maintainable and detachable
• Possibility to easily leverage webpack and other build tools' capacities and advantages
• No need to bundle 3rdparty libraries such as Cesium directly into the codebase
• Possibility to include NPM packages and much more
• Possibility to easily extend the usage of the library to be incorporated in other frameworks such as React or others without compromising their approach
• Reduced file size through webpack build processes (e.g. my webpack build is a single 3.0MB javascript file (could be optimized, see above!), whereas the official version loads around 9.9MB of javascript, with Cesium taking 7MB alone)
• Easier version control and provision through npm
• The possibility to build standalone versions still exists, of course; we would just have to set up the build pipeline

Of course, there are also disadvantages, such as

• Change in development process
• Probably a bit more difficult for less experienced users to create applications
  However, the last point can also be mitigated by supplying a prebuilt, standalone version. Given the fact that less experienced users will mostly use the standalone client provided by you, this aspect can also be neglected.

---

I hope that my posting wasn't too long :-) Please let me know what you think of the approach and whether you think that we could change the library to be npm-module based (perhaps something like webclient 2.0 to avoid breaking changes or so). I do hope that we can develop this approach further since I think it would help the amazing work you've put in so far to be even more widely used and also be more future-oriented.

Should you find bugs and issues, please report them to me.

Happy coding and best,
Lukas

[Tugark]

By the way, here is a screenshot that shows custom terrain and 3dcitydb-layers, provided by the webpack build (see the repo for known issues ;)):