Develop Reference

Which Anti-XSS library should I use? Microsoft XSS 4.0, Web Protection Library on Codeplex, or other?

Seems like Microsoft updated the Anti XSS library today:
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=f4cd231b-7e06-445b-bec7-343e5884e651
In addition there is a new release of the Web Protection Library
http://wpl.codeplex.com/
Are these two downloads the same thing? What XSS library should I be using?
Are there others I should consider?

Well, as the WPL owner these days I know it's a little confusing, so
The WPL contains two projects, AntiXSS and the Security Runtime Engine. Previous versions installed both, but really they're quite separate and the SRE is an ongoing project which is getting a major rewrite, so rather than hold up the latest changes to AntiXSS whilst I pottered around some more with the SRE we made the decision to split them out, and ship separately.
So right now AntiXSS 4.0 on msdownloads is the most up to date encoding library.
As part of the source push the latest source for the SRE will be pushed as well - however the SRE is still a work in progress, and will remain so for some time, so it'll be source only for a while.
We're still trying to figure out how best to address this in terms of codeplex projects :)

It is the same thing. WPL includes AntiXSS and Security Runtime Engine.
I'm using Microsoft AntiXSS library with my MVC2 application. It integrates nicely and requires no code changes in the views.

Html 5 wysiwyg designer

I am looking for wysiwyg designer that creates applications in html 5 (based on any major JavaScript library like JQueryUI or other).
So far, the only thing I found is Ext Designer:
http://www.sencha.com/products/designer/
but it is still in very early stage and with serious limitations (custom components can not be added to toolbox for example).
Any alternatives?

Well, since the HTML5 spec is very recently, and not all parts of it have been accepted/finished, I think it'll take sometime until we got a good wysiwyg editor for it, specially with support for any js library.

I've heard good things about Aloha.

You might want to have a look at Maqetta.

There is Atlas a development tool for building Cappuccino applications. Cappuccino apps are written in objectiv-j and will be compiled so they run as Html/JavaScript Applications.

I just tried out the HP/Palm/webOS Ares IDE, which lets you click and drag GUI elements and hook them up to JavaScript events. This is targeted at webOS devices, in that you can make JavaScript calls outside of the browser sandbox (similar to PhoneGap). But they claim they are targeting cross-platform web apps.
Today they announced Enyo, which is the next generation of this, which claims to have vast improvements. I'm excited to evaluate it for general purpose HTML5 web app development.

javascript framework IE6 compatibility

I want to determine the best javascript framework to use in order to maintain IE 6 compatibility.
Specifically I want to know which best supports IE6 - Dojo or JQuery.
I determine compatibility based on the amount of work you have to do to make the framework work with IE6 (framework may have features that need special coding to enable them to work with IE6, or there may be features that are incompatible altogether).
Are there any benchmarks, or compatibility matrices, for the various javascript frameworks that quantify the work you would have to do to maintain IE6 compatibility?

Both jQuery and DOJO claim they support IE6:
http://docs.jquery.com/Browser_Compatibility
http://o.dojotoolkit.org/support/faq/what-browsers-does-dojo-support
DOJO does seem to have quite a grandiose claim:
... 100% of the available
functionality works, that
accessibility is handled correctly,
and that all internationalization and
localization is supported. This is a
very high bar, ...
And jQuery claims they test regularly in IE6.
Personally, I would let other requirements dictate which framework you use. One of the fundamental jobs for a JavaScript library is to be cross browser compatible, so any decent library is going to be good at it.

"Better" in your question indicates subjectivity, so I'd probably change this to a community wiki.
The best thing to do in each case is to look at what the libraries say they support. I know that he following frameworks handle IE6 well:
Prototype
jQuery
I don't have up-to-date personal experience with Dojo or ExtJS, but they supported IE6 well a couple of years back when I looked into them — I'd be surprised if they don't still support it (for now). (ExtJS's "learn more" page says IE6 and up; the "supported" list on the Dojo front page is not, shocking, a link to a list.)
The Closure team originally said they supported IE6 (although they have no official list), but that may have changed with Google's recent decision to drop IE6 support from their web apps.

Amongst other things, the main priority of a javascript library is to solve the cross-browser issues. Having said that, I personally use jQuery and yes it overcomes the IE6 issues too other than other later versions of IE.

Will ExtJS die? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I look at ExtJS, and it appears to provide many of the RIA features that more bulky suites such as Flex provide, without the flash requirement. However, as Open-source initiatiatives such as jQuery-UI continue, will ExtJS simply die at some point? Furthermore, since flash penetration only continues to increase, why put stock in a javascript library?
That said, JavaScript libraries such as jQuery have made gigantic leaps in providing easy-to-use APIs with great functionality, so maybe there's some merit in that.
Thoughts? Opinions? ExtJS has a price tag, so I have to ask this question.

IMHO, the need in jQuery, ExtJS etc. will be eliminated as soon as XBL2, entire collection of CSS3 specifications, SVG and HTML5 all get available in an equal extent across all desktop/mobile web-browsers, which is not going to hapen within coming 5 years.
I look at ExtJS, and it appears to provide many of the RIA features that more bulky suites such as Flex provide, without the flash requirement.
To run Flex application you still need Flash player, which for example is not available on mobile devices
However, as Open-source initiatiatives such as jQuery-UI continue, will ExtJS simply die at some point?
Comparing ExtJS to jQuery-UI doesn't make good sense, since jQuery is primarily a cross-browser library to simplify operations on HTML documents and make web-pages nicer, while ExtJS is a true aplication framework that brings enhanced data-driven UI components to make applications easier.
Furthermore, since flash penetration only continues to increase, why put stock in a javascript library?
It doesn't really matter that Flash penetration "only continues to increase", since it is already available on 98% of desktop devices. Putting stock in a Javascript library makes sence, believe Google (who put most of its stock in DHTML)
will ExtJS simply die at some point?
Indeed it will, as at some point will die .Net, Java etc. It will not die in a foreseen future however and the need for this kind of Flesh-less solutions will only increase.
You may also want to take look into an alternative GUI framework Ample SDK, which will go Open-Source on 1st November this year. It enables technologies, such as SVG, XUL and more equally cross browser.

I don't think Ext JS will die anytime soon. When it will it will probably be one of the last JS frameworks standing. I'm saying this because ExtJS has a solid user and developer base and lots of open source projects are building on it (e.g. an ASP.NET dual-licensed CMS, Sense/Net builds its backend entirely around it among others).

They have a solid user-base and I don't see them leaving the race anytime soon. That said you can always look at the Internet as you look into the general market. Both Starbucks and the local cafe can co-exist.
That said...
Compare the trends between jQuery, ExtJS and Mootools

III'm not a javascript/DOM guru, just an ASP.NET programmer and now-and-then FlashBuilder coder who is looking into 100% client-side libraries. What I am finding is that ExtJS is much richer in its layouts and its UI widgetry than jQuery -- though jQuery has much momentum and new UI components are coming all the time. Still, ExtJS has a major lead in this regard.
With jQuery it is a lot easier to get something basic up and running mainly because jQuery hangs its effects on existing elements in your page markup: you can create a skeletal html page and then apply jQuery functionality to the elements. Compare that to ExtJS where your page is basically an empty body tag and the page contents are created by Ext writing to the DOM. Without the Ext (visual) Designer to lay out my pages and set properties, coding ExtJS configuration objects with a text editor is far too tedious for me and not at all to my liking. But with Ext's visual Designer, you do approach RAD.
ExtJS on IE8 can be slow and sloppy because of IE8's shortcomings. In my experience ExtJS RIA layouts work beautifully on FF, Chrome, and Opera but not nearly as well on IE8. However, IE8 with Google's Chrome-Frame addresses that. Nice gut-punch to those Proprietarians at MSFT, guys at Google!
I really like the hybrid approach FlashBuilder takes. With FB, you can write mxml and/or ActionScript classes. The down-side, as I see it, is that the Flash plug-in is required, and I fear that the Flash plug-in is going the way of that other dodo, WordPerfect, which once roamed the earth with 99% market share. I really wish one could design in FlashBuilder taking full advantage of ActionScript's OO features. mxml, and the FB debugger, and then cross-compile to ExtJS! FB : Ext :: GWT : Closure.

Like with each technology, everybody will have his own piece of cake. ExtJS will not die until ExtJS LLC exists (they are using it :)) And until they will have worshipers using their lib (like me) when You are at some point You just have to use chosen technology, no matter if it is perfect or not. Look at Lotus Domino - it is piece of crap and on the other hand piece of great software - and it is still alive... :)

ExtJS has dual-license And it's opens source
See here general details
And here licenses
And i using it. Good library for working with data - grids, trees... you name it.
And it has many controls. so just good library...

As long as the developers continue to work on it, the framework won't die. There have been a few frameworks that are effectively dead (e.g. MochiKit, which I love but have dropped for yui3) but that only means that they're not getting updated, not that they're unusable. If you liked one well enough, you could easily put out your own release and start up the project again.

Personally, I use Prototype, but it's the same argument. I strongly dislike flash due to the numerous security issues that follow it and the fact that not all devices can play flash. The iPhone is one major example. It CAN support animations and other things using JS libraries.
Some companies also disable flash as policy for security, although this isn't all that common. (I've worked places where this was the case, however.)
Another question is whether we'll care about flash with the advent of new HTML standards will largely eliminate the need for Flash altogether.

Why are there no real competitors to Javascript?

Perhaps I'm just unaware of the competitors, but it seems when it comes to client-side scripting in the browser and DOM, Javascript is it. I know there's VBScript, but it really isn't even in the same ballpark as JS (not even cross platform, for starters).
I'm just curious about how this came to be. Surely there would be a general desire for a new language to replace Javascript: built from scratch to do all the things Javascript has been bent and moulded into these days (look at the reliance on JS Libraries).

Momentum. JavaScript has been around for 15 or so years, and browser manufacturers have worked for 15 or so years to make it work in their browsers.
If a competitor came along, it would need to really bring something new to the table in order to convince everyone to a) adopt it, b) live with locking out all the users of older browsers like IE7, Firefox 3.0, Chrome 1.0 etc. and c) find replacements for all existing libraries like jQuery, prototype, extJS etc.
In short: we don't need another Standard, let's rather improve JavaScript and build on the rich foundation that already exists instead of starting back from stone age again.

There is! Ones that spring to mind are Flash, ActiveX, and Java... But these all have their drawbacks. Mainly security and integration with the browser/DOM.
Flash and Java live in their own little world, by design (and to address security issues). They can't alter the HTML around them. ActiveX has access to the DOM, but also everything else on your computer.
JavaScript seems to have found a nice balance between flexibility and security, it can trivially interact and alter the pages HTML/CSS, do "safe" networking, has a decent standard library (which has things like JSON, XmlHttpRequest'sih networking, DOM manipulation, and so on). Most importantly, it's available in basically all vaguely-modern browsers, on all platforms, in a consistent manner (compared to CSS)
There are problems with JavaScript, but nothing major. The biggest is the performance. Load a comment page on Digg and watch your CPU usage. Chance are it will be 100% of one CPU core. There are projects to improve this, like SquirrelFish, TraceMonkey, and other strangely named things. But the performance is adequate to do some extremely impressive things (Google Spreadsheet, for example).
Basically, JavaScript is great, and it's drawbacks aren't nearly as big as the other competitors.

JavaScript won because it was introduced by Netscape in the period when they had above 90% percent market share. IE and other browsers had no choice but to support it also.
If a new language should be introduced, it would have to be either by agreement between all major browser vendors, or in a period where a single browser have enough market share to push it through.
Microsoft could probably have pulled it off some years ago when IE has an extremely large market share (before the rise of Firefox and Safari), but they chose instead (for strategic reasons) to let the browser stagnate.
Today, a new language would require agreement between at least Mozilla, IE and Safari to gain traction, and I think that is highly unlikely. The browser vendors have invested a lot of ressources in optimization, compatibility testing and so on for JavaScript - why should they want to start from scratch with a totally new language - and have to support two languages in parallel for decades to come? The cost greatly outweights any benefits.
Anyway, it is quite unrealistic to believe that a new language designed from scratch could be significantly better than JavaScript.

Show me another language that isn't reliant on libraries?
C, C++, C#, VBs, ... all rely on libraries. The only difference is that they often come with a standard set of libraries.
So do we really want is a standard set of libraries? What we're currently getting is a range of library sets (JQuery, prototype, extjs, mootools, etc). This is a good thing since we the developers get to choose one that suits our needs. In addition these libraries can be included and evolved without changes to the client-side component.
I can think of no compelling language feature missing from Javascript. By compelling I mean so earth shatteringly important that I'd be willing to alienate those browsers that do not support it.

Standardized (ECMA-262)
Common syntax and relatively simple to master
Good browser support
Extendable
Still being developed
Relatively quick based on how much data it needs to process sometimes.
If a good competitor had arrived before 1999 (ECMAScript 3), it would probably be a tie between those two.

There are other languages for client side scripting, but AFAIK, none are integrated into a browser.
Both Flash and Silverlight have their own Languages. Flash has ActionScript, while Silverlight has many and all that work under the DLR including Python and Ruby.
To your second point as to why, more specifically you mention reliance on JS libraries as a flaw in the language; Libraries are popular, not because the language if broken, but because the standard API is broken. The existence of such great libs builds on the power of the language.
There is nothing particularly wrong with JavaScript, it has some features that up to very recently would have been esoteric or academic. First class functions for example.
Also, ubiquity / mass existing runtime deployment is a very compelling feature. ;)

I recommend you to view Douglas Crockford’s presentation about “The JavaScript Programming Language” to learn about the history of JavaScript.

I think Javascript (ECMAScript) with its C like syntax is so popular for some of the reasons C is:
Relatively small number of language
keywords (easier to learn).
Concise and efficient syntax (quick to write).
Easily extendable
through external libraries and APIs that do
not pollute the basic language (ie Browser DOM,FilesystemObject etc).
Creating a new language that will provide many of the current libraries "built-in" is always risky as it starts to limit future applicability of the language and makes learning the base language harder.
This would be even more problematic for a client side browser language because the language designers can't possibly know how the language may be used in the future.
I think Javascript the language is fine in its current role as the "glue" that links so many other client sode technologies.
There are no other competitors because while Javascript is not perfect, it does the job.

I guess because the demand for it would have to be huge for browsers to implement it.
After all, it's the browsers that process and run the JavaScript and you'd have to have a large amount of sites using the language in order to make the browsers interested in implementing it. Then again no-one would use it if there was no browser support in the first place.

i'd say that this is because client side web development is still a very young branch of programming.
if you look at it only now it has become more widespread since we moved to faster "intertubes" :) and we're not using modems anymore.
and the problem for clent based web development is that it's not up to the developer what platform he'll use but it depends on the browser manufacturers.
and they change slow.
VB script's demise was in my opinion its VB-innes. too much unnecessary stuff.
As for javascript it will mature, but it's a start.

Browser support. If its not an MS tech the it most likely will not go into IE. If it's not in IE then no one can use it. If it is an MS tech, then most likely only IE will have the right to use it as it will be closed source and proprietary. If only IE supports it then only some developers will use it.
To challenge JavaScript it must work just as easily and more consistently across all of the major web browsers. Without browser support any new client side web tech is destined to fail.

I think it has to do with standardization, because durring the last browser-war (ie v. netscape) there were two, Netscape's ECMA (+1 Geek point for you if you knew this was the real name for JavaScript) and Microsoft's JScript, obviously ECMA (JavaScript) won out and became the defacto standard.
Now, we have another browser-war in progress and each of the 2 (3 if you count Chrome 12% FFS) major competitors 3 fully (with a few edge-cases) support JavaScript.

My guess is that its ubiquity and ease of integration in any new user agent project. It comes built into almost all browsers so you dont have to download/install/configure anything to have it running. once you look at user agents off desktops (wii, iphone, windows mobile, n95 etc) the availability of any of the contendes dries up quick - so you code for html and javascript becuase it will work most of the time.

I agree with Michael, we should improve Javascript, not worry about competitors because there aren't going to be any, in fact even Javascript 2.0 seems so far from reaching reality.
Since Javascript is such an ambiguous language, we're able to create libraries (jQuery) and even abstractions (Objective-J) and not worry about all the problems that Javascript has at its heart.

After so many years we don't even have CSS implemented same in all the browser, same goes for the JavaScript, IE has one model and rest of browsers has another Model (I mean like Event Handlers and attaching events).
If new competitor comes, it has no chance, neither it has so much time as css and javascript had.