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'm about to start development of fairly large java based desktop application. After looking at JIDE components and frameworks, it seems to be a good solution at a glance. I'd like to hear from those who used those products. How reliable are they? What's the learning curve? Pros and cons?
I have lived and breathed JIDE for close to 2 years. As the main developer of my company's Swing GUI app, JIDE has made my life both easier and harder.
First, the good part.
The breadth and depth of its components are incredible. Their lastest demo has 171 items, and most are for different components. It's what Swing should've been. The company is indeed small, but you can't possibly say they have only "one product" (re #Stephen C). You're not gonna find any other component suite that has everything from date chooser and popup alert, to searchable and filterable list and table, to pivot table and docking.
Their support is surreal. It's true (per #Carlos) that the only medium is the forum, but the turn-around time and quality of their responses are truly amazing (I'm the 3rd top poster there, so I do know). Many of my posts are new feature and API change (e.g. private -> protected) requests, and they fulfill the vast majority of them within one release or two (which means a few weeks to a month at most).
You can buy source code license for full source code and unobfuscated debug jars. I'd strongly suggest that you do (I wish I could get sales commission from them) if you plan to use their more complicated products like pivot and docking.
Once you have their source code, you can do a lot of customization if you need to, as the code is very open and nicely structured for extension. Sometimes it's risky to extend undocumented classes/methods, but they've kept their code very steady.
And I have to say that their code quality is top notch. It's not squeaky clean (it's as big as Swing itself), but I've never been forced to scratch my head and wonder WTF.
They have very solid developer guide(scroll down the page) for each product group. javadoc is excellent. The full demo itself is a great way to explore the components and features. Documentation was the main reason why I picked JIDE docking over FlexDock (and later I found JIDE docking also has a lot more features).
Now the difficult part.
As #Carlos mentioned, they do introduce regressions with each release. It doesn't seem like they have totally comprehensive and fully automated regression tests, but that's probably next to impossible given the complexity and interactive nature of their products, especially for things like pivot and docking. Even though they fix things very fast, it's always a pain having to wait and then upgrade to a new version, only to find other regressions. That being said, my company's GUI app has shipped several versions without major issues.
I've mainly used many of their somewhat standalone components like date chooser, balloon tip, status bar, multi-page dialog, etc., and two of their most complicated products: pivot table and docking. (Sorry, no JDAF.)
They are complicated for good reasons. OLAP is an industry of its own, and docking is the underpinning of all modern IDEs. That's why I didn't call this section "the bad part". Pivot and docking are difficult to use not because of their quality but due to their complexity.
For example, JIDE docking manager has over 70 primitive bean properties (as of 2.9.5). Some are interdependent, and it takes a while to figure out how to set them for your particular needs.
All in all, I would recommend JIDE without any reservation. It'd be a huge pity if you can't use it due to its propriety, in which case don't even look at its demo, otherwise you will find everything else out there lacking.
I've been using JIDE for 2,5 years now. As far as I'm concerned, it's the best Swing component library there is (as there aren't many). Some of the functionality can be replaced by other alternatives if you want to take a component from here and another from there but some seem to be unique. And of course it is easier to adopt one complete solution instead of separate components and frameworks. Though I should point out, that I've mainly used separate components from the library as well as the Docking framework, but not JDAF so I can't comment on that.
Quality has been good for the most parts although at some point it felt as every release introduced a new bug. But so does every Swing release, so can't really blame them. Response times and customer service in general has been good so you're not alone with your problems. They also seem willing to adapt their products for customers needs.
However, on some parts their operation seems a bit amateurish. For example, the last time I checked, their forum was still used as a bug database. They also have released a large number of new products, some of which seem to be stuck in the beta stage forever.
I'd recommend that you contact them about the deployment fee to get an idea of the total costs, evaluate the product and then consider the risks and costs of adopting JIDE compared to the risks and costs of other alternatives. Open source is not risk free either. Being stuck on a dead commercial product may be worse than being stuck on a dead open source product, but I wouldn't enjoy either.
I'd be wary of this product:
It appears that you will be charged a "negotiable" deployment fee if you want to distribute to customers or do a mass in-house deployment.
JIDE Software seems to be a small one product company. With any company like this, there is a significant risk that it will go out of business or be bought out, leaving customers in the lurch with a dead product.
Using JIDE would be an impediment to making your application open source ... if that step is in your future plans.
UPDATE (2022)
Another thing to be wary of is that JIDE Software don't seem to have plans for supporting newer releases of Java properly. For example, there appear to be dependencies on JDK internal APIs which are being progressively closed off ... starting in Java 9.
Related
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 11 years ago.
The engine I've been wanting to remake is from a PlayStation 1 game called Final Fantasy Tactics, and the game is basically a 2.5D game I guess you could say. Low-resolution sprites and textures, and 3D maps for battlefields. The plan is to mainly load the graphics from a disc, or .iso (I already know the sectors the graphics need to be read from) and fill in the rest with game logic and graphics routines, and probably load other things from the disc like the map data.
I want this to be a multiplatform project, because I use Linux and would like for more people to join in on the project once I have enough done (and it's easy to get more people through platforms like Windows). I'll be making a website to host the project. Also, none of the graphics will be distributed, they'll have to be loaded from your own disc. I'd rather not have to deal with any legal issues.. At least not soon after the project is hosted on my site.
But anyway, here's my dilemma- I know quite a bit of Java, and some Python, but I'm worried about performance/feature issues if I make this engine using one of these two languages. I chose them due to familiarity and platform independence, but I haven't gotten too into graphics programming yet. I'm very much willing to learn, however, and I've done quite a bit of ASM work on the game- looking at graphics routines and whatnot. What would be the best route to take for a project like this? Oh, and keep in mind I'll eventually want to add higher-resolution textures in an .iso restructuring patch or something.
I'm assuming based on my results on Google that I could go with something like Pygame + OpenGL, JOGL, Pyglet, etc. Any suggestions on an API? Which has plenty of documentation/support for game or graphics programming? Do they have any serious performance hits?
Thank you for your time.
I'd recommend going with PySFML, and, of course, Python.
If you do your Python programming correctly , and if you really are willing to fiddle with C or ASM Python plugins for faster computations, you shouldn't really have too much performace hits.
First thing, I wouldn't worry too much about language performance at this moment. If you worry about performance unnecessarily and choose the wrong/hard platform, your project will be dead before it started..because it will take it longer for you to produce something and harder to get other people to join your project.
Since your are familiar with Java & Python, I'll suggest do your project with Jython or JRuby. That way you get to write in nice and powerful language with the benefit of Java runtime.
By choosing to run it on Java runtime you get:
Multi platforms support, so this address your concern about linux/window platform.
Latest Java runtime is very good and in most cases the JIT can perform equal or better to natively compiled program.
At the end of the day if you're passionate about the project and committed to getting the most out of the language you choose, the performance difference between java and python will be minimal if non-existent.
Personally speaking, the biggest challenge is finishing the project once it loses novelty and initial momentum. I suggest you go with whichever language you're more passionate about and are interested in plumbing the depths of, or one that could boost your resume.
Secondly, as you mention you're hoping to attract contributors, you may want to factor that into your decision. I can't comment much here, but have a look at similar projects with lots of activity.
Good luck!
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 11 years ago.
I'm looking into writing my first application of Google App Engine. C# is my 'native' language, and so writing the app in Java would of course be most logical. BUT, I'm a geek and would like to take to opportunity to learn something new.
Therefore its a toss-up between Python and Go.
Do you have a strong preference based on experience (ideally in the context of writing on App Engine).
If you've come from C# (or another similar language), how was the transition?
The recently-released Go runtime for App Engine is labelled experimental for a reason: Both Go and Go-on-appengine are new and in a state of change.
If you want to experiment with Go and running Go apps in the cloud, go for it. If you want to write a production app on App Engine, use Python or Java.
This question is about as subjective as they come, but I'll bite anyway.
Python is easier to learn, has a much larger development community, is mature, and has a lot of third-party libraries available for you to integrate into your application. It's a winner for sure.
That said, Go is an extremely well-designed language. Far, far more so than Python. Go was specifically designed to allow you to catch most mistakes at compile time, while Python is almost legendary for its ability to mask your mistakes. Go code tends to be easier to maintain. Go is also dramatically more efficient than Python -- several times faster or even several orders of magnitude faster, depending on what you're doing.
Both languages are very powerful and very fast to write code in -- you can accomplish a lot in a short amount of space. But Go is unfinished and still in a state of flux, with core APIs still changing. It has a comparatively small developer base, and very few "real world" usage examples. Nonetheless, even this early in its development, it's already shown to be a compelling alternative with a clear use case.
I did a Python app for GAE recently and coming from C# I had no problems/was able to pick it up in a few days tinkering with the docs and playing with the SDK (I had some previous experience with python).
Python is pretty intuitive, it's imperative and OO, might require a slight change in thinking from C# but nothing revolutionary - using the interactive interpreter will allow you to pick it up in a day IMO.
Learning how to use the datastore and figuring out other GAE specific API's (blobstore, image, mail) will probably be more work (it's specifics like transactions/groups, consistency modes ...) but you can figure that stuff out as you go/when you need it in your app.
One thing to note - recently announced pricing scheme makes Python a bad choice on GAE ATM because it cannot handle requests currently and this leads to one "instance" per request. This is also true for Go ATM (as far as I know). JVM OTOH can handle ~20 simultaneous requests per instance if I remember the mailing list conversations correctly. And you will be paying per instance/hour. This makes JVM the most practical choice if you plan on publishing your application in the near future.
Also using JVM you could use Scala (a new/cool language) and a framework like Lift which should theoretically allow you to port your code/avoid lock-in (disclaimer : I say theoretically because I'm only starting out with Scala and have no practical experience with Lift).
So I would recommend to look around the mailing list and see what other people are saying about the recent changes.
Personally I would prefer Python because is much, much more mature than Go.
In the past, I learnt, the hard way, what are the risks of choosing a not-so-mature technology.
Warning, I am biased to recommend Python because I like it but you should also be careful because I heard many complains about how much support does Google put on Python-App-Engine. People are asking for years to upgrade Python support and nobody hears them.
These being said, probably Java would be a smarter choice, especially because you are used to C#.
Go is still experimental on the GAE - so maybe not the best platform to learn a new language. Python is definitely a good choice.
Considering a new language do not forget that by choosing Java you get the JVM which allows not only Java code but also oder languages like: Scala, Grails, Clojure, JRuby any many others.
Python is since long supported on GAE - lots of tested information, infrastructure, etc. Go is new to GAE.
I would decide more on the language level. Coming from C#, choosing Python you go a bit more "high-level", whereas choosing Go goes more into the "low-level" direction. More low-level control, but also more concern about that. Choose Python if your interest is on application development, and Go if it's more about systems development. One important aspect for me would be that Go has actor-style concurrency built in, though I don't know how well supported this on GAE will be.
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 12 years ago.
So I apologize if I'm posting this in the wrong place but I thought asking the coding crowd would be best.
So I'm building a website with 3 developers. One dev is on front-end, one on PHP back-end and one on the database design. The core application of the website is actually much more complicated than i/we (the devs here) originally imagined it would be. The hardest part is in the database design and the design and development of the CMS to manage the database. Working closely with one dev, we have created the final version of the database. This is good news. Meanwhile, the rest of the site is being built with Zend with the other 2 developers.
Essentially what has happened is that the database designer that I have been working with has all the knowledge in his head because he worked with me consistently to design the DB by learning about the technicalities of the domain, industry terminology, the system requirements and so forth. He has also designed the CMS to manage the products that we will insert as per his data structure. Logically, he should really be the one then to code the core application because he knows deeply what he designed. However our system is in PHP and he's a Java dev. So I'm pondering what do to. He has agreed that he could learn PHP in about 2-3 weeks he estimated but admits that at the start, coding would be quite slow while he falls over a few times.
The lead developer on the other hand knows little about the requirements of the core app, the design of the database, the products and the business domain and would therefore take a long time to go through the same process of transferring all this knowledge until he's intimately familiar with everything. So its really a question of time. Would it be faster for a 6 year Java dev to learn PHP and build the core app or would it be faster for the 6 year PHP dev to pick up the knowledge from myself and the database dev?
Is it a close call? Is there a clear winner?
Any advice/suggestions?
Thanks
In essence I think that having experience of design and a good knowledge of how systems work is the most important thing.
Individual languages can be learned (and yes, there is a learning curve, while the syntax is absorbed, then the idioms, etc) and whilst having someone who knows a language when they start makes them a little quicker off the mark, I would choose someone with good design skills over someone with weaker design, but more knowledge of the language.
Language skills can be learned much more quickly than design principles.
In your situation, you have a problem. Two good people with different skillsets. Surely the ideal solution (if it's financially viable) is to have them work as team. Then both will learn much more quickly from the other where they are weak - and they'll be able to discuss design issues and rational. You should end up with a vastly superior product, and two developers whith enhanced skillsets and expanded experience. A win-win, if they can work well togther.
I agree with #Ragster - get the database guy and the UI guy to work together. There's even a buzzword for this - it is called pair programming.
But I'd add one thing. It sounds like a significant part of the problem is that the database guy has all of the knowledge in his head ... and there is nothing written down. This is not good. What happens if the database guy is run over by a green bus?
Maybe you need to make the database guy's number one priority to document the database design in a form that the UI guy can assimilate.
I would vote for using the experienced PHP dev rather than one new to PHP. Any experienced PHP dev should be able to take a brief from you and your colleague on what is needed and utilise the db design work already done.
A dev new to PHP will not produce code that is as well written as an experienced dev and that could cause you problems in the future.
The other solution would be to use Java for this application even if some of your other apps are PHP based. The two can live pretty well side by side.
I'd vote for the PHP-dev, working alongside the database/java dev.
That way, the database/java dev begins to get exposure to PHP, which will help his learning curve; while the PHP-dev will pick up the database structure and the all-important business rationale/details from the database/java dev.
You shouldn't create a dependency on any one person if you can help it, but distribute the application knowledge across your team. This way, you'll end up with a stronger team overall.
You should also ensure that the knowledge isn't maintained purely in anybodys head, but is documented. Always consider the dangers of a number 17 bus when all the knowledge is in somebody's head.
The nature of your question implies that you expect your programmers to develop in single-user mode throughout. I have honestly never met a situation where that was less appropriate than for you right now. Allow/instruct the obvious candidates to use pair programming, and the problem will simply dissolve into thin air. You will get better understanding within the team, faster results, better code, more unified solutions all around...
I am not being flippant here. If you have any historical or even ideological aversions to pair programming, please please please try to just get over them. It just is that much more efficient.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would like to say upfront that i am not a programmer. I'm 1 of 3 partners in a small start up. Two of us have a business and sales background, whilst the third guy is a very experienced Java Programmer/engineer (and a good friend).
As with most start ups we believe we'll be the next big website. We have found a opportunity that the "Long Tail" really describes well. By this i mean a product range that isn't currently being tapped into online. As with Amazon, our model is about offering every available product within the niche. Through the availability of everything outside the fast selling products, we hope to become best website for the niche.
We have placed a lot of focus on building the business/technology system that allows us to build our inventory information very quickly. This was because we knew that the size of our inventory would make or break our usefulness to end users.
So now i come to the problem that prompted me to seek your help.... (please help)... :)
In my (non-technical business) mind, we now have the ability to build our inventory quickly. This is just the start though, as a business we also need the following solutions before making money:
A shopping cart application to
allow buyers to search our inventory,
communicate with our business and
make orders etc.
A CRM application would then
allow the effective management
of customers and orders.
I found my way to Magento and SugarCRM both of which appear to be very impressive. The idea being to use Magento for the buyers (search,buy,interact etc) and Sugar for our staff (order processing, customer service etc).
In my mind the long term rewards of being able to update these core applications from the communities, would far outweigh the steep learning curve. Not to mention the time/money that would be required to even attempt to catch up with what already is stable and tested....
My friend and business partner is unwilling to consider anything in PHP and to a large degree opensource. He's of the belief it would be best to start from scratch.
From a language agnostic business person (non-programmer) - any opinions or advise on our situation would be much appreciated...
I'm keen to find a way of us unlocking horns, either way... I just struggle to see any strong value in Re-inventing the wheel....
Thanks in advance,
Guy
Thanks for the replies so far and the link, i'll go there in a minute. Here's some answers:
Our stock is currently held across 30+ different branches. Which means that we'd need a way for each branch to sign in and manage their own customers.
From our operational point of view, these seem to be the key challenges outside standard :
1) Our business has regions and each region has branches. In order for us to focus the various management levels of the business, it would be ideal if each management level could see the business relevant to them. For example National manager (can see everything), Regional manager (can see all branches in his region), Branch manager (can see everything for his branch with certain admin rights) and Customer service (can see everything in their branch with minimal rights). This is the only way we can have one umbrella site, which can be serviced by staff in branches nationally.
2) Over and above managing orders, it also makes sense that the messages are managed centrally through the application. This way any member of staff can easily see the past history with the customer and assist. I'm thinking that the questions would almost always come in through "Ask a question about this product" link, so incoming messages could be routed to the branch who has the part. If it's aftersales, then the branch who sold it. For general questions through contact us, we'll allocate a member of staff at head office.
3) I think it would be appropriate to show buyers upfront on the product page which branch has the part and the branch information.
4) Total inventory size is currently over 300,000 products. The business plan is to rapidly increase this to 10 times that figure.
5) The products are spare parts. Therefore the buyer would need to search by the orignal product that the parts fits... Each part can often be used on various products.
The answer to this is very difficult, largely due to the fact that not all of your requirements are present. What size is your business going to be? Do you plan on expanding quickly? Do you have specialized requirements? What are those requirements? Answers to questions such as these need to be hashed out.
Now, I need to make a few quick points. There can be a tendency for developers to choose a technology they are comfortable with while disregarding the better choice. There is also a tendency for developers to also want to develope from scratch. This said, if your developer is truelly experienced he will have a good idea of what to use, what to resuse, and what to develope from scratch. You should also take note that this is not an all or nothing sort of situation, and you can blend opensource and homebrew.
My suggestion to you: If you are none technical and your startup is just a few people, this means your one Technologist is essentially your Chief Technology Officer. You need to allow him freedom of choosing technologies and developing his technical plans. This doesn't mean you can't be part of the planning process, but picking specfic technologies is in the realm of his expertise, and you should give him room to move. There could be very good reasons for not using PHP. If you can't trust your CTO to make these decisions you need a new CTO. Edit: --Or you need to start trusting him.
Is your friend experienced at all with running a business?
If not, he may not realize the basic truth:
If something is your core competence, strategically, do it in-house. E.g. you posess the staff who can do it better AND cheaper (however you mesh the two) than competing solutions. E.g. if your friend has extensive experience developing such types of software, or has a working prototype already that fits your needs, or is Jon Skeet and can develop a CRM application fully born from his head between lunch and dinner.
If something is your marginal advantage, do it in-house. E.g. if your friend has ideas on features that would give you a leg up on competition AND can not be easily replicated by competitors. If he merely has a brilliant new widget for a web site that any half-competent developer can clone in 3 weeks, it's not worth it.
Otherwise, do NOT do it in-house. You will waste your businesses' resources on something that gives you no advantage over competitors.
This is not related, in any way shape or form, to PHP and open source.
If you can't develop a qualitatively better solution that will strategically (long term) outperform the opensource solution your competitors use, your software will be a marginal cost to the business, not marginal benefit.
Sadly, the only one who can answer the last question is the technical guy, and he may be, like all techies, biased towards homegrown stuff. So as someone in the other response said, you need to trust his judgement or get someone whose judgement you trust, friend or not.
Nut be sure the question he is answering is the right question -- the one in bold 2 paragraphs above
Hope this clarifies somewhat.
Is there anything about your business model that custom technology is a strategic advantage or core competency? Is there anything special about the products you are selling that require the web site to be any different than any of hundreds of different types of existing online ecommerce sites?
You haven't yet shown anything which would lead me to believe you need custom programming for anything.
This might not go down well with your Java programmer friend, but until you show some kind of differentiating need, wouldn't commercial-off-the-shelf (even hosted) systems meet your needs?
This kind of question might be better off at http://answers.onstartups.com/
After reading your further specifications - they are fairly complex but not that far outside other businesses, I think you need to do a thorough evaluation of the COTS products out there with your technologist with a completely open mind.
The "wheel" you're talking about isn't round. It's as lumpy and pointy and oddly shaped as your business requirements are. If your business requirements are the same as those of other Magento and Sugar CRM users, and will be for the next five years, then they may be great products for you. Then you just need to figure out how to fire your friend, who will not be the best person to maintain those applications.
Or you may need heavy customization, need or anticipate special features not already found in those applications, or want to continue working with your friend. If so, then perhaps you should defer to to your expert friend on technical, programming related decisions, while he leaves sales and financing decisions up to you.
I think some of the answers here are made under the assumption that open source development cannot be branched, it can. You can branch development from Magento, and add new concepts & modules specific to your business. Magneto in fact already has a system in place for doing this. Magento's weakest point is it is not well documented (but is your homebrew system really going to be documented better???)
Regarding #5 the spare parts search - shameless plug - part search extension for magento
Being able to understand, maintain, develop and have control over own technology is very much a business requirement and a very important one. And here you have to trust and respect the opinion of the most technologically experienced member of your team. Either this or look for a new partner.
It sounds as if you have a very ambitious business plan and you’ll need more than 3 persons to put it into life, perhaps you could hire some PHP or Java gurus? Sanitizing 300K+ product descriptions and entering them into the system is going to be a challenge on its own, in addition to setting up the system, failover, testing, customisation (even if you started off with a OSS product) etc.
Are you sure you’ve really got the necessary resource to go that big that quick and still achieve a service of satisfactory quality? Would your business plan still work at a much slower pace or does it rely on the ability to set up a massive operation very early to grab the land?
Another person who understands technology well on the board level could have been beneficial, since your friend needs to cover a lot of ground to set up all the systems necessary for trading and possibly could make use of some help.
Answering your question: PHP and Java are two different universes, and imposing a requirement of learning PHP on your friend will just make the enterprise even more technologically risky. And since your friend doesn't seem to be comfortable with the idea will simply not work.
My organization has a lot of legacy ASP software on its hands.
Since our perception is that Microsoft has shown a distinct lack of support for its older products, we need to figure out what to migrate to next.
If we migrate to ASP.NET from Classic ASP, It feels like that'd be a 'complete rewrite' "migration". Since that is probably the case, we're thinking about turning to a free (as in beer and as in speech) platform. I particularly think our investment (in programming effort, I mean) would be better spent with a platform that will let us evolve, rather than forcing us to dump very single line of code every 4 / 5 years. This is the main argument we've been using to advocate moving towards a 'free' platform.
Currently we're thinking about using a mixture of Java with a dynamic language like JRuby or Groovy.
My questions are: What would be a good migration choice? Are our fears unfounded? Would we (conceivably) need to rewrite a large portion of the codebase after 4 or 5 years anyway? What arguments do you have for moving to either .NET or to a free platform?
We recently migrated a substantial ASP project to ASP.NET and it's definitely possible to do a migration that doesn't become a complete rewrite, preserving a susbstantial proportion of the original code (although we benefited from some fairly well architected code with good separation between the business logic and the presentation layers from the outset).
We looked at two possible routes to the migration:
A ground-up rewrite as a 'proper' ASP.NET application making the most of the built-in controls and shifting all of the business and data access layers into classes etc - ie the way we approach a new ASP.NET project.
A more basic syntactic migration, taking the ASP pages and changing them over to ASP.NET without making too many up-front changes to the structure or logic. Then building on that as we continue to develop the site by making better use of ASP.NET controls, separate classes etc for new and revised functionality.
Due to schedule pressures, we adopted the second route, allowing us to make the switch sooner rather than later and then take a longer-term view on more fundamental changes as part of future developments.
On that basis, for the initial migration we were able to re-use the majority of the existing code, although this is gradually being replaced as we go forward. With an 'average' page having, say, 50-200 lines of HTML and 50-500 lines of VBScript code (as separate functions, not mixed into the HTML spaghetti-style), we found it took about an hour per page to migrate them, including changing all of the ADO data access to a new ADO.NET data access layer. Some simple pages took just a few minutes - some of the more complex pages took a whole day - but about an hour a page was the overall figure across hundreds of pages, with the time to change the data access representing a significant part of the effort.
If we were to redo the migration today, we'd use ASP.NET MVC rather than web forms as it maps better to the way that the original pages were written - although I couldn't comment on whether or not a migration to MVC would take more or less time.
This doesn't necessarily have any bearing on whether or not you want to move to a free platform or change languages - you might have other reasons for wanting to do this. (Our client was Windows based so moving to ASP.NET, development time aside, carried no additional costs.) However, I can say that it's possible to migrate a substantial ASP site to ASP.NET without a complete rewrite - and it's equally possible to migrate from earlier versions of ASP.NET to more recent versions with minimal work. Obviously the route that we chose, preserving some of the ASP feel to the code rather than opting for a complete redevelopment, might not suit everyone - but it does give you a low impact entry point into ASP.NET that then allows you to build on that groundwork while making the most of your existing codebase and skills.
You know mono exists right?
I think you'll find that the longevity of a language is not as important as you think it is, since the lifetime of the major versions of an app is really quite likely to be less than that of most languages. And to be fair to .NET 2.0 -> 3.0 is a pretty small shift up, not a "dumping every single line of code" exercise. If you even wanted to shift up, which isn't really required yet.
I think a strong case could be made for any given platform you might consider, I'd look at other factors like your programmers comfort/skills/familiarity, community support, extensions, and fitness for purpose.
The choice lies in your company's ability to support whatever you choose.
Are you going to support the code yourselves? If so, what is your skill set base right now?
If you are currently enjoying ASP, ASP.NET (code rewrite or no) seems like the first idea to try, even if you don't realise it, by having used ASP thus far, you have probably acquired a great deal of knowledge in maintaining IIS, as well as the plethora of Microsoft based Services and Servers that you can reuse or at least easily adapt to, in ASP.NET development, deployment and support.
JAVA, RUBY, Whatever you choose, the beauty/usefulness/power/usability/durability of any technology lies on the people behind its maintenance.
The questions you should be making are:
best directed at your team
who will be developing, planning managing the resulting app/service?
Are you Ruby people? If not, do you want to be?
Are you JAVA people? same as above
are you....?
..and so on..
Don't distract yourselves with costs here and there or free versus non free.
when the technology is unknown/new to the people behind a project, man hours in support can be much more expensive than most packaged software solutions out there, which will then provide you with support.
This is also true for development environments where you have to pay more for the IDE/Server/etc, but on the bottom line you have less of a learning curve to go through and support at your level of expertise.
Besides: just like #annakata said, you have plenty of opportunities/projects to implement "free as in beer" ASP.NET functionality.. mono or not..
Example: you can set up ASP.NET service with Apache if you like that sort of thing..
Choose what technology you want to adopt by what you know and what you want to know, not what you think is the latest and greatest in buzz, specially if the whole reason why you even started thinking about rebuilding your code set is due to the lack of support for ASP from Microsoft.
I don't think you can escape the pain of migrating every 4-5 years given that the industry is in a continuous flux and tools, platforms and languages evolve to maximize efficiency. There's no guarantee that Groovy/Ruby/C# won't change to adopt the next big thing.
Personally I wouldn't lose sleep trying to 100% future proof myself. If that is the goal then you might as well use assembly and even then there's no guarantee that'll stay constant either.
Just consider the following
1) What do your guys know? If they are vb guys it makes sense to move to VB.NET
2) What budget do you have for tools?
3) Does the platform you want to move to have the stuff that you need? I remember some time back discovering with amazement Powerbuilder's support (or lack thereof) for regular expressions
4) Is there a community around the platform?