I already using the minify argument when building with dart2js.
I looked at the output and I see that the import 'dart:html causes problems in terms of the output file size (2kb .dart file becomes 182kb .js file). For example it imports SVG package though in my code I never touch any <svg> DOM Elements.
I understand that the compiler doesn't know if I'm going to use svg DOM Elements or not. And I understand that the using of var is one of the reasons of that behavior.
But if I will not use any var keywords, the compiler still doesn't have enough 'power' to strip all unused packages and functions.
Is there any directive I can use to forbid the import of certain packages. I mean built-in packages right now. I'm using IntelliJ IDEA and it doesn't allow me to change anything in the Dart default setup.
UPD: Tried to use
import 'dart:html' show querySelector, Element
to import only that method and class, but file size is still 182kb.
The only solution I see for now is to make a few stripped versions of the default 'dart:html' package. The one without WebGL, SVG and some other features.
Because maybe Dart compiler works good, but there is just some methods and classes that I don't use, but the code uses. Like.. the initial package methods checking if some elements are SVG or something like that.
There is a tool for analyzing the output of a dart2js build, especially for references and dependencies. Just tested and gave a better overview in my case.
https://github.com/dart-lang/dump-info-visualizer
hosted :
https://dart-lang.github.io/dump-info-visualizer/
Build with option --dump-info
https://webdev.dartlang.org/tools/dart2js#options
Even when you don't import anything you will get some minimal output size. Dart provides a lot of features like classes with inheritance and mixins (and a lot more) and dart2js output contains code that implements these features.
This is like adding a JS library like jQuery.
Therefore main() {} will already result in an output size of several dozen kb. Adding another line of code probably will only add a few additional bytes.
pub build by default does tree-shaking and minifications, therefore no additional options are required.
I am currently trying to get to grips with bootstrap and am struggling to understand where I should be editing the CSS. I created a custom.css.scss file to edit settings in my app/assets/stylesheets folder however when I add rules they often seem to be overridden as such I have found that I have to edit certain elements by going to the external libraries bootstrap-sass resource and drilling down to the ../stylesheets/bootstrap folder where I then have to hunt for the relevant style to change. I am sure I am doing this the wrong way, is there something I should be doing to ensure my custom.css.scss has priority? Any help much appreciated!
You don't want to edit the bootstrap files themselves, but CSS rules have a precedence structure which determines which CSS rules are used. It is not terribly complicated, but is a bit tricky until you get the hang of it.
Smashing Magazine has a relatively good introduction to it with links to other sources as well.
In the application.css found in the assets all other styles are included you just need to change the order of these like mentioned here: Rails 3.1 Load css in particular order.
I've been reading O'Reilly book "Dojo - The Definitive Guid" but somethings are still not definitive to me.
They talk about "bootstrapping" and getting the dojo.css from the AOL CDN".
When I'm testing on my machine, should I use the CDN? Or should I wait and use that only when I deploy?
Secondly, the book talks about CDN for dojo, but not for dijit.
I'm developing on Google App Engine (GAE) - so having the 2000+ Dojo/Dijit files in my Javascript directory is a little annoying, because it slows down my upload to GAE each time.
Firebug is giving me this error:
GET http://localhost:8080/dijit/nls/dijit-all_en-us.js 404 not Found
GET http://localhost:8080/dijit/_editor/plugins/FontChoice.js 404 not Found
I downloaded the sample from here:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html?theme=soria
and I'd like to "simply" get it to run on my machine under local google app engine (which is the localhost:8080 that you see in the URLs above).
I see this statement which probably is causing the second 404 above:
dojo.require("dijit._editor.plugins.FontChoice");
One other error:
cannot access optimized closure
preload("en-us") dijit-all.js (line 479)
anonymous("dijit.nls.dijit-all", ["ROOT", "ar", "ca", 40 more... 0=ROOT 1=ar 2=ca 3=cs 4=da 5=de 6=de-de 7=el 8=en 9=en-gb])dijit-all.js (line 489)
dijit-all.js()
dojo.i18n._searchLocalePath(locale, true, function(loc){\n
To continue for now, I'm going to try to copy the entire dijit library, but is there a solution short of that?
My current script includes look like this:
<script type="text/javascript" src="/javascript/dijit.js"></script>
<script type="text/javascript" src="/javascript/dijit-all.js" charset="utf-8"></script>
I got the dijit.js file by copying and renaming dijit.js.uncompressed.js to dijit.js.
You have a few options actually:
You could use the CDN for everything (though using the full source locally does give you better error messages). Google has them as well. Dijit is here: http://ajax.googleapis.com/ajax/libs/dojo/1.3.2/dijit/dijit.js FYI. This has many advantages in my opinion. User caching of the JS being the primary one.
Build a layered file. I think the O'Reilly book has a section about it but the PragProg book is better in this regard IMO. There's also this doc on dojocampus.org about building. This will trim down the files you need to upload to GAE and speed up your app loading. This is actually what I do in order to cut down on HTTP requests.
Keep doing what you are doing. :)
Regarding the errors you are seeing about 404 for en-us files are essentially harmless. Here's a better description.
You also might be reloading dijit files by using dijit.uncompressed.js and dijit-all.js and causing problems in the process...but I'm not sure about this one.
I just want to clarify that when using CDN all you need to include is the main Dojo script. The rest will be pulled in automatically when you dojo.require() them.
If for some (technical) reasons you don't want to use the X-Domain loader (CDNs use this type of loader), you can do a custom build (well-described in many places). After the build you copy only relevant files to your server. No need to copy all 2000+ tests, demos, unused DojoX projects, Dijits and so on.
During the build you will create a single minified file (or a few layers), which will include all Dojo JavaScript code you use. If you use Dojo widgets, their templates will be already inlined, so you do not incur hits for them. As part of the build CSS files are combined together and minified too. So literally in most cases you will have just two files: a Dojo layer, which includes everything + your custom code, and a CSS file. In more complex cases you may have more files, but usually we are talking about handful.
How to make sure that everything is in the build? Fire up your favorite network analyzer (Live HTTP Headers, Firebug, Fiddler2, or Charles Proxy would do fine) and see if you hit any files outside of your build. If you do — include them in the build, or try to figure out why they are requested, and eliminate these requests (some localization-related calls are fine).
Personally I would start with the CDN option — works well, no hassle, hosted by somebody else with fat pipes.
To address your first question, use the full source version locally for development, so that you can get clearer debug info which points to a legible line in source, rather than the single line the minified version is reduced to. Use the CDN for production.
I'd love to ask you how do the guys developing dojo create the documentation?
From nightly builds you can get the uncompressed js files with all the comments, and I'm sure there is some kind documenting script that will generate some html or xml out of it.
I guess they use jsdoc as this can be found in their utils folder, but I have no idea on how to use it. jsDoc toolkit uses different /**commenting**/ notations than the original dojo files.
Thanks for all your help
It's all done with a custom PHP parser and Drupal. If you look in util/docscripts/README and util/jsdoc/INSTALL you can get all the gory details about how to generate the docs.
It's different than jsdoc-toolkit or JSDoc (as youv'e discovered).
FWIW, I'm using jsdoc-toolkit as it's much easier to generate static HTML and there's lots of documentation about the tags on the google code page.
Also, just to be clear, I don't develop dojo itself. I just use it a lot at work.
There are two parts to the "dojo jsdoc" process. There is a parser, written in PHP, which generates xml and/or json of the entirety of listed namespaces (defined in util/docscripts/modules, so you can add your own namespaces. There are basic usage instructions atop the file "generate.php") and a Drupal part called "jsdoc" which installs as a drupal module/plugin/whatever.
The Drupal aspect of it is just Dojo's basic view of this data. A well-crafted XSLT or something to iterate over the json and produce html would work just the same, though neither of these are provided by default (would love a contribution!). I shy away from the Drupal bit myself, though it has been running on api.dojotoolkit.org for some time now.
The doc parser is exposed so that you may use its inspection capabilities to write your own custom output as well. I use it to generate the Komodo .cix code completion in a [rather sloppy] PHP file util/docscripts/makeCix.php, which dumps information as found into an XML doc crafted to match the spec there. This could be modified to generate any kind of output you chose with a little finagling.
The doc syntax is all defined on the style guideline page:
http://dojotoolkit.org/reference-guide/developer/styleguide.html
I am still struggling to find a good naming convention for assets like images, js and css files used in my web projects.
So, my current would be:
CSS: style-{name}.css
examples: style-main.css, style-no_flash.css, style-print.css etc.
JS:
script-{name}.js
examples: script-main.js, script-nav.js etc.
Images: {imageType}-{name}.{imageExtension}
{imageType} is any of these
icon (e. g. question mark icon for help content)
img (e. g. a header image inserted via <img /> element)
button (e. g. a graphical submit button)
bg (image is used as a background image in css)
sprite (image is used as a background image in css and contains multiple "versions")
Example-names would be: icon-help.gif, img-logo.gif, sprite-main_headlines.jpg, bg-gradient.gif etc.
So, what do you think and what is your naming convention?
I've noticed a lot of frontend developers are moving away from css and js in favor of styles and scripts because there is generally other stuff in there, such as .less, .styl, and .sass as well as, for some, .coffee. Fact is, using specific technology selections in your choice of folder organization is a bad idea even if everyone does it. I'll continue to use the standard I see from these highly respected developers:
src/html
src/images
src/styles
src/styles/fonts
src/scripts
And their destination build equivalents, which are sometimes prefixed with dest depending on what they are building:
./
images
styles
styles/fonts
scripts
This allows those that want to put all files together (rather than breaking out a src directory) to keep that and keeps things clearly associated for those that do break out.
I actually go a bit futher and add
scripts/before
scripts/after
Which get smooshed into two main-before.min.js and main-after.min.js scripts, one for the header (with essential elements of normalize and modernizr that have to run early, for example) and after for last thing in the body since that javascript can wait. These are not intended for reading, much like Google's main page.
If there are scripts and style sheets that make sense to minify and leave linked alone because of a particular cache management approach that is taken care of in the build rules.
These days, if you are not using a build process of some kind, like gulp or grunt, you likely are not reaching most of the mobile-centric performance goals you should probably be considering.
I place CSS files in a folder css, Javascript in js, images in images, ... Add subfolders as you see fit. No need for any naming convention on the level of individual files.
/Assets/
/Css
/Images
/Javascript (or Script)
/Minified
/Source
Is the best structure I've seen and the one I prefer. With folders you don't really need to prefix your CSS etc. with descriptive names.
For large sites where css might define a lot of background images, a file naming convention for those assets comes in really handy for making changes later on.
For example:
[component].[function-description].[filetype]
footer.bkg-image.png
footer.copyright-gradient.png
We have also discussed adding in the element type, but im not sure how helpful that is and could possibly be misleading for future required changes:
[component].[element]-[function-description].[filetype]
footer.div-bkg-image.png
footer.p-copyright-gradient.png
You can name it like this:
/assets/css/ - For CSS files
/assets/font/ - For Font files. (Mostly you can just go to google fonts to search for usable fonts.)
/assets/images/ - For Images files.
/assets/scripts/ or /assets/js/ - For JavaScript files.
/assets/media/ - For video and misc. files.
You can also replace "assets" with "resource" or "files" folder name and keep the name of it's subfolders. Well having an order folder structure like this isn't very important the only important is you just have to arrange your files by it's format. like creating a folder "/css/" for CSS files or "/images/" for Image files.
First, I divide into folders: css, js, img.
Within css and js, I prefix files with the project name because your site may include js and css files which are components, this makes it clear where files are specific for your site, or relating to plugins.
css/mysite.main.css css/mysite.main.js
Other files might be like
js/jquery-1.6.1.js
js/jquery.validate.js
Finally images are divided by their use.
img/btn/submit.png a button
img/lgo/mysite-logo.png a logo
img/bkg/header.gif a background
img/dcl/top-left-widget.jpg a decal element
img/con/portait-of-something.jpg a content image
It's important to keep images organized since there can be over 100 and can easily get totally mixed together and confusingly-named.
I tend to avoid anything generic, such as what smdrager suggested. "mysite.main.css" doesn't mean anything at all.
What is "mysite"?? This one I'm working on? If so then obvious really, but it already has me thinking what it might be and if it is this obvious!
What is "Main"? The word "Main" has no definition outside the coders knowledge of what is within that css file.
While ok in certain scenarios, avoid names like "top" or "left" too: "top-nav.css" or "top-main-logo.png".
You might end up wanting to use the same thing elsewhere, and putting an image in a footer or within the main page content called "top-banner.png" is very confusing!
I don't see any issue with having a good number of stylesheets to allow for a decent naming convention to portray what css is within the given file.
How many depends entirely on the size of the site and what it's function(s) are, and how many different blocks are on the site.
I don't think you need to state "CSS" or "STYLE" in the css filenames at all, as the fact it's in "css" or "styles" folder and has an extension of .css and mainly as these files are only ever called in the <head> area, I know pretty clearly what they are.
That said, I do this with library, JS and config (etc) files. eg libSomeLibrary.php, or JSSomeScript.php. As PHP and JS files are included or used in various areas within other files, and having info of what the file's main purpose is within the name is useful.
eg: Seeing the filename require('libContactFormValidation.php'); is useful. I know it's a library file (lib) and from the name what it does.
For image folders, I usually have images/content-images/ and images/style-images/. I don't think there needs to be any further separation, but again it depends on the project.
Then each image will be named accordingly to what it is, and again I don't think there's any need for defining the file is an image within the file name. Sizes can be useful, especially for when images have different sizes.
site-logo-150x150.png
site-logo-35x35.png
shop-checkout-button-40x40.png
shop-remove-item-20x20.png
etc
A good rule to follow is: if a new developer came to the files, would they sit scratching their head for hours, or would they likely understand what things do and only need a little time researching (which is unavoidable)?
As anything like this, however, one of the most important rules to follow is simply constancy!
Make sure you follow the same logic and patterns thoughout all your naming conventions!
From simple css file names, to PHP library files to database table and column names.
This is an old question, but still valid.
My current recommendation is to go with something in this lines:
assets (or assets-web or assets-www); this one is intended for static content used by the client (browser)
data; some xml files and other stuff
fonts
images
media
styles
scripts
lib (or 3rd-party); this one is intended for code you don't make or modify, the libraries as you get them
lib-modded (or 3rd-party-modified); this one is intended for code you weren't expected to modify, but had to, like applying a workaround/fix in the meantime the library provider releases it
inc (or assets-server or assets-local); this one is intended for content used server side, not to be used by the client, like libraries in languages like PHP or server scripts, like bash files
fonts
lib
lib-modded
I marked in bold the usual ones, the others are not usual content.
The reason for the main division, is in the future you can decide to server the web assets from a CDN or restrict client access to server assets, for security reasons.
Inside the lib directories i use to be descriptive about the libraries, for example
lib
jquery.com
jQuery
vX.Y.Z
github
[path]
[library/project name]
vX.Y.Z (version)
so you can replace the library with a new one, without breaking the code, also allowing future code maintainers, including yourself, to find the library and update it or get support.
Also, feel free to organize the content inside according to its usage, so images/logos and images/icons are expected directories in some projects.
As a side note, the assets name is meaningful, not only meaning we have resources in there, but meaning the resources in there must be of value for the project and not dead weight.
The BBC have tons of standards relating web development.
Their standard is fairly simple for CSS files:
http://www.bbc.co.uk/guidelines/futuremedia/technical/css.shtml
You might be able to find something useful on their main site:
http://www.bbc.co.uk/guidelines/futuremedia/