Did anyone has the comparison between these two libraries (Combres2 and SquishIt)? If one library is better than another one, I also want to know the reason for that.
I found the article said that Combres2 has a better compression than SquishIt. But it is almost a year ago.
http://blog.buzzuti.com/post/Combres-vs-SquishIt-e28093-A-battle-of-Minification-Combiner-and-Squishing-in-generale280a6.aspx
One thing to make note of is that SquishIt works in a different manner than Combres2, so it isn't a simple who produces better minified code.
SquishIt works very nicely with T4MVC, which you won't get with Combres2. On this basis alone I'd tell anyone to use SquishIt. Additionally, SquishIt is not xml config file based, which allows for a lot of flexibility. In fact, you could theoretically make an xml config file and mimic Combres2 if you really desired it.
In terms of minification SquishIt is actively developed, which means that if new methods to minify scripts are created you'll be more likely able to leverage that as well. Currently it supports JSMin, YUI, MS Ajax Minifier, Closure Minifier, or even no minifier.
Update 1/18/2012: There are now many other alternatives out there aside from SquishIt and Combres2. For starters, Microsoft is creating there own system for the next release of ASP.NET 4.5. Cassette, similar to SquishIt, and RequestReduce, which is quite different than anything else by automagically doing everything for you.
I'm a fan of SquishIt.. even though Combres and SquishIt both (optionally) use the YuiCompressor.NET library (which I am biased, for ;-) )
Being a fan of Justin Etheredge, I recommend/use SquishIt.
The reasons to one library is better than the other (for me) is if the final result is NOT a break code and still working.
I have test and working with the Microsoft Ajax Minifier, and I assure you that is working absolute correct - can even minifie the jQuery library with out any issue.
http://ajaxmin.codeplex.com/
http://aspnet.codeplex.com/releases/view/40584
documentaion:
http://www.asp.net/ajaxlibrary/AjaxMinDocumentation.ashx
Now if a library is one year old this have nothing to do, because they just working on javascript code that have some standards some years now.
To point again out : the better is the one that product minimum code that is still working under very complex javascript functions like the one jQuery have.
One note:a minified library can minified a full set of files at ones, do not try to minified one by one and them add them to a single file, this is not working.
This is meant as an answer to the 'Microsoft Ajax Minifier' recommendation, and a general warning for those that do so. As my reputation is a mere 41, I cannot add the comment there, where it should go. :(
For our team, the native C# VS2017 Microsoft compression (which may or may not be the same as the one labeled as 'Microsoft Ajax Minifier') failed on the css function 'calc', and badly.
That was a bit tricky to track down, since the error (obviously) only occurs during minification. And since we were minifying based on environment (interwoven with Release, Debug), that meant the calc bug (by default) never appeared on local. It just magically appeared when we pushed to production... and only on pages that used the calc function.
(Definitely agree that minimum code add-on is fantastic. But the native minifier can be faulty. So proceed with caution.)
If you are not using 'calc' (and you are noticing no other issues), then likely your team is fine with the default minification tool.
And of course, Microsoft could have fixed the bug since we discovered it. But bug reporting through msdn doesn't always lead to resolution of the issue. :(
There may be other issues. But in our case (since we use 'calc'), that was sufficient to have us investigate other minifiers, and SquishIt has been our team's choice. We had not looked at Compres2 at that time. Up until now, we've been very happy with SquishIt.
Side note: I'm in the middle of investigating minifiers again because of some sort of 'collision' between jQuery 3.6.0 and SquishIt for VS2017. (with no 'collision' between jQuery 3.4.1 and SquishIt, VS2017). Early stages of problem-solving process.
Best wishes and happy coding,
Michael M.
Related
The HTML/JS .aspx pages in my ASP.NET application use the MicrosoftAjax.js file like :
<script src="../../Scripts/MicrosoftAjax.js"></script>
Considering MicrosoftAjax.js is very old, I want to replace the MicrosoftAjax.js file with TypeScript (.ts) file and serve the same purpose. I am a bit not clear how complex this change would be and its impact as I am not much familiar with Typescript.
Are there any specific steps that i can follow to do this change ?
Well, you can download the ajaxcontrol tool kit source code.
All of the JavaScript routines are included.
thus, you could thus try and modify the toolkit source code to use TypeScript.
but, unless you willing to modify that code, look at the code, and play with the source code?
Then why bother with TypeScript. I mean, you MUST be adopting TypeScript for a reason - like say NEW software development?
I mean, why do you care if the jQuery, or jquery.UI library that SO MANY use in their projects is TypeScript or not?
Answer:
You don't give one hoot - do you?
Unless you plan to active modify that JavaScript library, and make changes.
If you not planning to make changes to that code, then I see ZERO reasons to worry about that code being JavaScript, or some .net "layer" is tossed on top called TypeScript to (hopefully) make writing your JavaScript easier.
I mean, I am looking at TypeScript, since writing JavaScript tends to suck HUGE!!!
Here we are with the fantastic .net framework, classes, great and fantastic type checking, strong data typing, and then we have to jump down to writing JavaScript with all of its warts, and INCREDIABLE PAIN and suffering when writing js code. It is beyond pain - it just is.
Now, don't get me wrong - we all as developers have to mess with js code. And that js gives us the abilities to write really nice interactive and responsive web applications. So amazing are the results, that we now can actually provide, and write and build applications that give EVEN BETTER user experiences then even what desktop software offers (at least in most cases - business applications). So I LOVE what client side JavaScript code can do for us - but this huge mess of JavaScript libraries - ever growing? It is killing the browser performance right now - and increasing load times - it is a mess our industry has to deal with. (and Blazer looks to be that solution).
So, I have now
AjaxToolKit - tons of JavaScript library routines
jQuery - a ton more of JavaScript library routines
jQuery.UI - a ton more of JavaScript library routines
jQuery.toast - a ton more of JavaScript library routines.
bootstrap.js - a ton more of JavaScript library routines
And so on!!!! (probably left out a dozen more!!!!).
I mean, REALLY when is this madness going to stop!!!
Exactly how many external js libraries do you expect me to have to adopt?
But, NOTE VERY careful - library routines!!!!
That means this is code I don't maintain and modify and care about.
(so who cares if that external library code is Typescript or not???)
There is NOTTHING stopping you from using TypeScript for YOUR code, but who gives one hoot about all the above external library code routines - why not just use them?
In fact, this is quite much why I can't wait to get up to speed with blazer. Blazer might be REALLY cool because I can now run my .net code client side. (how cool is that!!!) - no more JavaScript code!!!! Our savior has arrived!!!
But, what is MORE valuable in Blazor is not that you can write .net code (c# right now - hopefully they will add vb.net some day - but it don't look like that will occur).
The HUGE value is I can now dump that train wreak of having to adopt a gazillion external script libraries, and now use ONE seamless language for both server side code, and client side code. No more JavaScript, but MORE important I can then adopt pure nice clean .net code - and that code will be for both ends. And that means things like say moving a class object from server side to client side - and I don't have to muck around with JSON, or serialization , or anything - it all the same code, and thus moving data types from server to client side becomes not only near automatic, but seamless, and the same language. and it runs at compiled speed browser (client) side. Blazor has the potential to get rid of ALL THAT nonsense, including that of killing the browser side with a NEVER ending and EVER growing list of external JavaScript libraries to just build a decent working web page.
It is the galactic mess of all these libraries, and killing the browser with that truckload huge payload of external libraries that is the big mess right now.
Blazor has the potential to just toss ALL OF THAT hair ball mess out the window.
Now WHY do I mention the above? Well, if you going to consider modifying the ajax tool kit source? I would consider a migration to Blazor - and not TypeScript.
But, then again, we STILL not answered why you care?
I see ZERO advantage to change the jQuery libary code, or in this case the ajax control tool kit to using typecript UNLESS you going to actively modify the source of that external libary in the first place.
I mean, why do you give one fying hoot that jQuery, or jQuery.UI is JavaScript, or some layer on top called TypeScript is being used? (perahps bettr inteli-sense???).
So, the tool kit is open source.
I did in fact modify the ajax file up-loader.
I needed two things:
First, I wanted the time remain for a up-load (who left out that feature!!!!).
But then again, that is the beauty of the ajax tool kit - it is open source. So, now my up-loader shows the time remain like this:
And the other missing feature? Well, the 3 events for the ajaxfile up-load. I wanted to be able to pass values from the up-loader to the server side events. So, I modified the events, and now I can pass a jason string - that effective allows me to pass a "class" up during the up-load process.
Now, could have I decided to spend all that extra time to make this code work as TypeScript? Gee, that would be quite a bit of messing around and extra time.
But, the fact that I already use all those external libraries (jQuery, jQuery.UI and a bunch more? I don't see the need or goal here.
We all use truckloads of those externa js libraries. Unless we plan to active MODIFY such code, then TypeScript gives ZERO value to me as a developer.
And adopting TypeScript in YOUR code does not prevent you from using and consuming that boat-load of externa js library code that you FOR SURE are using these days.
So, to answer your question?
If you want to download a copy of the ajaxtool kit, and add type script tags, and re-compile the whole tool kit on your own - and with Type Sciprt?
Sure, go ahead, but I fail to see the goal here unless you actually willing to download the source and you plan to active modify and mess around with the source code.
If you JUST going to continue to use all those external library code, then I see zero advantages to bothering with TypeScript in those external libraries - just use TypeScript FOR YOUR code development - not everyone's else JavaScript library code that you now using anyway.
I mean, do you care that jQuery, or bootstrap.js is TypeScript? Don't' think so.
But hey, the ajax tool kit is open source. You can jump right in to modify that library code, but I don't see any benefits to doing so.
I need to get my Meteor JSapp in more than one language.
What would be the best approach for i18n?
Google passed my quite a bit of results but reading them I am more confused than happy. There a many hacks but is there a settled solution to this?
This is more a comment than an answer (however my repu still is too low :o):
Localization normally is only needed client side (there are exceptions but not many and they can be dealt with) and as Meteor is quite young with an own templating engine it's normal that you find more hacks than stable solutions.
However you can doge that bullet by using an older client side templating technique than Meteors built in one like AngularJS with Angular-Meteor (http://angularjs.meteor.com/). Personally I can just recommend this project as it gives you a lot more power than Blaze alone does. And now when you look for solutions for localizing AngularJS you will find a lot more. One I can recommend is angular-gettext (https://angular-gettext.rocketeer.be/) which also comes with a grunt script to extract and compile your strings in one click and which builts a .pot file so that you can translate your app with PoEdit just like you would with an old school webapplication. The only thing you may need to do yourself is to extend the grunt script to parse for any custom translation functions you may add (but maybe you can live without those than you wouldn't need to do anything).
I had an idea for "cheap" version control of the css of one of my sites, but am thinking it may not be a good idea. Thought I'd throw it out here in case someone has a similar idea that works better (besides real svn, etc.)
My thought was to create a main css file like "sitename.css" then use #import inside this file to connect to the most recent file with updates. I'd name these imported files by date, eg: 20101222_css.css so I'd know when the last update was applied. When I have a change, I could make my edits, drop the update in the respective location, change the #import to the new file, and viola... updated on the site.
After reading about issues with #import, such as it loading AFTER the page finishes, I'm not too keen on this now.
Any ideas of a way to implement something similar without a full blown system? I do a lot of small project work for various people and thought this method may be a simple way to keep track of things.
Thanks for any ideas/suggestions.
Your idea would add additional page loads to your site for no good reason, which will be a performance hit. It would also expose your versioning to the outside world. And as you say it will suffer from slow loading speeds due to the way #import works.
But the real down-side of this technique is that it only works for CSS files. You haven't solved the problem for any other files on your site.
You seem to think it would be simpler to use than a real SVN setup, but if you end up coming up with different techniques like this for every type of file on your site, you could easily end up giving yourself more headaches than you solve.
SVN is actually quite straightforward to use. With a good GUI (try TortoiseSVN), it's so easy you almost forget its there. Seriously, use SVN. There's no need to come up with 'clever' alternatives.
Its not a good idea, especially if you push this into production. If you want "cheap" version control, download VisualSVN. Its free.
The guys at Yahoo use a technique that reminds me of what you describe:
<link rel="stylesheet" type="text/css" href="http://l.yimg.com/a/combo?arc/yui/reset_2.6.7.css&arc/yui/fonts_2.6.4.css&[....]/subfooter_0.0.12.css" />
It makes sense for them because it's a caching tecnique. They set HTTP headers so stuff never expires: if you load the site one year later and you haven't removed your browser's cache, you shouldn't need to fetch again any of the files that haven't changed.
However, it's by no means a sensible version control system. You already have a good bunch of real version control systems out there!
We have a flex based UI whose functionality (eg: login, logout) needs to be tested periodically in IE 7. Manual testing takes a lot of time and hence we want to automate it.
EDIT: We dont have the source code of this app uder test so cannot use something like FlexUnit. Is there a way to automate this testing?
I have heard of FleXmonkey, but have read negative reviews of it and hence wary of trying it.
EDIT: source of negative review:
Automated testing of FLEX based applications
(Comment by Ryan H)
Please suggest if theres a way to go about it.
EDIT: An open-source solution is preferred.
Thank you.
You won't get very far in your development adventures if you avoid reviewing things just because you read negative reviews. ( Please provide a source for said negative reviews ). I've also read bad things about Flex and Flash Builder and the Flash Player. Yet, you still ended up using Flex?
That said, I strongly suggest checking out Flex Monkey.
RIATest is another option.
I believe you can also do this sort of testing with QTP. I couldn't find a specific source for QTP info, but there are a few links if you google.
http://www.learnqtp.com/does-quicktest-professional-support-flashadobe-flex-applications/
http://vishnuagrawal.blogspot.com/2009/04/flex-automation-testing-with-qtp.html
Without recompiling the source code, it is not possible to test Flex in all cases. Saucelabs IDE claims that it can test Flex without recompiling the code. You may check that.
I think FlexMonkey is pretty cool and worth judging on your own. Most of these tools use the same underlying automation framework provided by Adobe, and thus have many of the same pains and challenges. We've actually done a lot the last few months to make it easier to work with and have been working to provide more documentation on dealing with common challenges.
If you do have problem, you will find that our Forums are very active with questions and answers: http://www.gorillalogic.com/forum/7
-Jon Rose -
Gorilla Logic, Inc
Some Flex automation tools support testing of Flex applications without requiring to recompile it.
RIATest definitely supports it (called runtime loading) and if I am not wrong QTP does it as well. AFAIK there are no open source tools that support it.
Beware though that runtime loading is not for every application. If for example you are using custom html wrapper you cannot use it with runtime loading.
I've been working on a project called Axial that converts MSIL (compiled C# or VB.NET) to JavaScript. There are a few samples of working code, but some common situations don't work properly. (The current release doesn't work in production mode and the SVN code doesn't work in debug mode but is much cleaner.) I've heard from quite a few people that they hate writing JavaScript, so I know the project has some merit, but I'd guess that attitude is less prevalent among the SO community.
Assume the product works perfectly and smoothly, so your JavaScript works 100% of the time and a Visual Studio plug-in makes sure you're using the product correctly. Is this something you or your organization would use? What features other than straight code translation would interest you?
That sounds very much like a .NET-centric version of GWT. I guess the questions are:
Have I understood the purpose correctly?
Do you believe you can overcome any roadblocks that GWT users might stumble over?
Is there enough benefit in having a .NET version as well as GWT to make the duplication of effort worthwhile? (I'd personally just write the Java code and use GWT, but I know not all .NET developers know Java, and you may already have common library stuff you want to port.)
Do you have any useful ideas you could contribute to GWT? :)
(Disclaimer: I work for Google, but haven't used GWT myself.)
Been done (pretty much).