Oracle reveals Java Applet API deprecation plan Oracle has revealed its interim plan to help Java devs deal with browser-makers' imminent banishment of plug-ins. Years of bugs in Java, Flash and other plugins have led browser-makers to give up on plugins. Apple recently decided that its Safari browser will just pretend Java, Flash and Silverlight aren't installed. Google …
The way things are going we're going to be left with nothing but Javascript etc. to do stuff in a browser. Good thing from a security point of view, probably.
But for goodness sake, Javascript is just, well, horrible! Surely we as a species can come up with something better than that?!?!?!
Our descendants may look back in wonderment at how rambling and strange our code looks. They may even have a public holiday to commemorate the day the last page of Javascript was deleted.
"Just pick an existing language that was designed with security in mind and support it in browsers."
Hmm. The idea sounds familiar. I'm sure I've heard of such a thing mentioned in the past. Quite recently, in fact. I just can't quite place my finger on it.
More seriously, today's story demonstrates that the language needs a third attribute, beyond secure design and widespread support. It needs to be one that anyone can implement without getting their arses sued off.
How does today's story demonstrate anything about the need for a language that won't get you sued? Oracle never sued anyone for using Java in browsers. Their lawsuit with Google over Android is different, and doesn't concern Java but something almost-but-not-quite-Java that Google created.
Obviously to get widespread support the language must be open, otherwise Firefox can't include it and Chrome probably won't include it.
Something we are used to along the lines of .Net or Java (syntax wise) would be nice enough in a browser. Ho wait that's what TypeScript is for!
Now the problem is that little script kiddies fresh out of school finds it kool to script everything client side, because hey why not?
Also we'd have to move to trash server side JavaScript, and hang publicly whoever came up with the concept and implementation.
Just because an API is marked deprecated, it does not follow that the next release will remove it.
Thread.stop() was marked as deprecated in something like Java 1.1, yet still exists in Java 8
Maybe time for something like Google Web Toolkit to take off. Writing web applications in a statically typed language with excellent tooling and few of JavaScript's shocking brainfarts (the languages's creator Brendan Eich admits it was a proof of concept hack than Netscape rush released). Use JavaScript simply as a kind of architecture independent intermediate language like Pascal P-Code or Java bytecode, with the toolkit's compiler dealing with the quirks in different browser implementations.
<flamebait>
It would mean slack arsed JavaScript developers having to learn a properly designed programming language though.
</flamebait>
There are lots of design decisions in JavaScript that makes it a very poor candidate to use as a p-code-like target for other languages. Just getting any sort of performance in a JS runtime requires LOTS of voodoo.
This should be fairly obvious - it was after all intended to be used for basic interactive scripting. The requirements are somewhat different.
AVM2, which at least keeps type information around, would be a much better candidate, and is a fully open standard that you can implement without having anything to do with Adobe or the rest of Flash. But that's of course not as cool or fun as reinventing the wheel. (And admittedly AVM2 has its problems too, like the egregiously fat opcodes... eg string concatenation like "a" + "b" literally compiles to an addition op).
LOTS is probably relative. If you stated life coding assembly it's not so hard, but you do have to understand what the compiler and the browser are doing behind the scenes.
We do a lot of maths (e.g. Chebyshev polynomials with hundreds of terms) and even four years ago, raw javascript was within a factor of two of C++. That was why we made the decision to switch when we moved to mobile.
We also have a javascript raytracer and performance there improved dramatically when I switched from object access to closures and when I understood the compiler could spot integers and adjusted my code to work with them wherever possible. So the typing is there under the hood (Safari will show you the types of variables). However I miss it every time a bug formal typing would have caught gets through,
But you have to remember to declare classes in the same order or they become different types, that calling functions with different types reinstantiates it (i.e. treat every function as a template) and that functions that catch aren't compiled on V8. I've just read the post mortem on strong mode and it looks like the new features will be slow for some time to come, too (avoid @@species).
And in everyday javascript, the DOM remains a bottleneck in general and triggering layouts in particular. The garbage collector is getting much better but still can be an issue at times. And we still have to do too much on the main thread.
I would imagine it's much easier for cross-compiled code to stick within the rules.
I was referring to what it takes to write a runtime, not to write code that runs in it.
And first of all, just because you can write fast number crunching (relatively easy to optimize the runtime for) doesn't mean a lot of other stuff isn't painfully slow.
Second, imagine if equal effort went into designing runtimes for more suitable languages. You'd achieve a lot more and at the very least have much fewer bugs (many of them potential security issues).
Third of all, even discounting performance etc. and just looking at pain of development, it's not even a particularly good language for anything more complex (as you seem to partly agree).
@kmiettinen - "It would mean slack arsed JavaScript developers having to learn a properly designed programming language though." Are any other kind? The problem I see with most "become a web developer" is they only really teach/use JavaScript (JackassScript), PHP (another steaming, smelling pile), HTML, and CSS but do not teach/use properly developed programming language.
May be there should be a vote for the worst programming language that are/were widely used.
I'm not sure why you'd want to compile an Applet with Java 9 when there will be nothing to run Java 9 Applets. It wasn't just security concerns that ended Applets. Java's GUI, multimedia, and certificate APIs are pretty miserable on their own. Trying to get them working properly through a browser plug-in is futile. For all of JavaScript's flaws, it's still a million times better than Java Applets.
PHP's elegance is no doubt the reason that it is the number one language for writing web applications today. (Way more sites than Ruby, Java, .Net.)
The only real problem with PHP is that it does not allow pointer arithmetic. Having to do p[q++] is just obviously so inefficient compared to p++.
That is a language that would change the world.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
