Why use ExtJS over traditional ASP.NET?

[Conner05]

Hello,

I need to convince some traditional asp.net developers to switch from classic asp.net.

I've shown them my project using Ext with .net Json data services, while the performance is outstanding, their major arguments have been; the steep learning curve with Ext, there's already AJAX and third party components like Component ONE, lack of intellisense,help tools...job security, etc, the list goes on and on.

I've tried to convince these guys that while there is a learning curve, it is like learning any new framework, it takes some time and effort.

I'm wondering if anyone here has had success convincing their internal team or boss to get off the asp.net bandwagon. What were some of your arguments?

I appreciate your response as I do feel that Ext is the way to go.

Thanks,
Conner

[geoffrey.mcgill]

Hi Conner05,

Using the Coolite Toolkit might be happy middle ground, see http://www.coolite.com/.

Example Exploer (http://examples.coolite.com/).

But... of course I'm biased. ;)

Hope this helps.

[VinylFox]

But... of course I'm biased.

Maybe biased, but still very sound advice for the scenario this user describes.

Conner05, also remind the developers that their ASP.NET Ajax controls are not all cross-browser compatible, have a large overhead, limited flexibility, and generally look like poop.

[Lloyd K]

Get off the ASP.NET bandwagon? You can remain in ASP.NET and still use ExtJS.

We are entirely ASP.NET/ExtJS based without using annoying ASP.NET controls and postbacks and it's fairly straightforward thankfully once everyone gets into using things like HttpHandlers for handling the AJAX stuff etc.

[mankz]

Yeah, getting of the ASP.NET track is the way to go. You could probably get away with vanilla HTML pages that just serve ExtJS scripts. And you can use ASP.NET WebServices/ScriptServices (not SOAP) instead of HttpHandlers to get away from Response.Write and such...

Some cons with MS Ajax
1. MS Ajax uses UpdatePanels to be "ajaxy" which doesn't scale.
2. Their scripts are not X-browser
3. There's no transparency of what's going on under the hood. Hard to understand which scripts get included on the page when using their Ajax Control Toolkit.

[dlbjr]

Be Happy you do not have to deal with archaic AS400 Green Screen lifers as I do! I am so pleased the extinction of dinosaurs is a progressive process.

[harley.333]

Making developers use a framework they don't want to use is like making a child do grammar homework. You can force it, but they won't like, they won't learn anything, and they won't ever use it properly again.

I use Ext with ASP.Net. I don't use the ASP.Net Control Library. I don't use ASP.Net AJAX. I don't use HttpHandlers. I don't use WebServices. Everything is stream-lined, very easy to understand, very easy to debug, and very easy to maintain.

I stop trying to use verbal arguments and statistics to convince other developers. I rewrote a small app to show them the possibilities; and last week I was assigned a six-month project to rewrite a much larger app.

[arthurakay]

I use ExtJS extensively with ASP.NET.

My best advice is to think of things this way: just because you can do a lot of AJAX in ASP.NET doesn't mean you should.

First of all... if they're willing to consider using 3rd party AJAX .NET components, why would they have issues using a 3rd party JS framework?

ExtJS isn't that steep a learning curve -- not anything more than trying to figure out all that you'd want to do in any other language, including .NET. Web Forms and the built-in .NET UI tools look like balls, and they definitely have issues with browser compatibility.

ExtJS may not have intellisense in Visual Studio (there are some people out there who have packages that kind-of work, but they're unreliable), but the API documentation is outstanding -- better than the MSDN docs.

It's a great idea to use ExtJS (or really any separate UI code base) so that you have a distinct UI layer -- one that won't be disrupted should .NET come out with a major update, or if you switch from Web Forms to MVC.

Plus... if you're doing all of the backend work in C# or VB.NET, all of that code is (I'm assuming) object oriented... so why not do your UI in OO JavaScript?

And if you're worried about job security... an outstanding, flexible, visually engaging UI will secure your job as your boss and company executives will wet their pants.

[dlbjr]

Harley:

I've been there done that! We must continuously progress with advancing technology. Learning and changing daily! Most become numb to change and become obsolete. Be cautious of becoming the go-to guy and getting buried in request while the others sit back and have a picnic while pushing work your way.

Would you care to share your asp.net logic to send and receive JSON data? I personally use one small classic asp file for data "JSON" transfer on the server side. Please send a private message if so.

Later,

Dave

[shibubh]

We are entirely ASP.NET/ExtJS based without using annoying ASP.NET controls and postbacks and it's fairly straightforward thankfully once everyone gets into using things like HttpHandlers for handling the AJAX stuff etc.

+10

[mankz]

I use Ext with ASP.Net. I don't use the ASP.Net Control Library. I don't use ASP.Net AJAX. I don't use HttpHandlers. I don't use WebServices. Everything is stream-lined, very easy to understand, very easy to debug, and very easy to maintain.


Curious, what DO you use then? :)

WCF/MVC/PageMethods/AjaxPro...?

[harley.333]

I use the very basic ASP.Net Page life-cycle. I've posted about this before and there are samples in this forum somewhere. Basically, my Ext code makes a request to a specific page (User.aspx). The Ext code also supplies a param telling the page which "action" it wants to take (I named this param "a" -- which is an awful name :) )



Ext.Ajax.request({
params: {
a: "GetAll"
},
url: "User.aspx"
});


The ASP.Net code is super simple. I use a "switch" statement within the OnInit method. I chose OnInit because I can prevent the rest of the ASP.Net life-cycle, but I still have access to everything I need (the Request and Response objects are fully constructed):



partial class _User : PageBase {

protected override void OnInit(EventArgs e) {
DomainBase db;
UserObject obj;
base.OnInit(e);

try {
String sAction = Request.Form["a"];
if (!String.IsNullOrEmpty(sAction)) {
switch (sAction) {
case "GetAll":
db = new DomainBase(DataContext);
OutputJson(db.GetAllUsers());
break;
case "GetById":
obj = new UserObject(DataContext, new User(String2Guid(Request.Form["UserId"])));
obj.Discover();
OutputJson(obj.ToMessage());
break;
case "Update":
obj = new UserObject(DataContext, new User(String2Guid(Request.Form["UserId"])));
obj.Discover();
obj.UserTS = String2ByteArray(Request.Form["UserTS"]);
obj.FullName = Request.Form["FullName"];
obj.Update();
OutputJson(null);
break;
}
}
} catch (Exception ex) {
OutputJsonException(ex);
}
}
}


Using OOP pattern definitions:

the _User class is a "Controller"
the DomainBase class is a "Pure Fabrication"
the UserObject class is a "Information Expert"
the User class is a "POCO" and uses the Serializable attribute


The "Controller" classes are derived from a PageBase class. The PageBase class is derived from System.Web.UI.Page and adds a bunch of helper methods (things like String2Guid, OutputJson, OutputJsonException, etc).

Using this super simple pattern, I avoid the overhead involved with most other patterns. Also, the "complicated" pieces are written in clean code. This is hugely helpful during debugging. Honestly, debugging is what drove me to use this approach. When using AjaxPro, WebServices, and pretty much everything else, I would encounter an exception. But the exception was getting caught and/or fired from within the "helper library's" code. It was increasingly difficult to discover the root of the problem. Usually, the problem was my code or a serialization issue -- but the library should be helping me and not slowing me down.

Let me know if you have other questions.

[arthurakay]

The Ext code also supplies a param telling the page which "action" it wants to take

That's pretty close to how MVC works... you'd build a class of controller actions which return you a "view". Don't know if you've ever looked at MVC, but it sounds like you'd do pretty well with it.

[harley.333]

Yeah - I'm working on a Java app at the moment which uses the Spring framework. And it's very similar. Seems overly heavy to me; but then again, most of Java seems overly heavy to me. :)

But, I use the GRASP (http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)) definition of Controller, rather than the MVC definition.

[shibubh]

i dont think this is good programming pattern.

[Lloyd K]

Why use Page when HttpHandler is a lot lighter and can do everything Page can?

[mankz]

Why use Page when HttpHandler is a lot lighter and can do everything Page can?

Why use HttpHandler when you can use WebServices that handle all serialization/deseralization automatically?

[harley.333]

Lloyd: I should probably look at HttpHandlers again. I can't think of any good reasons not to use them; and I don't think it would take too long to rewrite my code.

Mats: I don't like WebServices. They are heavy and I've had problems with the automatic serialization. Granted, both of those issues may have been solved since I last tried; but at the time, I needed control of the pipeline. WebServices took too much control.

Shibu: Is there anything in particular that is ugly about the solution? I actually want the criticism. :)

[mankz]

I've had problems with automatic serialization too (with cyclic dependencies for example DataTables and DataSets) which I've solved using this approach (http://www.shouldersofgiants.co.uk/Blog/post/2009/01/25/Creating-a-RESTful-Web-Service-Using-ASPNet-MVC-Part-15-e28093-Adding-Connectedness-to-JSON.aspx).

Other than that they've worked like a charm for me.

my 0.05€

[Lloyd K]

mankz: Because web service isn't as flexible and simple as a handler, you get complete control over response, sure you dont have automatic serialization but that's trivial to add imho.

[mankz]

Of course it's trivial, I just like writing less code.

I think I have enough control over the response object with webservices. Only I don't get to do Response.Write, which I'm happy about since I don't need it.

I do see the case though when I'd like to have full control over my response. All depending on the task at hand I guess :)

[tryanDLS]

Another approach to this is to use webmethods instead of webservices. You need to deal with the wsdl an and soap overhead. Much cleaner IMO.

[Lloyd K]

Arent WebMethods and Web Services one and the same? i.e:



[WebService]
public class Service
{

[WebMethod]
public string GetName()
{

}

}


Or did you mean something else?

[mankz]

Sorry, when I say WebServices I mean ScriptMethods, not SOAP.
For instance:


[WebMethod]
[ScriptMethod]
public bool IsUserActive(int id)
{
}

[tryanDLS]

Arent WebMethods and Web Services one and the same? i.e:



[WebService]
public class Service
{

[WebMethod]
public string GetName()
{

}

}


Or did you mean something else?

Well most people understand webservices to be something you access via SOAP and XML. WebMethods on the other hand can simply be called via Ajax functionality as simple GET/POST calls without SOAP and call also just communicate via JSON.

[Lloyd K]

Ahh I've only ever seen [WebMethod] used in the context of [WebService] for SOAP services in .NET that's all, interesting that they're used elsewhere I shall have to look into those.

[harley.333]

Of course it's trivial, I just like writing less code.

Come on, man - this is not a lot of code:


public static String Serialize<T>(T obj) {
JavaScriptSerializer ser = new JavaScriptSerializer();
ser.MaxJsonLength = Int32.MaxValue;
String s = ser.Serialize(obj);
return s;
}

public static T Deserialize<T>(String json) {
JavaScriptSerializer ser = new JavaScriptSerializer();
ser.MaxJsonLength = Int32.MaxValue;
T o = ser.Deserialize<T>(json);
return o;
}


And here's how you use them:


String s = JSONHelper.Serialize(ANYTHING);

User[] users = JSONHelper.Deserialize<User[]>(Request.Form["Users"]);


One line of code to serialize - one line of code to deserialize. I can deal with that :)

[mankz]

Come on, man - this is not a lot of code:


public static String Serialize<T>(T obj) {
JavaScriptSerializer ser = new JavaScriptSerializer();
ser.MaxJsonLength = Int32.MaxValue;
String s = ser.Serialize(obj);
return s;
}

public static T Deserialize<T>(String json) {
JavaScriptSerializer ser = new JavaScriptSerializer();
ser.MaxJsonLength = Int32.MaxValue;
T o = ser.Deserialize<T>(json);
return o;
}


No, not that much code I agree. But I like this amount of code better:


[no code]


Curious, what do you do with the response object that you can't do with .NET builtin serializing. The only 2 things I can think of are

1. Getting rid of the format .NET serializes data... {d : }

or

2. Being able to pass javascript code as part of your JSON. Such as


field : {
"xtype" : "datefield",
"value" : new Date()
}


Maybe there are more situations that require Response.Writes?

[LiXin]

I am using ExtJS and ASP.NET MVC framework (HttpHandlers). Web Srevice is designed for integration not for developing web application. IMHO, JSON is much better as data exchange format than XML for web application.

Regarding serialization, web service has some limitations too.Some object types can not be serialized,such as Hashtable and Dictionary. Also for complex custom type, it has some issues, too. My understanding is that Web Service is using XML serialization not binary serialization. Speed and performance are big challenges to web service.

But if what you developed is for external use (integration), web service may be the good choice.

[LiXin]

Why use Page when HttpHandler is a lot lighter and can do everything Page can?

Actually, aspx Page implements IHttpHandler interface.

[shibubh]

Shibu: Is there anything in particular that is ugly about the solution? I actually want the criticism. :)

Because it inherits from System.Web.UI.Page and that page handler is indented for serving aspx pages (i.e WebForms) and includes a lot of overhead which is not needed for serving just a simple json/xml data. We do not need all page members,fields, methods, properties , events just to serve the json/xml data.

HttpHandler is a lot lighter and can do everything Page can?. So why not use HttpHandler.

[shibubh]

Curious, what do you do with the response object that you can't do with .NET builtin serializing. The only 2 things I can think of are

1. Getting rid of the format .NET serializes data... {d : }

or

2. Being able to pass javascript code as part of your JSON. Such as


field : {
"xtype" : "datefield",
"value" : new Date()
}


Maybe there are more situations that require Response.Writes?

for this i used Json.NET
http://james.newtonking.com/projects/json-net.aspx

simple example



public void ProcessRequest(HttpContext context)
{

JsonSerializer serializer = new JsonSerializer();
serializer.Converters.Add(new JavaScriptDateTimeConverter());
serializer.NullValueHandling = NullValueHandling.Ignore;
System.IO.StringWriter sr = new System.IO.StringWriter();
context.Response.ContentType = "text/javascript";
var extjsConfig = new {
xtype="datefield",
value = new DateTime(2009,01,10)
};
serializer.Serialize(sr, extjsConfig);
context.Response.Write(sr.ToString());
}
this will response

{
"xtype": "datefield",
"value": new Date(1231524900000)
}

[bahar]

I believe "EXT JS + ASP.NET MVC + Json.NET" would be a great combination.

[shibubh]

I believe "EXT JS + ASP.NET MVC + Json.NET" would be a great combination.

yes

[ethar1]

guys I cant make new post? why?!!

[geoffrey.mcgill]

I believe "EXT JS + ASP.NET MVC + Json.NET" would be a great combination.

Yes, see http://www.coolite.com/mvc/.

Online demo application available at http://mvc.coolite.com/

[mprice]

Great example from Coolite! Geoffrey - is the source code available for your example?

[mankz]

Yes, see http://www.coolite.com/mvc/.


...

[geoffrey.mcgill]

is the source code available for your example?

Yes, the source code for the MVC project is available on the Google Code project which can be linked to from http://www.coolite.com/mvc/.

The MVC sample application is still going through constant revisions. There's certainly room for improvement in a few areas, but things are coming together nicely.

The project requires the v0.8 release of the coolite toolkit (.dll's) to build, which have not been publicly released yet.

[Tyrven]

A bit late to this discussion, but I recently made a blog post about this very topic (http://blogs.ignia.com/Jeremy.Caney/archive/2009/08/05/aspnetcontrolsuites.aspx). As a backend developer, I have a traditional bias toward integrated server controls. Given the direction of Microsoft's platform, however, I think there's a strong argument for adopting purely client-side frameworks, which I make in the post.

[YankeeImperialistDog]

MVC.NET with extJS is the best argument there is.

[dotnetwise]

I believe "EXT JS + ASP.NET MVC + Json.NET" would be a great combination.

Also ExtDirect http://www.extjs.com/forum/showthread.php?t=72245

[Mike Robinson]

I don't think that there is any "blanket argument" to be found here. The answer is, as always, it depends.

We've all got a lot of variety in the applications that we're asked to build and deploy. Some are very complicated beasts ... but, a lot of them are also "stupid CRUD."

Furthermore, while some of us are deploying to "the Wild and Wooly Web," a lot of the apps we deal with are "purely internal." The I.T. Department controls everything; the entire deployment scope is well known. These apps often do not deserve to have a lot of costs associated with them. By deploying to a known framework that is, if you will, "already bought and paid-for due to other justifications," you can sometimes get "good enough," more cheaply.

AJAX deployment is a proven way to do it, but it is by no means the only way to do it. There is room for "boring old" ASP.NET out there... or perhaps, rather, "in here if perhaps not out there." The trick is to be familiar with many technologies so that you can make case-by-case decisions. Fill up your tool-box.