View Full Version : Issue Support and Continued Development

30 Jan 2007, 1:43 PM
OK, I've been working with the new Microsoft AJAX stuff for a few months, trying to do a kind of Resource Explorer application. It's primarily hierarchical data of Resources, all of which have parent resources and child resources. Resources have literal values associated that become attributes in the xml output. I've been trying to do a lot of the things I've seen here, even using the same color scheme (I think it's from using Vista, cause it's pretty), but up to now have been using only the MS Ajax and the supplemental Ajax Control Toolkit (very much like scriptaculous on top of prototype).

Now, I'm not a big Microsoft fan, mainly becuase I have to work with their tools, but it's a requirement. So I came across this site, cried a little becuase I realized I had wasted so much time, and then went to the higher ups to show them that everything we've been struggling to implement using asp.net ajax was already done, and with better quality. I went prepared, and no concern could kill my argument, that this was better more complete, and much higher quality in both user experience and design. There was one thing that made them quiver, though, and that is the fact that all this is being done by one guy, unemployed, who will likely move on or get a job, sooner or later. Ajax is supported by the standard MS 9 or 10 year lifespan, and with 60 billion in the bank, will most likely last for the 9 years.

The concern that I cannot address, is on support. What if something breaks? What if we're trying to customize some piece and have trouble and need some help? Nothing lasts for 9 years, so let's argue with 2, maybe 3 years. It's still very feasible that Jack gets a job in a month and yui-ext goes to low maintenance mode. It also on Microsoft to make sure that upgrades are smooth, or even backward compatible. dot Net 2.0 will still work on the 3.0 redist, and if something is found to be broken, MS takes the blame and has to fix it. It's all about passing the buck, about liability.

If something goes wrong, blame MS, call MS, then wait for a fix, it's not your fault. If I implement yui-ext, and something goes wrong, or someone wants something that's not possible, and there's no support, then it has to be rewritten, and then it's my fault. It's politics, business. If I were writing my own website, I could make the decision to use this without question, but in a corporate setting with accountability, it's more risky (not so much from a technical perspective, but political). Anyway, I guess that's the catch-22 on open source. This is some really good stuff, and I'll be using on my own time for sure.

If anyone has done any asp.net ajax server side, with yui-ext for the UI layout, and integrated the 2 so that the updatePanels work, please reply or contact me. The ASP TreeView is not supported by the new AJAX framework, and I'm trying to write a yui-ext based TreeView control that is data bindable and makes callbacks that I can catch in code behind event methods. I've seen the work on the GridView, and am currently working though that code.

30 Jan 2007, 2:12 PM
What if something breaks? You have the source code - you can change whatever you want - can't say that about MS apps.

Given their continued inability to make a working browser, I don't know that I want to trust them to make a working implementation of Ajax on top of that. Atlas is considered in some circles to be an ugly hack just to get something to market and capitalize on the Web 2.0 hype - how many years before it really works? While I like ASP.Net, I'm a little tired of rewriting the crappy HTML it generates - Atlas is no different, plus we have to deal with their javascript coding.

You seem to be concerned about covering your own butt. If you're not in a position to make the decision, all you can do is make a recommendation. Your boss can choose to use it or not - at that point it's on him. If you don't have the confidence in your ability to make a recommendation and live with the consequences, don't make any recommendations.

People want to use the MS and/or IBM (websphere) all-in-one type of solutions. Yeah, it's great that you can lay the blame on those companies - that's irrelevant when your app is a spagetthi-coded, poor performing piece of crap that you're stuck supporting.

I won't speak for Jack, but my impression is that this is his 'job' now.
Just my $.02

There are a number of threads regarding integrating with .Net 2.0 stuff, including the headaches with UpdatePanels.

30 Jan 2007, 2:50 PM
What if something breaks? You have the source code - you can change whatever you want - can't say that about MS apps.

They asked me the same thing, and I gave them the same answer, but the only problem there is that you have to figure out the source, find a solution, and implement it, which all takes time. I really don't disagree that MS is just trying to capitalize/meet a demand for 'Web 2.0', and that the quality does seem like a dirty hack. I hate IE more than you know, and it's the bane of my job, but I have to operate within the parameters given.

As far a covering my ass, well, I could really care less. The problem is that crap flows uphill too (and then back downhill), and someone else will likely have to cover the issue after I'm finished with the project and move on. I won't be supporting or maintaining, and they are the ones I have to look out for. That person will need the fallback excuse, and it's part of my job to make sure it's there. I don't doubt that Jack takes his work very seriously, and would probably do everything he can to support any issue no matter what his future holds.

In reality, I guess there are different markets in play here, and truthfully, corporate won't be ready for web 2.0 for some time. I'm doing what I can to push the evelope without having things backfire and slow down even more. I have the confidence, but not neccessarily the skillset, or time (wait, yes I have the confidence) to fix future issues (an IE6 reflow issue for example).

I'm not saying that I think anything will break either. What I'm looking for are talking points, arguments that I can make to counter any doubt, therefore I have to express that doubt here. Corporate consulting is a , but if I can get this into play, then I'm doing my part to advance this community by creating future jobs using this technology, rather than a pure reliance on big brand software frameworks. I don't always have the time to become an expert, so I rely on examples, forums, blogs and anything that can give an edge to get that extra functionality in less time to get the job done with high reliability. It's a balancing act.

Flame me, call this post a troll, but argue with reason not emotion, and everyone can benefit from the discussion. Software development can be as much of a fight for a technology as it can be a fight with the technology (from an implementation standpoint).

30 Jan 2007, 4:04 PM
Hi Josh,

I would like to provide my own response to a few of your concerns.

1. Support - While it is true that MS will eventually put out a fix on a problem, it is very unlikely you will be able to go into a forum and chat with the guy who is actually writing the code. It is also very unlikely that for most bugs on a new release, there is a fix available within hours of posting the bug.

2. Security - I am not technically "unemployed" anymore (probably time to delete/edit the post in the help forum). I now am working for myself, or you could say I am working for the Ext community. I actually just turned down a really, really fantastic job offer. Why? Well, I think Ext has a very bright future. I love the work and I will be working on it for some time.

I think the best decision is to create the best possible app/product that you can and if you are going to use a library to do that, these could be key considerations:

- Ext supports all of the major browsers. Although MS claims Atlas does, does it really?

- Ext supports just about any doc-type you throw at it.

- At the core of Ext is some of the most feature rich (i.e. Element) and fastest utility classes (i.e. DomHelper, DomQuery) available.

- The widgets provided by Ext have a lot of unique features and more being added with every release. New features are completely community driven and you get input!

- Ext components look good out-the-box.

- The code is well written, designed and documented. There is a community written manual in the works.

- There are real world examples, not just abstract demo pages.

Hopefully this reply helps in some way.


30 Jan 2007, 8:26 PM
All the serious responses aside, if your bosses want to give Jack money to continue to do what he is already doing, and that would make them more comfortable, then you can direct them to the paypal button. Some fraction of the MS license cost would be more than enough, I'm sure. :)

Your bosses are just repeating the FUD that has been fed to executives about open source software for years. If you want to figure out how to make an argument I suggest that you rehash the linux vs prop. unix vs windows, apache vs iis, etc arguments. There are plenty around the web. The bottom line is that open source software tends to have a better long term support and lower overall cost. This is not always the case, but it generally holds true for OSS that has a large user base. The best question you can ask them is how far your product is planned to evolve. Once, it is implemented and has all of the functionality that you have scoped, then long term support is an issue of preserving that state as the browser's continue to evolve (functionality may change, but the UI components are relatively stable). In the case of the competitor you mentioned, they don't exactly have a long history of backward compatibility...just ask all those Korean banks why their self service apps no longer work.

31 Jan 2007, 12:18 AM
For a fraction of the money the corporate drones are willing to pour into MS's coffers, they could sponsor Jack to develop specifc controls, or buy support directly from him.

Plus, the design is clear, and very object oriented. The code is well written, formatted, commented and it's very understandable. Changes can be added by overrides, or by submitting enhancement suggestions.

My employer has no problems with open source software. I think ext wins over MS software any day.

31 Jan 2007, 2:37 AM
I like aps.net ajax , and today Microsoft has just released the source code of everithing.
But you don't have a grid with all the features that Ext Grid has and you don't have a Layout manager
like Ext has.And you can use yui-ext together with asp.net ajax
look at this:


I have support for the Grid and for the TabPanel.

1 Feb 2007, 10:41 AM
I actually just turned down a really, really fantastic job offer. Why? Well, I think Ext has a very bright future. I love the work and I will be working on it for some

I'm gonna bite and say it was Google who tried to hire you to head up GWT on-going development, offering a signing bonus plus moving expenses. Am i right? Google is always on the lookout for talent, so i can see them trying it.

1 Feb 2007, 4:22 PM
Although I talked to google very briefly at one point, nope, it wasn't them. ;)

7 Feb 2007, 7:41 PM
Jo5h - I went through this same thing myself, so I sympathize. Others can debate "FUD" or freedom, but the truth is that the executives you need to convince probably aren't interested in the open-source "you have the source, you can fix it" argument. No blame there: they're not dumb, just cautious and used to an old-world support model. They've probably been burned by unsupported products before.

Here were the two points we used:

#1 bottom-line savings

In my experience there's only one way to present a convincing argument: in terms of dollars. People are expensive, extra development time = big $$.

For instance, with a small feature matrix we were able to present overwhelming cost savings for using Hibernate vs. buying another package, much less building our own. We just listed the requirements vs. how each package met them, with the estimated cost of developing the feature if it were missing from a package.

We did the same with YUI-ext and have already demonstrably saved dozens of developer hours vs. anything else we were considering. And since we're still in development we haven't even hit the "less code now = less debugging later" savings yet.

You may be in a slightly different situation, since you've already written some amount of it in MS AJAX. But I'm sure you can still present the true cost of continuing with one vs. the other, in terms of your project's specific requirements (of course, if you can't, it might be OK to just finish off with MS AJAX even if you like this one better...)

Best reason to fall back on dollars: it's the simple truth, not rhetoric - assuming they trust your math.

#2 true cost of support

OK, it's really the same point: once you've exposed the development cost, you can use that to offset potential support costs. After all, with thousands of dollars saved it's possible in the worst case to contract someone to fix your bugs and still end up ahead. Better yet, today and most likely in the future, you have the ability to directly contract the developer who wrote the package!

In comparison, as Jack pointed out, your feedback to MS is unlikely to result in more rapid response, etc. At that point it does become very useful to have good community support, well-documented code, simple & clean design, etc. because you actually /can/ fix it yourself. The MS AJAX community is fractured and not yet very helpful, as everyone is still learning to tame the huge codebase. (Unfortunately, this is a benefit that may not be easy to convey.)

Hope that helps? To be fair, by the way, we /have/ hit issues with YUI-ext and required support. Jack does a great job of responding to questions, even tricky and/or vague ones. We can all hope that continues even as these forums become more popular! Also, with any package you do have to buy into certain development methodology. MS AJAX will probably always be friendly to ASP.NET, .NET XML/web services, etc. while YUI-ext pushes JSON/REST and doesn't hook into your server-side code. For better or worse :)

Side note: don't write your own Tree, etc. components - go buy a good one from ComponentArt, r.a.d., or the like. They're cheaper than your time spent on dev,test, and esp. browser compatibility. (Jack's grid, menu, tabs, etc are great, but still in development, and not as feature-rich as the vendors' packages. They're cleaner, though!)