Linked by Thom Holwerda on Mon 11th Jun 2012 00:38 UTC, submitted by judgen
Windows "Microsoft recently extended 'It Just Works' compatibility for Visual Basic 6 applications through the full lifetime of Windows 8. Visual Basic 6 first shipped in 1998, so its apps will have at least 24 years of supported lifetime. Contrast that with the Microsoft .NET Framework 1.0 (2002), which is incompatible with Windows 7 (2009)."
Thread beginning with comment 521807
To view parent comment, click here.
To read all comments associated with this story, please click here.
galvanash
Member since:
2006-01-25

This has nothing to do with the VB frontends, but everything with the backend.


No. It has everything to do with the middleware - and VB6 doesn't have any worth speaking of. Sure, you can add some - but it is harder than just wiring things up with ADO/RDO. Obviously that isn't an option, since the whole argument against moving off the now 15 year old dead end platform is that .NET is too hard.

I hear ya though - making your app scale is the DBA's problem...

Web applications suffer from the same issues, with the added complexity that part of the UI is also running server side.


Not modern ones. There is virtually no reason to "run" UI code on the server anymore. You may host it and serve it to clients, but you certainly don't need to run anything except your data layer. It is the same thing as putting a VB6 executable on a network share, except:

1. It can work on different platforms.
2. It works over the internet.
3. It at least can work on mobile devices if you bother.
3. Pick a language you like - there are hundreds.
4. Supports virtually any database known to man.
5. Performs extremely well when done right.
6. Scales much better than monolithic desktop apps using connection oriented, archaic things like ADO/RDO/ODBC.
7. Has the largest developer community on earth.
8. Is the way Microsoft is moving anyway...

User interfaces do not have anything to do with server side scalability.


No they don't. But 15 year old database connection components do...

As for web interfaces being pleasant. I curse every time I need to maintain a mountain of CSS/HTML/JavaScript garbage that could be easily done in a RAD tool.


There are RAD tools for the web too you know... But if web frontends don't float your boat there is WPF, Silverlight, QT, GTK+, etc. etc. etc.. At least those technologies have parts that were actually written for Operating Systems newer than Windows 98...

I know I am sounding like an ass at this point. I don't care, it's frankly infuriating. I honestly cannot understand how any rationale person can defend continued use of a 15 year old product built on extinct technology on the sole basis of "it's easy"... When I was 12 I wrote TIBasic programs for my TI99/4A - compared to modern development in practically any language it was certainly easy - but it is also irrelevent now. The world has moved on. The vendor of the tool has moved on (and then some). It's time to move on.

Reply Parent Score: 3

Alfman Member since:
2011-01-28

galvanash,

"Not modern ones. There is virtually no reason to 'run' UI code on the server anymore. You may host it and serve it to clients, but you certainly don't need to run anything except your data layer."

It's probably not worth my getting involved here since I do agree with your overall message - leave bad legacy code behind when possible. However I'm not sure why you made the above claim? You must know that the overwhelming majority of web apps do generate UIs on the server instead of the client. Even modern frameworks like ASP.Net have done very little to shift UI generation to the client side.

It's technically possible to shift all UI code to the client side by using ajax and eliminating postbacks, but that's the exception rather than the norm.

Reply Parent Score: 2

galvanash Member since:
2006-01-25

You must know that the overwhelming majority of web apps do generate UIs on the server instead of the client. Even modern frameworks like ASP.Net have done very little to shift UI generation to the client side.


Well maybe I went a bit too far with that... I should have said "Not all of them". A combination of backbone.js or knockout.js with jquery on the client side can handle the UI and all the business logic - all you need on the server side is a data layer. There are other ways to do the same thing, ASP.NET has Atlas for example.

I wasn't really trying to say that this was the only way to do it, rather that server side generated UI code isn't the only way either. Web development does not necessarily involve server side complexities created by the UI code. The backend of a backbone/jquery web app is generally nothing more than a thin REST web service for fetching and retrieving your data. The nice part is you don't have to care much what the server side is (ASP.NET, python, Ruby, whatever) - it doesn't much matter.

Reply Parent Score: 2

moondevil Member since:
2005-07-08

I honestly cannot understand how any rationale person can defend continued use of a 15 year old product built on extinct technology on the sole basis of "it's easy"


I was speaking about desktop vs web development issues.

As for VB 6, it can die in peace for what I care.

Reply Parent Score: 2

galvanash Member since:
2006-01-25

I was speaking about desktop vs web development issues.

As for VB 6, it can die in peace for what I care.


I don't have any issues with desktop development or fat clients if you will. My criticisms were more towards the aging technologies under the hood of VB6 (which is what limits its scalability) - not desktop development in general.

Reply Parent Score: 2