Dotnet versus Java-Applets

U

UAError

frank said:
If you use Flash, you are not using .NET. It is an old ActiveX control. If
you use .NET, you have access to the entire .NET Framework, as well as
thousands of libraries and components written for the CLR, and sophisticated
development tools such as Visual Studio .NET. However, you will be
restricted to the Windows platform.

A .NET "applet" is much closer to a java applet than to flash. The power is
much greater than flash.

Frank
And there comes a point where you have to start asking
yourself: if you're already committed to the .NET runtime
(or JVM for that matter) why not just ditch the
(constraining) browser - if not for evertyhing, at least for
the more demanding/premium aspects of an
application/service.
 
D

Daniel James

Flash is a nice little technology is you want to
display little on a website ...

Oops! I seem to have accidentally edited out the word "movie" after
the word "little". That rather makes a nonsense of the sentence.
Sorry.

Cheers,
Daniel.
 
D

Daniel James

I would like to understand what you mean when you say :
Applets are on the way out, but in favor of Flash.

I didn't write that - Hal Rosser did.
Is dotnet technology very simple like Flash.

NET technology is much more like Java than Flash. Both Java and .NET are
more powerful than Flash. Flash is primarily a means of placing animated
graphics and sound into a web page, Java and .NET allow programs to be
embedded in a web page so that they will run in your browser - these programs
may produce animated graphics and sound, or they may carry out calculations
or do anything else that can be done by a program running inthe restricted
environment provided by a browser.

At the moment Java is supported by a great many browsers while .NET is
supported only by IE (?) and only then if the .NET runtime is installed on
the client PC. That may change.

My advice is that you should not use Flash or Java or .NET unless you have a
real need that cannot be satidfied without it. Not all browsers can show
Flash movies or run Java or .NET programs, and you will restrict your
audience if you use these technologies unnecessarily. You can do a great deal
with just HTML if you try.
If not - when dotnet be much like Java-Applets (as it is today) ? Long-Horn
?

NET is already "much like Java-Applets" on Windows if the .NET runtime is
installed. The problem is that .NET isn't available in the browser on Macs or
linux or BSD unix or Solaris or Palm pilots, or most smartphones or
minicomputers ... or any of the millions of other computers that don't run
Windows 2000/XP or don't have the .NET runtime installed.

Cheers,
Daniel.
 
G

Guest

Dan,

Not to quibble about 2000/XP being required for .NET but right now most of
my .NET software is binary compatable and runs completely unchanged on Mono
equipped Linux systems and on Mac OSX Panther systems. Also much of the
software I have written for PocketPC runs unchanged on Linux, Mac and Windows
systems and performs far better than it would if written in Java.

V

:

The problem is that .NET isn't available in the browser on Macs or
 
G

Guest

Dan,

Not to quibble about 2000/XP being required for .NET but right now most of
my .NET software is binary compatible and runs completely unchanged on Mono
equipped Linux systems and on Mac OSX Panther systems. Also much of the
software I have written for PocketPC runs unchanged on Linux, Mac and Windows
systems.

V


:

The problem is that .NET isn't available in the browser on Macs or
 
M

Monte Hansen

Perhaps false the way you read it =), but I wasn't speaking to the actual
"safety" of such code, nor comparing it's safety to Javascript. And large
corporate desktops don't tend to run "default" anything these days. The
ability to install apps and updates, change IE preferences, among other
things, are often locked down tightly by AD Group Policies.

Managed corporate environments are becoming more common, and being more
strict on multiple levels (especially those that are outsourced). Those with
a narrow audience might not care, whereas those with a broad audience
probably should.

+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+
Monte Hansen - MVP VB
http://KillerVB.com
+|+|+|+|+|+|+|+|+|+|+|+|+|+|+|+
 
D

Daniel James

In article news: said:
... right now most of my .NET software is binary compatable and runs
completely unchanged on Mono equipped Linux systems and on Mac OSX
Panther systems.

Yes, true, you can run .NET applications under Mono.

AFAIK Mono doesn't allow you to run .NET applets in a web browser on those
platforms ... or does it?
... and performs far better than it would if written in Java.

Yes, the .NET VM does seem to be rather better designed than the JVM. That
makes it more efficient and allows some languages (notable managed C++) to
run that could not be fully supported by the JVM.

If you're trying to distribute active content on the internet, though, you
are far more concerned with ensuring that your content is accessible to the
widest possible range of users (using, as they do, the widest possible range
of browsers) that with efficiency. If the thing doesn't run at all for half
your potential users that's a problem.

I'm not knocking .NET -- and it can be a good solution in a controlled
intranet enviroment where you can esure that all the clients are running
machines with a CLI-enabled browser -- but it hasn't yet achieved the
ubiquity that makes it a viable choice for the internet.

Cheers,
Daniel.
 
F

Frank Hileman

Yes, I read too hastily. Sorry about that! You are correct in a way, and
this argument also applies to java applets and flash controls. Flash is
often blocked because it is predominantly used for annoying advertising.
There is no technical reason to believe javascript is more secure. - Frank
 
G

Guest

I was impressed when I first read what you can do with a .NET smart client
running in the Internet zone as an embeded usercontrol or standalone
downloaded app--very cool stuff.

However it has been around a while now, and I still have not seen much
adoption of .NET smart clients or HTML embeded Win Form usercontrols or the
ClickOnce deployment technology. I am affraid to get into it too deeply
because no one else has and it could getting dropped from support.

Am I wrong and people really are using it?
Do you think it will get picked up more when .NET 2.0 comes out?
 
F

Frank Hileman

I think many people are not aware of the power available. If you looked at
the VG.net demo you can see simple animated demos are possible with the
default IE permissions. I haven't seen many publications speaking of these
possibilities, with the exception of Chris Sells' articles and the MSDN
magazine article. These were complicated by adding additional permissions,
and maybe that scared some people away.

VG.net users are definitely putting vector graphics on the intranet with
..NET. It is one of the first questions they ask. We include a readme
describing how to create usercontrols for IE.

There is no way MS is going to drop support for this. .NET is much more
powerful than JavaScript, and it can only help MS by promoting .NET
technology. However, a standalone exe and webservice is sometimes a simpler
solution, and often xcopy deployment works fine. Sometimes browser
integration is just a "management requirement" coming off a checklist.

Regards,
Frank Hileman

check out VG.net: www.vgdotnet.com
Animated vector graphics system
Integrated Visual Studio .NET graphics editor
 
G

Guest

You are right to say that not many people are aware of the power available.

However, we have fully adopted the technology. We used to implement
browser-based administration systems developed initially using VB
UserDocuments, then switched to ActiveX controls due to download problems.
With the release of .Net, we switched to .Net component applications which
run fully within the browser, some 2 years ago now.

This is a very powerful technology. The default IE security settings for
..Net components are much lower than those for ActiveX controls, and the
no-touch (zero impact fusion technology) deployment, makes installation and
updating seemless.

One word of warning: Because there is so little adoption (as yet), there is
very little assistance available. There are large numbers of quirks in the
behaviour of the .Net framework and IE (e.g. the inability of the .Net
framework to access .config files for downloaded .Net component files through
proxies requiring authentication - Microsoft have assured me this is a known
'feature' which is planned to be fixed as yet; the fact that you can automate
and .Net component from IE, but not vice versa (without HIGH security
settings), and so on.

Having said all of that, we have adopted it as a strategic technology for
Intranet and Internet-based administration systems (i.e. non-public facing),
where the issues of WAI complinace, browser compatibility do not apply.
Hopefully if more people adopt this smart-client technology, then takeup in
other browsers might increase.

Disappointed to see that so few postings on this a written from a point of
any actual first hand experience on the subject.....
 
G

Guest

I'm not knocking .NET -- and it can be a good solution in a controlled
intranet enviroment where you can esure that all the clients are running
machines with a CLI-enabled browser -- but it hasn't yet achieved the
ubiquity that makes it a viable choice for the internet.

For applet-style web applications... For other web applications, ASP.NET is
very well suited for use on a variety of platforms because it outputs html.
 
D

Daniel James

Jzero said:
[I wrote]
I'm not knocking .NET -- and it can be a good solution in a controlled
intranet enviroment where you can esure that all the clients are running
machines with a CLI-enabled browser -- but it hasn't yet achieved the
ubiquity that makes it a viable choice for the internet.

For applet-style web applications... For other web applications, ASP.NET is
very well suited for use on a variety of platforms because it outputs html.

Good point - you control your server and can run what you like on it.

The topic under discussion here was client-side code, and for that I maintain
that while .NET may be a technically superior solution to Java it is not yet
sufficiently widely deployed to be recommendable for internet applications
(intranets are another matter - you control your intranet and so can ensure
that the CLI runtime is installed wherever you need it).

I have less experience when it comes to server side apps and can't really
compare ASP.NET with other solutions. The only server-side programming I've
done has been in (unmanaged) C++ or using a dedicated Java servlet engine. If I
were setting up a general webserver today I'd almost certainly use Apache on
linux, but YMMV.

Cheers,
Daniel.
 
K

Ken Halter

Sure wish there was a way to remove groups from a list of groups that was
incorrectly assembled. This thread's like a virus. It just goes and goes and
goes... too bad that *.vb.* groups couldn't care less about "Dotnet versus
Java-Applets".

How about changing the subject line, removing the *.vb.* groups and
restarting it in a .Net newsgroup?

--
Ken Halter - MS-MVP-VB - http://www.vbsight.com
Please keep all discussions in the groups..

Daniel James said:
wrote:
[I wrote]
I'm not knocking .NET -- and it can be a good solution in a controlled
 
D

Daniel James

Ken Halter said:
... too bad that *.vb.* groups couldn't care less about "Dotnet versus
Java-Applets".

They don't care that VB.NET opens up the possibility for writing applets
in VB? Well, being neither a VB user nor a proponent of active content
neither do I, but I don't see that that's any reason to censor the
thread.
How about changing the subject line, removing the *.vb.* groups and
restarting it in a .Net newsgroup?

How about leaving it alone, because as much as you may dislike having to
ignore it in whichever group(s) you're reading there will be other people
who will have learned from it and be glad they read it there.

Yes, I agree the thread was overposted, but IME it does more harm than
good to try to correct that. It's locking the stable door after the horse
has bolted.

Had you had a worthwhile contribution to make to the discussion, you
would have been within your rights to drop some groups from the list ...
but adding an off-topic posting to the thread in all the groups *just* to
complain about the only marginally on-topic nature of the thread in your
favourite group is counterproductive in the extreme.

The thread had all but died anyway, you've just started it up again by
whingeing.

Cheers,
Daniel.
 
S

smith

If you don't see them I think you're just not looking or maybe you should
give one a try yourself and see how easy it really is. And that one will
lead to more for you and the for good of your company.

Personally, from real deployed experience I think putting the browser in the
mix for corporate development just adds more code which adds more potential
for bugs when it isn't needed at all. For the wide world of retail users
and non-MS OSes the browser and the UBIK javascript definitely has it's
important place, but for corporate deployment where you know that the users
have the framework, as your post implies, an IE window is often just
overhead.

So now it's called "Smart Client" and there's a new MSDN dev center for it,
but since v1.0 we've had the ability to do "AutoDeploy" with binary
Remoting. The assemblies sit in an IIS VDir and are called over http and
when the are called they just deploy and run... and with Remoting you get a
nice performance boost over XML-heavy web services. (Pick up "Advanced .Net
Remoting" - C# or VB versions - by Ingo Rammer. After the first few
chapters you'll see that remoting really isn't all that tough)

Yes, SmartClient/AutoDeploy is for corporate solutions and you have to use
strongnaming and you have to get the desktop user permissions set with an
msi or other tactic to allow the apps to dowload and run, but it far
outshines adding the surface area of IE code and you get a "real" app.
Change the version and the users get it automatically.

Case history (you wanted to know if anyone was really doing it):

I took over a very mature VB6 app used concurrently by 40+ users on both
coasts, it used DCOM against a server process for intelligent multiuser task
scheduling, LeadTools for graphics and loads of "Rocky method" object
manipulation. It was very well coded by my predecessor but with all that it
had, and with the fact that the users always wanted more it was not only a
full 1024x768 main screen but it also at the dll limit of VB6. It could
take no more.

But back with the days of .Net1.0 we had two major features that needed to
be added, and so with a simple COM callable wrapper, a ten-line "loader"
called by the VB6 app, and a couple of SetParent api calls (or Setowner,
depending on whether you wanted the .Net gui element to be a "form" or to
embed itself like a control into a VB6 frame), we were able to add in
AutoDeploy forms "applets" with VB.Net that raised and responded to the main
app's COM events.

Updating the new features just meant updating the version numbers and
popping the new assemblies into the VDir. As stated, the applets used
remoting to talk to their specific functionalities' serverside equivalents
so a lot of maintenance was even better centralized.

By checking/downloading the applets during the first need for each object
and holding references for future use we got nice speed perception and the
users firmly believed that they were just running the main app, they could
not tell the difference.

I go into all this because it's a little frustrating to know that we all saw
this being done way back in the betas and we all read Billy Hollis' "Death
of the browser" in the MSDN VBasic dev center Columns years ago and yet when
given the choice of this simple and powerful option or sticking something in
a browser the browser seems to still be a habit that many folks don't want
to get out of. We don't have to wait for .Net2, it's all right in .Net1.

Granted, there are some little tricks to getting autodeploys with interop
and remoting to all work together (I put a few such tips on my little site
so that I wouldn't forget them) but truly, all it takes is trying it with
the .Net you have today to really amaze you (and your bosses).

Robert Smith
Kirkland, WA
www.smithvoice.com
 
S

smith

Oh, and if you *don't have to* connect to a legacy app ... then your
AutoDeploy/SmartClient projects are a heck of a lot easier :). Once you get
away from COM components and just into .Net all it takes is passing the
users a url.

smith
 
R

Rick Brandt

ShaneB said:
Although it's not in the forum rules, it is still a courtesy to
others. Many people read several of these groups a day in order to
increase their knowledge and help others. I'm sure that they (like
me) would prefer not having to sift through duplicate or off-topic
posts. If someone does not get an answer from a particular group in
a reasonable amount of time, then I'm all for them trying another
one....but I don't think the first choice should be cross-posting. In this
particular case, the original poster's question was probably
most suited for the dotnet.general forum.
As a final thought: If everyone cross-posted, we would only need one
newsgroup.

Unless you have a defective news reader you will only see a cross-posted message
once as reading it in one group will treat it as read in all of the other
cross-posted groups. Now if it were *Multi-Posted* then all of the bad things
you describe would be true and the OP should be chastised for that.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top