I don't want to get into the why / why nots of Node, jspm, Gulp etc. (they have my full buy-in) but to cut a long (boring) story short, I absolutely cannot use those lovely tools at the location i am currently at.
I want to use Aurelia. I just want to drop the built minified javascript library into my web application and start using it.
Where is such a package?
Many thanks,
R.
We don't have an official one yet, but we are looking into it. There may be something unofficial floating around. Aurelia does require a module loader. Even though you can't use node-related tools, can we assume that you can use either system.js or require.js as a loader? (preferably system.js)
Not possible for this time because aureliajs is only starting period and not complete for development.
Related
I'm creating a little SPA framework (might be a full-feature framework).
Frontend is based on native javascript (including ES6 features and web-components).
Backend is written in Go.
Here is a list of my needs, that I'd like to do automatically:
Minify my javascript files
Transpile ES6 code to ES5 (with something like babel.js)
Polyfill my web-components
Is there a way to achieve this without using node.js? Are there already go packages that can make those 3 things happen, with a "simple" grunt/gulp-like way?
I would like to avoid installing node.js, npm, bower... etc.
In my (not very classified) oppinion, using those node.js tools makes my application a mess adding a lot of unnecessery overhead to my application folder and makes my framework dependant on a lot of stuff (that application programmer has to learn, understand and know how to use).
Thanks for any tips/oppinions.
If you're doing a SPA you should just stick with gulp and others. You'll probably end up using npm stuff like browserify, autoprefix, etc, and you'll basically end up reinventing the wheel with your own asset pipeline.
With that said I've seen a couple, but none of them looked very mature last time I looked:
https://github.com/jbowens/assets
https://github.com/shaoshing/train
and you're going to need npm installed to use them regardless.
I'm working on a JS library that relies heavily on D3 (and to some extent, lodash). I've modularized it, have bower_components for the external library dependencies and node and gulp for the build/concatenation/uglifying process. So I'm covered from the development standpoint (no need for require.js).
However, in order to let other people use my library, they need to have both d3 and loadash loaded. I don't want to bloat their loading but at the same time I want to make things easy for everyone. Should I just concatenate my dependencies along with my .min.js and have that be a release? What are the best practices?
BTW, my current versions of lodash and d3 clock in at 52k and 148k respectively. Thanks!
I seems interesting to embed dependencies in your own library to offer customers an easier way to integrate your component, but think about that:
They may use another component requiring a more up-to-date D3 (you embedded)
For performance reason at load time, your customer may want to use D3 (or other embedded libraries) using the official CDN (better access and downloading time)
You will have to carry about updating your component each time one of your dependency is fixed.
For other more reason you could find by yourself, it is not a good practice to embed dependencies inside your component unless you plan to manage a full support of it.
I'm interested in using Cesium to build a 3D Earth with custom tiles, but as per the "get started" instructions here, it seems as though you have to download a massive 30mb directory and include the whole thing in your project to have it run correctly. Is this true? Can I not just include Cesium.js and get running like that? I don't need 80% of the UI elements they include anyways.
At the end of the "get started" tutorial, they seem to indicate that all you need to get running are these bits:
<script src="Cesium/Cesium.js"></script>
#import url(Cesium/Widgets/widgets.css);
<div id="cesiumContainer"></div>
var viewer = new Cesium.CesiumViewer('cesiumContainer');
But when I set these bits up, I get this error: "define is not defined" and "Cesium is not defined".
What is the lightest possible way to run Cesium?
That tutorial definitely needs an update and I'll make a note to clean it up. (For starters, there's a bug at the bottom of it, because Cesium.CesiumViewer should just be Cesium.Viewer.) That being said, here's the low-down on what's included in the zip and what you'll want/need for actual development.
Apps -> Sample applications.
Source -> AMD modules for module-based development (requirejs, browserify, etc..) also used by the sample applications.
Specs -> Unit tests.
ThirdParty -> Third party libraries required for the above.
Build/Apps -> Built and minified versions of the sampled applications.
Build/Documentation -> The reference documentation.
This leaves two directories, Build/Cesium and Build/CesiumUnminified, which I'll talk about in a minute.
But first, the technically correct answer to your question is to create the lightest possible Cesium-based application, use the AMD modules we provide. This means you only need to include the Source folder at development time, and then your build process will create the minified and concatenated version of your app for deployment. Using modules ensure you only include the Cesium features you are using. This is different than the "traditional" web development practice of including minified versions of all of your code and libraries in the correct order via script tags at the bottom of your page. Modules are gaining momentum on a daily basis and ES6 along with build systems like Babel are slowly taking over the web dev landscape. We use requirejs ourselves, but there are tons of options out there.
An example of an application built this way is the Cesium Viewer example in Build\Apps\CesiumViewer (source is in Apps\CesiumViewer). The entire built app (uncompressed) is 8.77 megs and exposes pretty much every Cesium feature and capability. 3.65 megs of that is the Natural Earth imagery that ships by default and other data files that the app only pulles down on demand if you use a feature that triggers it. The remaining JavaScript is greatly reduced in size by gzipping compression on the server end. To see this for yourself, run the latest Cesium Viewer link and open the network tab in your browser dev tools. The entire app only sucks down 2.2 megs (and that includes the initial imagery being loaded from Bing. The Cesium portion is only about 426kb. It might suck down a few extra kb if you start loading GeoJSON or KML files, but not much.
Since a module based approach requires additional set up and is still not that common in web development overall, we also supply the Build/Cesium and Build/CesiumUnminified folders. These included fully minified and concatenated versions of Cesium that suck all of the modules into a single file. However, you need more than just the Cesium.js file for deployment. Here's a break down of these folders:
Build/Assets -> The default imagery/assets that ship with Cesium (imagery/icons/stars/data for ICRF transformations). This data is pulled down as needed depending on how you configure your Cesium application. It's 3.65 megs, but chanes are your app will only ever touch a few kb of that (depending on the features you use). Rather than try and determine what to deploy to the server, I suggest deploying the entire directory (but as I said, the client may never retrieve most of it).
Build/Workers and Build/ThirdParty -> These contained the concatenated web workers used by Cesium. This includes code used by imagery/terrain, geometry tessellation, and zip file handling. It's pulled down on demand and even if you did something to require all of it, is still under a meg gzipped. These files can't be included in the primary Cesium.js because of the nature of WebWorkers (In our opinion this is a difficiency in the spec).
Build/Widgets -> contains the concatenated CSS, both in inidividual widget form and in a combined widgets.css file. I recommend just including widgets.css and be done with it (4kb gzipped); but if you are really concerned about size you can bring down individual css files. This folder also contains icons used by the various widgets. Once again, they are only retrieved from the server if needed.
As their names suggestions, Both Build/Cesium and Build/CesiumUnminified are pretty much the same thing. The main difference is that Build/Cesium has been minified and is much smaller. It is also faster because it has a lot of debug code removed in order to improve performance. Our official recommendation is to develop against CesiumUnminified and deploy using Cesium. This will make it easier to develop because you'll get better error handling and callstacks if there are problems in your code.
An example of an application built this way is the Hello World application link. There's actually not much size difference from the built Cesium Viewer app I linked above, but that's because they are essentially the same application built two different ways.
So this answer ended up being a lot longer than I wanted it to be, but Web Development is varied and Cesium tries to do its best to support all of its different approaches. Cesium itself is also incredibly ambitious so we've had to overcome a lot of hurdles that other projects never encounter. Is there room for improvement, absolutely, but we go out of our way to ensure that Cesium is as light as it can be while delivering the features that it has. I think in a 2.0 version we will probably take this even further and try and make things more modular.
I hope that answers your questions and concerns.
I'm building a library, and plan to use parts (could be entire files or arbitrary lines) of other libraries in my code. Also, I would like to have fixes on the other library reflect onto my library as well.
I could just add the entire library (script tag, AMD, etc.) and use it. But I don't want to use the entire bulk of another library for my very small library. One of these libraries is Modernizr, but I'll only be using at most a dozen checks only.
I could just copy-paste the implementation from one library to mine. However, when the library I need updates, this would mean copy-paste all over again.
I read about GIT and submodules, where a subfolder could contain a sub-project. This sounds promising, where a build script could extract parts of the other library and put it into my code. However, the library could have different code structure than mine which would lead to manual editing, which defeats the purpose of some steps.
I haven't gone that deep into automation but I have had basic experience with makefiles. How would one go about in doing such integration?
It's not generally a good idea to use parts of libraries that didn't pre-package those parts for you. The correct way to do it would depend on each library and how it is meant to be made/compiled. There may also be license considerations, which will vary depending on the license of the library, some would require maintaining the license for the part of the library that you use.
[Edit]
Would it be possible to include the entire other libraries, and then use some sort of minification on your library to keep the size down?
I was tasked with figuring out how to package JavaScript and CSS into one file per each. We have a java servlet application and we use JQuery if that makes any difference. We use ant to script our builds, so easy integration with Ant would be nice. We want to do this to reduce caching issues and to reduce number of requests to the servlet.
I found few tools out there, but not sure what are pros/cons of each. Here is the list so far:
JAWR (http://jawr.java.net/)
Juicer
(http://cjohansen.no/en/ruby/juicer_a_css_and_javascript_packaging_tool)
JSBuilder2
(http://www.sencha.com/products/jsbuilder/)
JSLint
(http://code.google.com/p/jslint4java/)
(JavaScript only)
Quilt
(https://github.com/kitgoncharov/quilt)
(JavaScript only)
Do you guys have any recommendations, warnings, advices? Or maybe a better tool/framework?
Thanks in advance!
For JavaScript, the closure compiler integrates with Ant. It can concatenate and minify your JS. You can also use YUI compressor. Here's an example of using YUI compressor with Ant for JS and CSS.
By far my favorite template is HTML5 Biolerplate The build script there is pretty good as a template.
Also, versioned files with long cache times will greatly improve load times.
Replace "being nice" with "a must". You absolutely want something that integrates with your build tool since you do not want to minimize your files manually again and again and again and again and again and again and again and again and again and again.
Jawr - very nice library, makes everything for you, simple to integrate (at least with its Grails PLugin).
The small problem, I havn't found a way (may be it exists) to integrate ALL bundle's dependencies in a single file. (if you don't have dependencies between bundles (modules), you won't regret this decision).