Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Great JavaScript Debate: Improve It Or Kill It

Soulskill posted about 2 years ago | from the cast-your-votes-now dept.

Google 482

snydeq writes "Recent announcements from Google and Intel appear to have JavaScript headed toward a crossroads, as Google seeks to replace the lingua franca of the client-side Web with Dart and Intel looks to extend it with River Trail. What seems clear, however, is that as 'developers continue to ask more and more of JavaScript, its limitations are thrown into sharp relief,' raising the question, 'Will the Web development community continue to work to make JavaScript a first-class development platform, despite its failings? Or will it take the "nuclear option" and abandon it for greener pastures? The answer seems to be a little of both.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Do whatever you want (-1)

Anonymous Coward | about 2 years ago | (#37496354)

Do whatever you want

Re:Do whatever you want (1, Funny)

Anonymous Coward | about 2 years ago | (#37496580)

Fuck you! You can't tell me what to do!

In my opinion... (3, Funny)

VGPowerlord (621254) | about 2 years ago | (#37496366)

In my opinion... kill it! Kill it with fire!

Re:In my opinion... (4, Funny)

hjf (703092) | about 2 years ago | (#37496414)

Why? This is not 1999. We don't "hate" javascript anymore, like we did years ago.

Now we hate flash. Get on the wave, man.

Re:In my opinion... (1)

smagruder (207953) | about 2 years ago | (#37496448)

Exactly. JavaScript performs well now (generally) and it gives us programming goodies like Ajax, transitions, flat dialogs, etc. I'm actually in like (not love yet) with the language.

Re:In my opinion... (1)

sneakyimp (1161443) | about 2 years ago | (#37496508)

Yes but does Javascript provide access to hardware (camera, microphone) and sockets? Flash does. The sockets in particular (and the new 3d features just added) should make it considerably better for games.

Now don't get me wrong, I'm not flash evangelist. I'm just wondering whether to invest my time in Actionscript or Javascript. One can now develop mobile apps with MXML and Actionscript or one can develop them using Javascript and various new (i.e., experimental) frameworks.

I do find it odd that everyone is trying to kill both Flash/Actionscript and also Javascript. Client-side scripting languages provide tremendous advantages over plain old HTML.

Re:In my opinion... (2, Insightful)

smagruder (207953) | about 2 years ago | (#37496614)

I think both should be kept around. They both have their strengths and weaknesses. As a programmer, I like picking the best tool for the implementation.

Re:In my opinion... (5, Insightful)

aztracker1 (702135) | about 2 years ago | (#37496658)

What you are talking about isn't the responsibility of the language, but the underlying API provided by the browser. And yes, there is some movement towards exposing those hardware elements to the JS API. Though not formally part of the DOM... The language itself is in my opinion a very elegant functional prototype based language. Though recent movements are to avoid use of the prototype aspects of the language.

It seriously bugs me when people confuse the DOM/JS API for a given platform and the language itself. One is not intrinsically tied to the other. JS has been a favorite language of mine for a very long time (since around 1996). It gets a bad rep. mainly because of the browsers' DOM implementations in the v4 browser war... Don't hate the player, hate the game.

Re:In my opinion... (0)

Anonymous Coward | about 2 years ago | (#37496700)

Yes Javascript DOES provide hardware access (see node.js), it is just embedded on the browser that it doesn't.

But time will make it possible. Wait and see.

Re:In my opinion... (2)

Toonol (1057698) | about 2 years ago | (#37496800)

Yes but does Javascript provide access to hardware (camera, microphone) and sockets? Flash does. The sockets in particular (and the new 3d features just added) should make it considerably better for games.

Javascript easily could. The browser doesn't. That's the limiting factor. People mistake the limitations that the browser enforces as limitations of Javascript.

Re:In my opinion... (2)

hedwards (940851) | about 2 years ago | (#37496806)

I agree, death to Flash. The last thing we need is more and better security vulnerabilities.

We hated flash then too. We've always hated flash (0)

Anonymous Coward | about 2 years ago | (#37496542)

Why back in my day when we discussing whether or not we should increase our websites standard aspect ratio from 640X480 to 800X600, we hated flash then too...but designers loved it cause it was pretty.

Re:In my opinion... (1)

syousef (465911) | about 2 years ago | (#37496670)

Why? This is not 1999. We don't "hate" javascript anymore, like we did years ago.

Now we hate flash. Get on the wave, man.

We hate everything you young wiper snapper. Get off my lawn!!!!

Re:In my opinion... (0)

Anonymous Coward | about 2 years ago | (#37496472)

In my opinion... kill it! Kill it with fire!

^^^^^^^^ a billion times this. Javascript needs to die, it is a disastrous language for web development, at least for the kind of applications that everybody is claiming will be in the future of the web.
Large scale development in Javascript is akin to programming in assembler. Its a generational regression.
Bring in a clean, well designed language to web development, its not like I'm asking for a miracle or am I ? ^_^

Re:In my opinion... (0)

Anonymous Coward | about 2 years ago | (#37496576)

the correct answer is probably to agree on a language that abstracts the underlying javascript and makes it more concise to write for web frameworks but when a corporation creates an "alternative" .. translation = developers will have more work to do for each platform they want to target, thus cancelling out any benefit of a better language.

Re:In my opinion... (0)

Anonymous Coward | about 2 years ago | (#37496686)

I completely agree! Javascript is by far the worst part of web development.

Re:In my opinion... (0)

Anonymous Coward | about 2 years ago | (#37496728)

Yes! Kill it with fire, slowly make it suffer...
Just like it made me suffer with all its inconsistencies, glitches, idiosyncratic behavior, global vars, etc, etc...

How about neither? (4, Insightful)

Hatta (162192) | about 2 years ago | (#37496378)

Leave the web for documents. Run applications natively. Why is this so hard?

Re:How about neither? (5, Informative)

hjf (703092) | about 2 years ago | (#37496402)

Because Google needs you to run everything in their cloud so the NSA,FBI,CIA, and even the DMV can get easy access to all your documents.

Re:How about neither? (0)

Anonymous Coward | about 2 years ago | (#37496416)

because javascript isn't used just for web apps? many very, very basic behaviors cannot be done on the web without javascript (eg changing the style of an element, showing/hiding content). it (or something like it) is a necessary evil - for now.

Re:How about neither? (2)

PeanutButterBreath (1224570) | about 2 years ago | (#37496524)

very, very basic behaviors cannot be done on the web without javascript (eg changing the style of an element, showing/hiding content). it (or something like it) is a necessary evil - for now.

Those are not necessary for consuming documents (or more generally, data).

Re:How about neither? (1)

aztracker1 (702135) | about 2 years ago | (#37496698)

The browser is today's equivalent of an old terminal based system. Just has room for more logic to run at the terminal to minimize bandwidth and latency. In order to apply the latter aspects, JS or another client-side scripting language is necessary. I feel that JS is a nice fit. Browser differences in API implementations aside.

Re:How about neither? (2, Insightful)

amicusNYCL (1538833) | about 2 years ago | (#37496496)

The web is not for documents, it is for storing and displaying data. Flexible and powerful interfaces to that data are a part of the web. A client-side scripting language is required for any interface that doesn't require a page refresh on every click.

Leave the web for documents. Run applications natively. Why is this so hard?

Yeah, and phones should only be used for making and receiving calls. And GPUs should only be used for rendering graphics.

I'm sorry you're getting old, but things change whether you want them to or not.

Re:How about neither? (1)

smagruder (207953) | about 2 years ago | (#37496562)

I would add to this...

The web as document-only is a ship that has sailed, and that trip was in the last century.

Re:How about neither? (2)

Lisias (447563) | about 2 years ago | (#37496516)

Leave the web for documents. Run applications natively. Why is this so hard?

Because native applications "are hard to make", and is run on an equipment not owned by the software maker.

Web Applications, on the other hand, "are easy to make and deploy", and, most important, are run on software maker's owned (or rented) hardware.

Had you ever tried to deleted your FaceBook account? ;-)

Re:How about neither? (3, Insightful)

Hooya (518216) | about 2 years ago | (#37496704)

> Why is this so hard?

Two reasons, from my experience:

1. we have large corporate clients (think multinational). They use our services exactly once every year. Over 1,000,000 people in total. Imagine the logistics involved to get a desktop/native application deployed - for that one time use? What if we need to tweak something halfway. How do we re-deploy?

2. That application is "distributed". Everyone does a little bit that is then accumulated. Sure, we could write a client-server app. Then we'd need to figure out threading issues on the server side, work out the communication protocols, work out locking issues. Or we could let, say, Apache handle the threading (we're good but i'd rather trust software that has undergone years and years of usage - there are other web servers that do this better, i know.) Let HTTP be the communication protocol. Let the backend database handle data locking issues (at least using standard SQL concepts allows everyone to be able to wrap their heads around the issues involved). You could argue that we could use a native app that then uses HTTP. For that, see #1.

Native apps were great. Far richer experience in terms of UI. But far, far, poorer in terms of distributed-ness and ease of deployment. Or, looking at it another way, the current state of things are due to the evolution of one native app - the browser. It's just that it comes with an established integrated communication protocol and a UI that's flexible/extendable and the guarantee that the shell/runtime is multi-vendor - but largely compatible and available on most computers shielding you from deployment hassles. So it IS a native app that comes with the pieces you need (comm protocol, extension language, widespread availability).

Re:How about neither? (1)

mikeg22 (601691) | about 2 years ago | (#37496792)

Their are native application platforms that are easy to distribute. Flash and Silverlight are 99% as easy to distribute/update as html/js apps (at least to desktop boxes).

Re:How about neither? (1)

91degrees (207121) | about 2 years ago | (#37496788)

Because the web is interactive, and native applications have a cumbersome install process. Google would be less convenient as a native application, but without javascript wouldn't pop up those helpful suggestions.

Oh Lord... (0)

Anonymous Coward | about 2 years ago | (#37496380)

Please, kill it with fire! And maybe some brimstone too.

What failings? (1)

Anonymous Coward | about 2 years ago | (#37496390)

What failings? I believe that there are some, but why not mention what they are, instead of just throwing it out there as an abstract concept?

Also, it's clearly a reasonable programming language. It's not logically broken and it's quite usable, so how can there be actual limitations? It can modify the DOM in any way a programmer could imagine. What's the problem? Performance?

Re:What failings? (1)

the linux geek (799780) | about 2 years ago | (#37496436)

No block-level scope. No threads. No support for strong typing. No inheritance.

Re:What failings? (1)

blair1q (305137) | about 2 years ago | (#37496476)

What we need, then, is interpreted C++.

Re:What failings? (2, Funny)

Anonymous Coward | about 2 years ago | (#37496530)

You shut your mouth! You shut your GODDAMNED MOUTH!

Re:What failings? (0)

Synerg1y (2169962) | about 2 years ago | (#37496774)

Lol, you trying to build a web application with javascript or something? I hear mcdonalds is hiring.

Re:What failings? (1)

Suiggy (1544213) | about 2 years ago | (#37496514)

JavaScript emerged out of a process focusing on appeasing the masses of web developers with features without much regard for how the end result would turn out. It has some major problems regarding performance, scalability across multiple cores, ease of maintenance and debug-ability that can't really be overcome with better implementations and tools.

People like to talk a lot about moving everything to the browser, replacing traditional applications development, but that's just not going to happen with JavaScript at the helm.

Re:What failings? (1)

BZ (40346) | about 2 years ago | (#37496760)

Scalability I'll grant you, though that's what Intel is working on.

What are the major performance and debug-ability problems that cannot be overcome with better implementations and tools?

What are the major ease of maintenance issues that are not being addressed by ongoing language evolution (e.g. addition of namespacing, modules, etc)?

Re:What failings? (1)

aztracker1 (702135) | about 2 years ago | (#37496810)

Single threading is appropriate enough for most client-side applications, and web workers can be implemented across thread (processor) boundaries. As far as maintenance, this comes down to due dilligence, as with any interpreted environment (like Ruby or PHP, not that I favor either of them, there are good maintainable projects, and bad/difficult ones. Performance has been reasonable on modern hardware for some time... It's often the rendering engine itself that slows things down, or not stacking changes, and forcing re-flow too frequently, which some new events are helping to resolve. A lot of the issues are more with the DOM implementation over JS as a language. Beyond this, JS isn't really at the helm so much as a waiter/waitress taking and processing orders from the kitchen (server).

The hardest part in terms of web application development has been the need for knowledge of HTML, CSS, JS, HTTP, Backend Language, Backend Platform, Data Source... That's seven differing and divergent technologies to have awareness of. I'm favoring JS on the backend via node, and MongoDB as a data source. This at least reduces some of the knowledge required, and makes interacting across the application Teirs more effective. Save for maybe Silverlight+.Net, no other language/platform comes nearly as close.

It's not now, and never will be a panacea, but it could get better. Swimming against a wave usually doesn't work so well.

JavaScript fulfills its mission pretty well (5, Insightful)

smagruder (207953) | about 2 years ago | (#37496398)

If someone wants to add to its mission, or write a client-side language with a different mission, go for it.

But a lot of the web is running nicely with JavaScript, and pulling out the JavaScript rug from web developers and website owners is really not an option.

Let's call for some pragmatism here, shall we?

Too well, probably. (2)

PeanutButterBreath (1224570) | about 2 years ago | (#37496586)

People keep figuring out how to do even more with JavaScript, forgetting that just because you can, doesn't mean you should.

Re:Too well, probably. (1)

smagruder (207953) | about 2 years ago | (#37496648)

True enough. But this notion can be applied to just about any programming platform. When a programmer tries to put all their expectational needs into one technology basket, bad designs can happen.

We want some... (0)

Anonymous Coward | about 2 years ago | (#37496404)

B L O O D !

here we go again (1)

Captain Arr Morgan (958312) | about 2 years ago | (#37496420)

This summery throws into sharp relief the typical misconception of Javascript. The language is not the limiting factor, its the browsers that implement it. Dart will do nothing more then fragment this even further.

Re:here we go again (1)

Anonymous Coward | about 2 years ago | (#37496762)

This summery throws into sharp relief the typical misconception of Javascript. The language is not the limiting factor, its the browsers that implement it. Dart will do nothing more then fragment this even further.

Oh please, assembly languages don't have limiting factors, except when you start designing programs with thousands or hundred of thousands or million of lines of code. Same thing with Javascript, it not an obscene language, but it doesn't scale at all for the kind of software projects that people are thinking of throwing on the web.
Yes, doing some basic scripting in javascript is all good and dandy; developping complex applications in javascript is like standing on the edge of a 300 foot cliff. Not good, not good at all.

Can you even kill an Internet standard? (1)

pwileyii (106242) | about 2 years ago | (#37496424)

Patching it is the easier route and the one that will happen, because it is what people will accept. Look at nearly all Internet standards that we will see that is the case. SSL/TLS, IPv4, HTML, SMTP, WEP (is still supported by nearly all wireless APs) etc. Has an Internet standard EVER been successfully killed?

Re:Can you even kill an Internet standard? (1)

Ragun (1885816) | about 2 years ago | (#37496484)

Sure standards can die, but it will take disuse for a longer period than the internet has been introduced.

If there's a greener pasture (1)

blair1q (305137) | about 2 years ago | (#37496458)

If there's a greener pasture, someone with resources similar to those possessed by the original javascript developers would be seeding it.

Now, knowing what we know about how fugly Javascript is, the question is: why hasn't anyone replaced it yet?

Why kill it? (2)

drobety (2429764) | about 2 years ago | (#37496492)

I like Javascript, it allowed me to code without having to install big fancy development platform. Given how widespread it has become, I fail to see how killing it make any sense. I don't care about dogma, I care about reality.

Re:Why kill it? (1)

betterunixthanunix (980855) | about 2 years ago | (#37496720)

I like Javascript, it allowed me to code without having to install big fancy development platform.

So would a number of other and largely better programming languages.

Standardize a VM. (0)

Anonymous Coward | about 2 years ago | (#37496526)

Replace it with some kind of VM. It's ridiculous that the entirity of the web should be forced to be written in some baroque monstrosity (or, in the "best" case, get compiled to that monstrosity).

Why stop at Javascript? (2)

Ragun (1885816) | about 2 years ago | (#37496528)

JavaScript was meant to manipulate documents, and is used to make those documents into applications.

Lets just throw out HTML altogether and come up with a new language to make the client side section of web apps with. HTML was never envisioned to do this.

Re:Why stop at Javascript? (2, Funny)

Anonymous Coward | about 2 years ago | (#37496612)

Great idea! Maybe some sort of an eXtendible Mark up Language....

Re:Why stop at Javascript? (1)

Ragun (1885816) | about 2 years ago | (#37496646)

What? Nonsense. Thats just a more flexible document. I am talking about going to web based app/applet delivery.

Re:Why stop at Javascript and HTML? (1)

drobety (2429764) | about 2 years ago | (#37496638)

Let's throw out everything in the world which has become something it was never envisioned to be.

Re:Why stop at Javascript and HTML? (1)

Ragun (1885816) | about 2 years ago | (#37496692)

There comes a time when you adapt something so far, that it is clunky and frustrating to use in its new role. Its time to throw it out and make something that is designed to do what we want it to.

Rocks worked well enough to hammer things for a long time.

Then we invented hammers.

Re:Why stop at Javascript? (0)

Anonymous Coward | about 2 years ago | (#37496662)

XAML says, "Hi."

Re:Why stop at Javascript? (1)

Ragun (1885816) | about 2 years ago | (#37496710)

Closer, but this still looks like a way to give object descriptions. we need logic in the base language sent over http.

The unpopular vote (3, Interesting)

gadzook33 (740455) | about 2 years ago | (#37496546)

I know I'm going to get banned from /. for all time, but can we talk about something like Silverlight please? It's a dream to program for and it does all the stuff that we wish javascript did. Ok, begin anti-M$ rhetoric.......now

Re:The unpopular vote (4, Insightful)

Microlith (54737) | about 2 years ago | (#37496582)

Soon as Microsoft surrenders language and library development to a 3rd party that operates in an open manner and allows any and all uses without royalty requirements.

As it stands? No way. That's just handing Microsoft what they've always wanted.

Re:The unpopular vote (2)

Ragun (1885816) | about 2 years ago | (#37496588)

I think you answered your own question.

How on earth is a standard supposed to spread when everyone and their mother distrusts the people producing it? No one trusts them to contribute to the field without some kind of nasty lock-in, and their is a reason for that distrust.

Re:The unpopular vote (0)

Anonymous Coward | about 2 years ago | (#37496664)

Try using something other than windows, like a serious solid secure OS. Then come back how you got on implementing Silvershite.

Re:The unpopular vote (0)

Anonymous Coward | about 2 years ago | (#37496724)

It's not MS that we hate, it's their practices. We want it to be open source, they made it shared source. We want it to be patent-free, they made it patent-encumbered. We want it to be cross-platform, they made a UNIX proof-of-concept and then used their IP to prevent a full implementation from ever being made, so the Windows versions would always be better. Are you proposing that we adopt Silverlight in spite of these things, or are you proposing that MS cleans up its act and starts playing nicely? We're all on your side if you mean the latter. I really hope you don't mean "Let's start using it now and hope MS plays nicely in the future." We've all been burned too many times to believe that. Who do you think created this whole Javascript mess anyway? That's right, most Javascript implementations are very similar with one very notable exception by ...wait for it ...MS.

Re:The unpopular vote (0)

sensationull (889870) | about 2 years ago | (#37496802)

Your right, Silverlight is very simple to code for and comparitivly very efficient but as it did not spring to 110% marketshare in the expected twenty seconds Balmer is refocusing away from it on everything but Windows Phone.

I think a lot of the reason for this is that many of the web developers are either Apple followers or OSS fundementalists both of which have an irrational hatred of anything MS no matter how well it works.

Re:The unpopular vote (0)

lucm (889690) | about 2 years ago | (#37496822)

Silverlight is awesome in a controlled environment, such as an intranet. But in the wild, there are still too many fashion victims buying overpriced white computers and using braindead browsers to make this an effective solution.

Javascript is fine. The API is rotten. (0)

Anonymous Coward | about 2 years ago | (#37496548)

HTML with CSS is nice if you want formatted documents, but it's a horrible GUI kit.

IMHO (1)

drolli (522659) | about 2 years ago | (#37496564)

If you want to replace JS for the sake of its limitations, then use java or C#. Both are fully grown languages with all mechanisms and tools you would ask for, a huge programmer base, good JIT implementations and an awesome amount of code already written.

If you have another agenda, i cant help you.

Mission creep. (4, Funny)

PeanutButterBreath (1224570) | about 2 years ago | (#37496570)

I decided it would be a neat hack to flood my living room and turn it into an indoor pool. Boy, did that reveal some serious shortcomings in my home's electrical system. Can any recommend an electrician who doesn't suck as bad as the guy who installed the one I have now?

Re:Mission creep. (1)

lucm (889690) | about 2 years ago | (#37496780)

Maybe the real problem is the kind of water you use, not your electrical system.

Re:Mission creep. (1)

Ragun (1885816) | about 2 years ago | (#37496820)

Yeah, I really wish that they would just invent indoor plumbing already so we would have a better way to get water into the house.

JavaScript (0)

Anonymous Coward | about 2 years ago | (#37496572)

I've always been a fan of JavaScript, so I'm all in favour of giving the language a few minor updates to squeeze more functionality out of it. Frankly, I've never understood why some people have such a hate-on for the language. It does what it was designed to do and, in my opinion, it does its job well. I've written tens of thousands of lines of JS over the years and have yet to run into any serious problems.

Not bad with a Framework (0)

Anonymous Coward | about 2 years ago | (#37496606)

With the rise of several good frameworks in recent years, such as jQuery and MooTools, working with javascript has become much much easier. But still the language itself is a freaking mess.

Yes. And replace it with Java Swing (1)

roman_mir (125474) | about 2 years ago | (#37496622)

Take out JavaScript and take out the browser entirely, replace it with a Swing Applet.

At this point buy a gun and lots of ammo, because you'll need it to fight off the zombies.

Dr Strangelove (2)

JLennox (942693) | about 2 years ago | (#37496624)

I used to hate javascript. I'd disable it in my browsers up until a few years ago and avoid it like the plague in all of my web development tasks. A year and a half ago I became a full time web developer.

I had to shut up and learn to love javascript, and I really do. There's nothing wrong with it.

A language like PHP3 lacks enough features to make many common patterns possible. Progressing to PHP4, and PHP5, more and more patterns became possible. PHP can now house proper code, though it frequently doesn't because people still hack away like it's PHP3 or PHP4

To me, javascript feels much the same way. I never come across a pattern I can not implement, though I see a lot of coding that ignores standard patterns to it's own demise. linq.js, underscore.js, jquery, and some in-house libraries make classes, objects, collections, DOM work, etc, amazingly simple. The standard library is very poor, but that's ok because the 3rd party libraries are fantastic. Outside of IE8 and under, the speed is FAST too.

A lot of times there's a function that will be implemented by a library but can optionally wrap to a native function if available, making support for everything universal.

Death or Simplification! (0)

Anonymous Coward | about 2 years ago | (#37496644)

It can stay as long as it gets the OpenGL ES treatment where it is stripped down to only the essentials. There are some very good things about ECMAscript but there are also horrible fire breathing dragons hiding just out of sight...

Static Strong (4, Interesting)

kervin (64171) | about 2 years ago | (#37496722)

Give us a static strongly typed alternative/extension without the literally hundreds of known design flaws.

How about a Javascript that's more Java-like?

If only (0)

Anonymous Coward | about 2 years ago | (#37496738)

We could just program javascript on the client and the server. Then no programmers ever need to learn new languages, and we can try to dumb-down Computer Science as a whole. That means cheaper programmers, simpler outsourcing, and less management headaches.

If anyone sees a problem with this, please stop forcing javascript into the server-side. Can't we improve server-side development, not make it worse?

Neither of them. (0)

Anonymous Coward | about 2 years ago | (#37496750)

Fork it. Fork a compiled version specifically for web apps.
Mix in some of the abilities of Java and JavaScript, compiled, problem solved. Just don' tell Oracle...

The real problem is the idiots designing and implementing the spec taking a god damn decade to get stuff done. IF THAT.
W3C, even WhatWG, the problem is there. JavaScript is completely capable as a language. Just because idiots complain, doesn't mean it is terrible.

But the very structure of HTML itself is the worst part. Filled with a bunch of nonsense that doesn't need to be there due to terrible specs being attribute-complete rather than not storing things at all and just parsing that as "default".
This has resulted in relatively simple pages reaching ungodly filesizes as more and more attributes get added.
Seriously, what is the deal with that?

I don't entirely see the problem here though.
Web workers, WebGL, they can run games at decent speeds with fairly decent graphics and FPS. (see quake 2 JS)
Web pages are also being hardware accelerated now.
JavaScript itself is a fine language. Very extendable.
The only annoyance is its inability to store binary data, resulting in the next best thing, Base64* encoding at 133% ~filesize per binary chunk, to be used.
If you don't care so much for portability, binary data can be stored pretty well in media files and opened and scanned.

* on that note, hasn't anyone came up with a larger encoding system that takes advantage of countless other characters that can be represented in pretty much all languages without screwing around with escape characters, or differing language sets lacking those files or whatever?
Why did we settle on Base64? Surely those 2 extra characters aren't the only characters left that are useful for encoding in plaintext?

Already obsolete (1)

lucm (889690) | about 2 years ago | (#37496756)

Who needs javascript now that every website ends up being rewritten in Objective-C?

Actionscript 3.0 (1)

Toonol (1057698) | about 2 years ago | (#37496778)

It would be great if they could evolve it in the direction Adobe did with Actionscript 3.0. That is a nice little language.

The biggest problem, though, isn't Javascript; it's the horrible API and document model it has to struggle with when doing anything in a web browser. That would make programming in any scripting language a nightmare.

Native Client (NaCl) (1)

bbn (172659) | about 2 years ago | (#37496798)

I am hoping for another Google project: Native Client (NaCl).

What we need is not yet another language with a new set of limitations. Instead we need a system that allows any language, even ones not invented yet. And without waiting for every single browser out there to update to the most recent language specification. Without having to program for every bug in every browser.

Native Client solves this by allowing binary executables and a standardized byte code (LLVM) as alternative. You can code in assmbly, C, C++ or any other language you prefer. And it is still as secure as JavaScript. The execution environment is double sandboxed and secure in a very robust way.

Missing the point (2)

Okian Warrior (537106) | about 2 years ago | (#37496808)

I think many people are missing the point of Javascript.

The new spec includes the ability for Javascript to open sockets. Once that takes hold, you'll have the ability to completely control the browser window from the home server.

When that happens, it will be big. The browser is essentially a rendering machine which makes it trivially easy to show things and is largely machine independent. Instead of selling a huge monolithic program, companies can simply sell time on their servers to run their programs.

Imagine that you want to use a big engineering program - Orcad or Altium Designer, for example.

Instead of paying $10,000 for a copy of the program and taking a chance that it's as good as it's marketing claims, you can buy a month of usage for $100, and the executable will run on the company's servers while using your browser to paint the screens. Sort of like how World of Warcraft runs on servers, but paints the screens locally.

This has many advantages for the user:
1) You don't have to risk an enormous sum of money to try something out
2) You don't pay for the product more than you need it
3) You have NO installation issues
4) You are always using the most up-to-date version
5) The vendor can keep backups of your files for you
6) You can access your files and the application from anywhere on the net

And for the vendor:
1) The code is never given out (only runs on the server): no piracy!
2) You don't need multiple versions for different architectures (reduced engineering)
3) You don't have to push updates to the users all the time
4) You can tune the compilation/installation to make the best use of the server
5) Rendering is much easier - the bulk of the code is written for you by others (reduced engineering)

There are some disadvantages - the vendor has access to the document, which means that they can also sell the document to spammers (designs to China, for example). This can be dealt with by using a trust model; ie - the company will have an online reputation which will get quickly tarnished once this happens.

That's the promise of Javascript, and the real potential of the cloud. Companies supplying online services to compete for customers.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account