Can someone explain why I would want to use the less.js script along with its stylesheet? I don;t understand the purpose and its advantages. Thank you. Erik
Less.js is a CSS pre-processor, it means that you will be able to write your in style using the Less pre-processor languages in a *.less file, then Less.js will compile it into pure CSS.
CSS pre-processor comes with a lot of powerful features such as: variables, mixins, nested rules, operations, imports and a lot more.
With Less.js you have two options:
Running Less at client-side: write your styles in Less then include the JavaScript pre-processor: Less.js.
Running Less at server-side: write your styles in Less then run the pre-processor using Node.js or Rhino, and in other cases you may use some ports like DotLess.
If you have potentially large Web Interface Design (complex layout, sprites, multiple navigation, several forms, etc...) then you should consider using one of the popular CSS pre-processor like Less.js or Sass. They will help you a lot.
Keep in mind... there are big project build on top of CSS pre-processor, Twitter Bootsrap use Less and Compass is a great framework that will kill your aches related to cross-browser issues concerning inline-blocks, clearfix, box-shadow, etc...
Related
I'm using Vuetify Vue3 for a project. There are some components missing that are available in other fw. Does this cause messup in the project by installing extra fw for one component?
You can indeed have several frameworks at the same time, but it may drastically impact your performance and lead to messy code because of the difference in APIs.
If you are meaning, CSS like a UI framework (Vuetify, Bulma, Bootstrap etc...), the answer is the same. Doable but quite heavy.
Nothing stopping you from going crazy by using all of them!
Technically, you can use at the same time, but if you mean CSS frameworks sometimes it can lead to conflict between classes.
It is not recommended and best practice to do that because it can cause a conflict and also can make your application heavy.
But it is not forbidden and you are free to try.
I am currently developing a web application. I am using Bootstrap-vue in frontend. Does Bootstrap has feature in which I can create on-the-fly class? Tailwind has it . I tried searching it in the internet but no luck.
Here is my case:
Color values are save in the database.
Every time the page loads, I will fetch those colors and create class based on their colors
Your help is much appreciated. Thanks in advance.
Bootstrap is not really an utility-based CSS framework, hence there is nothing similar to Tailwind because it's not the mindset of the tool.
Also, even if this kind of code exists in Tailwind, it can become funky pretty quick and the best thing is still to write some bare simple vanilla CSS code alongside your template to get what you want.
You won't get any performance benefit by using an arbitrary value anyway and hence it should be used for exceptional cases anyway, a CSS declaration will be far more cleaner.
Feel free to create global CSS variables in vanilla CSS for your use case.
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
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
i read about the Google Closure Compiler and i will try to use it to make my web application better. But i think it is doing the same things like the dojo shrinksafe.
Has anyone tried to use the Google Closure Compiler for a complex dojo project?
Thanks
Benjamin
Yes, Google Closure Compiler works fine with Dojo projects. Because Closure is derived from Dojo, it has similar concepts (modules, loaders, the build, and so on) so it is potentially possible to use some advanced features of Closure Compiler with Dojo, which go beyond simple minification.
We (Dojo) will evaluate what we can reuse and leverage from Closure and how we can improve interoperability. Obviously it will include all tooling too.
Closure will probably work with any valid javascript code. I fed it an extremely packed, obfuscated version of a complex Prototype project of mine and it spit out a perfectly working version. So even if your code has already been shrinked by Dojo, you can probably use Closure on top of it. You should, however, choose one of the two.
As of Dojo 1.4 (not yet released, but the code is in the subversion trunk of Dojo), you can now use Closure Compiler as an option for the Dojo build process. It takes a bit of setting up. Instructions on how to use Closure Compiler with the Dojo build system.
Dojo 1.6 is compatible (after some minor modifications) with Closure Compiler in Advanced mode.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
Stephen
I happen to have a 12,000 (26,000 if you include dojox/dijit imports) line dojo 1.3.2 application I am about to release.
Well I used the standard dojo build system to throw it all into one lovely big one megabyte file. Then I introduced it to the google closure compiler, the compilation went very well reducing the package down to 350 kb, 100kb less than yahoo ui, and 150kb less than shrinkwrap. I, of course, did it all in advanced mode like a man.
So far so good, then it was time to load it up! The results were mixed. The site did seem to work, but I did get quite a few pesky errors telling me that various things behind the dojo prefix could not be found. I wasn't able to work out exactly what was going on as I didn't have closure addon for firebug ready, but I didn't notice issues the actual operation of the site - though I posit if I looked hard enough I would have found them.
So I thought to myself it appears the closure compiler is renaming dojo name space in my compiled.js to make them inconsistent with dojo.js. It seemed like an ideal solution was to combine dojo.js.uncompressed.js with my blob.js.uncompressed.js using the closure compiler. This resulted in a 51kb reduction in the size of the dojo library so far so good! Bad idea dojo didn't much like this at all and refused to load! It just downloaded then just sat there in protest of google's world domination.
I have done some further research into this matter, from what I read dojo 1.4.0 does support closure in 'simple' mode, but this is rather pointless because as I read closure simple mode provides a similar amount of compression to yui.
Anyway, those are my thoughts, I have looked at closure a little, it looks like a very nice library. The css layout looks drastically simpler than dijit's, this is something I am very fond of, I've often found it easier to rewrite dijits than try and theme them correctly. It seems to be missing some elements of the dojo library I am rather fond of such as dijit._Widget, dijit. _container/contained and of course the famous dojo.declare(). I suppose I could rebuild these, but why should I?
Addition:
Oh it also appears to be lacking a good RPC, cometed framework, and publish/subscriber framework. Unless I am mistaken. Don't get me wrong I want to like closure, I'm not a dojo apologist by any stretch of the imagination, I just like these parts of dojo. The addition of require and provide does make this a serious contender from my perspective. The lack of a meaningful system of this nature drove me away from jquery.