The Great JavaScript Debate: Improve It Or Kill It

← Back to Stories (view on slashdot.org)

The Great JavaScript Debate: Improve It Or Kill It

Posted by Soulskill on Friday September 23, 2011 @09:12AM from the cast-your-votes-now dept.

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.'"

19 of 482 comments (clear)

Min score:

Reason:

Sort:

In my opinion... by VGPowerlord · 2011-09-23 09:13 · Score: 3, Funny

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

--
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
1. Re:In my opinion... by hjf · 2011-09-23 09:19 · Score: 4, Funny
  
  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.
2. Re:In my opinion... by aztracker1 · 2011-09-23 09:39 · Score: 5, Insightful
  
  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.
  
  --
  Michael J. Ryan - tracker1.info
3. Re:In my opinion... by Pieroxy · 2011-09-23 09:54 · Score: 3, Insightful
  
  Nothing can be worse than Oracle. Seriously, you want to talk evil companies...
  You do know we're not talking about Java, right?
  
  --
  Write boring code, not shiny code!
4. Re:In my opinion... by chill · 2011-09-23 09:56 · Score: 4, Funny
  
  A beautiful rant killed by an ugly fact.
  
  --
  Learning HOW to think is more important than learning WHAT to think.
How about neither? by Hatta · 2011-09-23 09:15 · Score: 4, Insightful

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

--
Give me Classic Slashdot or give me death!
1. Re:How about neither? by hjf · 2011-09-23 09:17 · Score: 5, Informative
  
  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.
2. Re:How about neither? by Hooya · 2011-09-23 09:42 · Score: 3, Insightful
  
  > 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).
3. Re:How about neither? by smagruder · 2011-09-23 10:19 · Score: 4, Insightful
  
  Please keep the politics out. Can't we have a haven for tech-only discussion please?
  
  --
  Steve Magruder, Metro Foodist
4. Re:How about neither? by izomiac · 2011-09-23 11:11 · Score: 3, Interesting
  
  Apparently, someone thought the concept of files, folders, applications, and menus was too complicated for the 'average person'. Over the years, this idea has spawned countless variations of these concepts in an attempt to make them 'easier' for this hypothetical user. Ironically, the inconsistency and countless layers of abstraction made everything much harder.
  
  Today, users aren't expected to know what any of that stuff is. The modern user isn't expected to understand what application they're using, or the difference between open or closed. Instead of discrete applications, the web browser is used for everything. Files fall way to the "cloud", the internet is the new OS, the address bar your command line. Javascript has become the new assembly language.
  
  It's a marketer's dream, and an engineer's nightmare. Constantly changing everything breeds ignorance rather than increasing experience and sophistication. The tremendous complexity means we can see the web start to have the processing power of a 8086, and about a dozen abstracted layers from hardware, each with their own bugs. It probably won't be too much longer before computer science starts resembling biology, i.e. the dissecting and analysis of a complex system from the top down. Amusingly enough, Windows Vista contains about fourteen times more digital data than human DNA. OTOH, only 98% of DNA is 'junk', so it's probably not a fair comparison.
5. Re:How about neither? by theArtificial · 2011-09-23 12:00 · Score: 4, Insightful
  
  A SSH session uses about the same amount of bandwidth as it did in the 90's. Now you need a 3mbit pipe just to load an ordinary web page in a decent amount of time.
  You know what else uses the same bandwidth of the 90s? 90s webpages. The websites of today are doing more than ever (streaming video, multimedia rich) and file sizes and screen resolutions have increased. Compare the file size of the average game released today to that of 1999. Why don't you fire up Lynx and save yourself the aggravation?
  
  You imply that the delays are due to JavaScript yet majority of the data on the wire isn't JavaScript. The delays you're referring to are mostly due to DNS lookups (and subsequent downloads) of byte heavy multimedia like images, video, and other goodies like Flash and data. As sites have grown in complexity a bottleneck occurs with the number of HTTP requests which a browser may make. The CSS file is parsed and the assets are downloaded the user must wait. The wait may be reduced employing a thoughtful design and clever use of domains (and subdomains). CDN (Content Delivery Networks) are popular for this very reason. At the server level on-the-fly compression may be enabled for various mime types (JS, html pages, smaller images etc.) to increase speed even further without requiring application level changes.
  
  JavaScript may be used in many ways to improve performance on sites, for example: instead of downloading all the map data one only needs what's in the view port. Additionally images which a user never views may not be requested, saving bandwidth. Like any tool it can be misused. Sites which use several ad scripts, analytics, 3rd party widgets etc. are the exception. What about interactive sites (powered by cobbled together server side scripts, made with multiple frameworks) which operate in an underpowered, over provisioned VM, on a shitty pipe with oodles of other sites located on the other side of the world? JavaScript indeed. To see stuff done right look at Amazon.
  
  So with JavaScript gone you have Flash, video, and data. I'm sure these will all be faster now... (since we're using less of these now than in the 90s, right?)
  
  10 years ago new releases of MS Office bloatware was driving the PC upgrade cycle, now its Web Apps and ordinary websites that have been unnecessarily 'appified'
  You're leaving out a big one: entertainment, specifically games. In addition new technology such as DVD, Bluray, data interfaces (USB 3.0) factors in too. I however agree with you, plenty of sites are one trick ponies that in the days past would've been a small program are now a web 2.0 site... which will generate insults seemingly using as many technologies and 3rd party service mashups as possible.
  
  --
  Man blir trött av att gå och göra ingenting.
JavaScript fulfills its mission pretty well by smagruder · 2011-09-23 09:17 · Score: 5, Insightful

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?

--
Steve Magruder, Metro Foodist
The unpopular vote by gadzook33 · 2011-09-23 09:30 · Score: 3, Interesting

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
1. Re:The unpopular vote by Microlith · 2011-09-23 09:33 · Score: 4, Insightful
  
  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.
Mission creep. by PeanutButterBreath · 2011-09-23 09:32 · Score: 4, Funny

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?
I wouldn't mind Lua by FictionPimp · 2011-09-23 09:41 · Score: 3, Interesting

I wouldn't mind if they added Lua to web browsers.
Static Strong by kervin · 2011-09-23 09:44 · Score: 4, Interesting

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?
How many times will we have this argument? by rabtech · 2011-09-23 10:04 · Score: 4, Insightful

The history of the Internet and examples like IPv6, HTTP, SMTP, etc have shown us over and over that "good enough" + evolution trumps replace almost every time.
The path forward is clear: improve JavaScript, extend it, improve HTML, and keep on trucking. Neither will ever be replaced on a wide scale, only evolved.
The reason we don't already have worldwide IPv6 deployment is they redesigned IP instead of just extending the addresses.

--
Natural != (nontoxic || beneficial)
Read Crockford's "Javascript: the good parts". by csirac · 2011-09-23 15:13 · Score: 4, Informative

How does one establish whether methods/vars are public/private/protected? Or inheritance? To me, the weird misappropriation of the function keyword to build objects, the verbosity of the code to express objects, and the lack of inheritance, etc. are primitive compared to Actionscript 3, to Java, to PHP5, to C++, and a variety of other languages I've dealt with.

You really need to read Crockford's "Javascript: the good parts". You absolutely do make private methods and vars (ever noticed that you can't directly call jQuery's internal methods? Or TinyMCE's? Or any other major library/framework?)
He also makes the case that actually JS has more patterns to allow code re-use. That's why things like Mootools can even fake things that look like classical class inheritance patterns for you, if you really want to do that.
Check out http://www.crockford.com/javascript/inheritance.html and http://javascript.crockford.com/prototypal.html and http://www.slideshare.net/douglascrockford/javascript-the-good-parts-3292746