(Beware, this could be a longer posting ;-))
As mentioned e.g. in https://github.com/3dcitydb/3dcitydb-web-map/pull/28#issuecomment-385880567, 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.
Hi there
(Beware, this could be a longer posting ;-)) As mentioned e.g. in https://github.com/3dcitydb/3dcitydb-web-map/pull/28#issuecomment-385880567, 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-npmSince 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:
3dcitydb
(or change package.json in the client later on)npm install
npm install
npm run-script build
, this creates a webpack build within the /dist/ folder.Should you need assistance, I can help you out.
As for the advantages - using such an approach (npm module, webpack) has several advantages:
Of course, there are also disadvantages, such as
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