Having been inspecting a few elements on Google, i noticed that their naming conventions are fairly funky, ie.
.n-Wa-q-Dc, .n-xb .n-Wa-q-Dc:hover
This is clearly not readable/manageable by a human. Is it the opinion that Google's CSS and class names are largely auto generated by server side technology.
I cant see people maintaining such a CSS file myself.
Would it be advisable for such a large system (Google) to have any people managing the CSS and just to let the systems handle it?
They should have a version that is human-readable (for development) and, from that, generate the obfuscated version (for deployment). Most likely, a search-n-replace is performed on the names of the scripts or stylesheets (from using human-readable to obfuscated ones) before deployment.
It looks as though they probably ran their css through a minifier to reduce the size of the css file. As
Related
The Html Imports standard uses <link rel="import" href="my-component.html">
What was the reasoning for using the <require> tag
The reason I am asking is that my editor supports web components import tag but not the custom require tag
Thanks
The require tag gets linked to Aurelias loader. When you require a path there are some conventions in place that allow Aurelia (or SystemJS) to get multiple resources such as html, js, and css from a single require tag.
This is especially handy for custom elements and cases where you have nested templates containing require tags. Aurelia is aware of their composition and can determine the exact paths for the resources you requested.
Trying to answer this myself. This is what I am seeing at this point.
In September, 2015, Aurelia blogged that "it has become clear that the HTML Imports part of the specs is not going to become standardized."
I've seen comments within github issues that Google is the only one who really wants to standardize HTML imports with the link tag. While the browser support available seems to support that, I can't verify of the browser supplier's intentions or active support, except Mozilla who is openly declaring that they have no plans to ship with it.
W3 github page for webcomponents indicates, "HTML Modules, rebuilding HTML Imports functionality using the ES Modules, are now being planned." That's as of January, 2016.
Aurelia's philosophy appears to be to build on top of the web standards as much as possible. However, those (draft) standards are still very much in flux. I think that Aurelia is just trying to use whatever they expect is most likely to be compliant when the standards are finally published, while also giving themselves as much flexibility to evolve as possible.
The attachment is a screenshot of Chrome Developer Tools when looking at Google+ HTML. Note the ~random classnames:
The source for unreadable identifiers can be:
minification
obfuscation
random Id generation
Google Plus is probably implemented as a GWT (or similar framework) application with minified resources (javascript and css files) and automatically generated identifiers. Minification is also widely used as a tool for obfuscating the code so the unreadability is partly intentional too.
Obfuscation can be used to reduce code size, as well as reduce code readability for an "unauthorized" user to make it harder to reverse-engineer a product/program or steal ideas. Someone asked a pretty similar question here, that should answer any more questions that you have.
I read Scott Gu's article about built-in support for bundling and minification in ASP .NET 4.5.
However there's no mention of embedded resources, which is a pity.
In the past I've been using a Codeplex project called Client Dependency Framework which supported embedded resources.
Seems like a pretty major omission to me. Is support planned?
I'm pretty sure you could write your own transformer to handle this.
Create a class that implements System.Web.Optimization.IBundleTransform.
Then in the Process method get the contents of the embedded resource. This shouldn't be too difficult. This blog post might be helpful.
Then add the transform to the bundle.
e.g.
var bundle = new Bundle("~/Test").Include("~/Content/Site.css");
bundle.Transforms.Add(new EmbeddedResourceTransformer());
Note that I am using the nuget package from System.Web.Optimization, not Microsoft.Web.Optimization (I have no idea why there are two different namespace implementations, and whether the syntax would be the same in both).
I also can't vouch for the performance of doing it this way as opposed to the file system.
Hope that helps!
Just a few comments on above answers since I don't have enough rep. to comment directly...
The answer from Hainesy suggests using a BundleTransform. I believe this is too late in the process to include an embedded resource. The BundleTransform is helpful for converting things inside the css or javascript after the contents are pulled from the original file and before they are put into the bundled file. For example, if you need to modify image URL's in CSS to point to local relative url for dev and to a CDN url for production.
The link from user960567 explains how to use embedded resources, but there's a catch. That process will only work for something like a common control used from another project.
e.g. If you create a textbox that needs CSS and JS then it allows you to create a HTML helper in the common project that will add the textbox and the script tags that pull in the embedded resource into the page. It does not allow you to pull the embedded resource from the common project into a bundle in another project. This will basically create a separate script or style tag for each embedded resource which may not be what you want (at least it's not what I was looking for.)
I've written a detailed article about how you can use the bundle and minification technology to wrap up your external resources here.
With the tools we have today for assets optimization (for example YUI compressor), how do you automatize it?
For example, I have designed a new website using LESS, so every time I have to edit CSS I have to manually convert them to LESS. The same for Javascript.
So I have to make my PHP project to point to my uncompressed CSS/JS, and when I'm finished, I compress/optimize them, and point my project to the optimized ones again.
I know that there are tools that helps with this (like less.app, which I've used), and that even there are PHP libs that manage all this problem (like Assetic), but I don't like them much. I'm searching for a "programmed" way to deal with optimized assets. Maybe some script that "watches" the uncompressed files or something...
I wish I could have too many alternatives as the Django framework has.
Please, if the question is not well redacted, tell me and we can improve it, so we can establish a good practice for assets :)
I think one efficient solution would be to do this task on the development side, when writting code, and point the code to the optimized files.
One tool that seems to work well is Live Reload (only for OS X, although there is a Windows version on the way).
I like this option as there is no overload on the code to maintain assets.
I'm architecting an enterprise web application using python, django. My final decision to make is which javascript library to use. I'm thinking about using Google's closure library or YUI3. Most of the development, I've used jQuery.I can code fast with jQuery but doesn't seem right for enterprise use.
YUI 3 seems pretty good. It includes most widgets I want to use, but Closure library does almost the same. Better offer with Closure library is they have Closure Compiler, but seems like Closure requires to write much more code than YUI 3. Documentation from YUI 3 is pretty good too.
The application will be for both web and mobile devices, so the library should not break in mobile device such as Android or iPhone.
If you were me, what decision would you make?
Disclamer
I mostly draw on comment about jQuery in enterprise environment and since I lack experience in YUI, I can not give any conscious advice for [not] using it over Closure.
But in lack of any other answers I'll share my experience with Closure.
Closure library
As for Closure library, which I have been using for last few projects but am, by no means, expert at it, I can say only good things.
Library provides the core components you need when building any kind of UI. But, unlike jQuery, it does not come with trillions of "ready-to-deploy" plugin-in scripts, or as some would say, with no batteries included.
It's got basic events, controls, xhr, dialogs, form components etc., and by my account the most important thing, namespaces (or at least something looking like them...).
With this you can create your own custom UIs limited only by your imagination and the power of JavaScript (and JS is very powerful language even if it does have its own annoyances).
And with help of Closure compiler, which not only minifies the code but it excludes all unused code, does type checking, gives warnings useful for debuging and so forth, it looks like solid foundation for building large applications ground up by teams of any size.
In my opinion, main reason for using Closure over jQuery in enterprise projects is consistency. Plugins are awsome but they tend to include inconsistency at all levels, either programming practices, visual styles and structure, performance, usage, you name it. Removing these small inconsistencies on large project can waste lot of time.
So in conclusion, if you have large project needing custom UI and a lot of flexibility Closure is the Right tool for the job. And with "namespaces" it even feels all Pythonish.
P.S. We also use Django on server side.
You have touched on most of the important aspects here, the type checking, minification, namespaces, but I would like to add a few more. Alongside is the templating sollution they offer, which is not only super fast and has full internationalisation support, this mixes in and compresses with the library. It also compiles down to java code so you can render on both the server and the client from the same template.
Then there is the component architecture which has a complete livecycle, seperates renderers from components, (if you are familiar with swing or flex you will get the idea), it has two models, one is client side rendering and the other is decoration which plays beautifully alongside the server side rendering.
The testing sollutions are well defined and now the
We have thousands upon thousands of lines of javascript and without closure it would have been an unmaintainable mess IMO.
I'd go with YUI 3. Especially if the only reason you're considering Google's Closure is the compiler. As this works well in YUI 3, with much better compression than the YUI compresser. I'm sure it doesn't do as good a job as it could with Closure code, but that's pretty hard to test.
The modular framework in YUI 3 is awesome, and there is enough sugar to give you a tooth ache without being too heavy. Yahoo use it for all their sites, and they have a strong emphasis on performance (so it can't be all bad).
In the tests I made, Google Advanced Compress is the better, and after the the Yahoo! YUI Compressor. You can make the tests here:
http://jsperf.com/closure-vs-yui