Beta
×

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!

Was Standardizing On JavaScript a Mistake?

CmdrTaco posted about 6 years ago | from the hindsight-is-twenty-twenty dept.

Programming 525

snydeq writes "Fatal Exception's Neil McAllister questions the wisdom of standardizing on a single language in the wake of the ECMA Committee's decision to abandon ECMAScript 4 in favor of the much less ambitious ECMAScript 3.1, stunting the future of JavaScript. Had the work continued, McAllister argues, it could have ushered in an era of large-scale application development that would ensure the browser's ability to meet our evolving needs in the years ahead. 'The more I hear about the ongoing efforts to revise the leading Web standards, the less convinced I am that we're approaching Web-based applications the right way,' McAllister writes. 'If anything, the more we talk about building large-scale Web applications, the more we should recognize that a single style of programming will never suit every job.' McAllister's simple truth: JavaScript will never be good for everything — especially as the Web continues to evolve beyond its original vision. His solution? 'Rather than shoehorning more and more functionality into the browser itself, maybe it's time we separated the UI from the underlying client-side logic. Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.'"

cancel ×

525 comments

Sorry! There are no comments related to the filter you selected.

Got it wrong (4, Insightful)

AKAImBatman (238306) | about 6 years ago | (#24689833)

So here's an idea: Your Web browser window is a View. Maybe it's high time we stopped trying to force it to be a Controller, too.

Here's an even better idea: The HTML DOM would be the View, the Javascript would be the Controller, and the server would be the Model! I'll bet I'm the first one to think of that...

So if nobody ever managed to come up with the ultimate, perfect language for systems programming, what makes us think we can do it for the Web?

The browser model allows for languages other than Javascript. (e.g. VBScript is somewhat popular in IE-only applications.) It's just that no one has come up with a better language. If no one comes up with a better language, why reinvent the wheel?

Ever since the early days of Web browsers we've had this language, JavaScript. Over the years, we've demanded more and more of it, to the point that we're now talking about using it to build entire applications. The simple truth, however, is that JavaScript will never be good for everything.

That's one person's opinion. My opinion (and the opinion of many others) is that Javascript is a very powerful LISP-like langauge capable of far more than its given credit for. Part of the reason for abandoning ECMAScript 4 is that v3 already supports most everything we need. It's not perfect, mind you, but it doesn't actually NEED the features of v4. Most of those features are syntactic sugar that makes the language more comfortable to Java programmers.

Behind the scenes, nothing really changes with the common features of v4. There's some type checking and a few other minor additions going on, but otherwise the objects are translated into Javascript objects.

Strong typing, packages, and namespaces may make it a lot easier to maintain large applications, but they're virtually useless to any Web coder who just wants to bash out a little bit of UI glitz.

And there-in lies the problem. People think of Javascript as being for "UI Glitz". That's the real issue to tackle. Not the imagined lack of MVC.

Re:Got it wrong (3, Insightful)

mcvos (645701) | about 6 years ago | (#24689961)

It's just that no one has come up with a better language.

No one has been able to come up with a better language than javascript? That's a scary thought.

Re:Got it wrong (4, Insightful)

Swizec (978239) | about 6 years ago | (#24690107)

The problem with javascript isn't that it's a bad language, the problem is that everyone continues on thinking about it as a tool for quick and dirty hacks. But guess what, that's how PHP started out and look where it came.

All javascript really needs is to be well supported in all browser and that people would stop thinking about it as just a script kiddie tool. Javascript is perfect for what it was intended to do and it's very good even for what it wasn't exactly intended to do and THAT's why there hasn't been a "better" language yet, because this one is good enough for the job. Frankly, outside of becoming standardised all over, I don't see what more you might want in javascript that you absolutely cannot live without.

Re:Got it wrong (5, Informative)

coryking (104614) | about 6 years ago | (#24690269)

I don't see what more you might want in javascript

- A real way to include other javascript files.
  - A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".
  - Ponies.

Re:Got it wrong (5, Funny)

Chaos Incarnate (772793) | about 6 years ago | (#24690437)

Any spec without ponies is a defective spec indeed.

Re:Got it wrong (1)

erlando (88533) | about 6 years ago | (#24690527)

- A real way to include other javascript files.

Agreed. Injecting a script-tag just doesn't cut it. We want real includes dammit!

- A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!"

Isn't this more of a browser-issue? A consensus is needed as when to fire "onload".

Anyway you can get close by using e.g prototype's document.observe("dom:loaded", ...) in Prototype 1.6+

Re:Got it wrong (5, Insightful)

coryking (104614) | about 6 years ago | (#24690699)

That document.observe is all great until you try to mix Prototype (or any of these libraries) up. Say you needed to use the YUI calandar control on a page that also uses Prototype (for lightbox2). Now the two libraries will "fight" over the browser's onload.

Actually.. that is the biggest problem we have right now. Dozens of javascript libraries and all do pretty much the same thing. All of them "weight" like 20->40k. That "weight" and the potential for them to conflict make life really hard.

What if you based your own code on Prototype and want to integrate a really nice file-upload control that uses MoTools?

What if you are using Prototype and you drop in TinyMCE. Now you've got two runtime libraries that both have their own methods for injecting objects into the DOM. Those two methods are ever so slightly incompatible so if you create a DOM object via Prototype (actually scriptalicious) and try to inject it using the TinyMCE way, things will break in random browsers in very hard to track way.

Enter Silverlight/Flex. Now you can go from dozens of Javascript runtime libraries to only two very stable ones. As the "UI control" scene for these grow, I suspect our dependency on Prototype/jQuery/Whatever will shrink.

After all, it has to be way easier for control vendors to target Silverlight/Flex then it is for them to target javascript. And as a bonus, it is way easier for me to integrate their UI controls into my own Silverlight/Flex application.

Re:Got it wrong (1)

dword (735428) | about 6 years ago | (#24690553)

window.onload = function () { alert('The page is loaded') };

Re:Got it wrong (1)

liquidpele (663430) | about 6 years ago | (#24690607)

1)Yea... this is a shortcoming, but it can at least still be done [javascriptkit.com]

2) <script src='thefile.js' defer='defer' > (the defer makes it not run it until the page is loaded).

Eh? (1)

Just some bastard (1113513) | about 6 years ago | (#24690615)

A real way to include other javascript files.

The "real" way is via the DOM.

function include(url){
var s = document.createElement("script");
s.setAttribute("type", "text/javascript");
s.setAttribute("src", url);
var nodes = document.getElementsByTagName("*");
var node = nodes[nodes.length -1].parentNode;
node.appendChild(s);
}

A well defined way to say "The page is loaded, all your variables and objects are loaded, Time to execute!" rather then "You can only see the variables and objects that are defined 'above' you and not 'below' you in unloaded portions of the page".

window.onload is the DOM event you're looking for.

Re:Got it wrong (2, Insightful)

Mr2cents (323101) | about 6 years ago | (#24690271)

Leaving the language itself aside, the big problem I see when reading javascript is all these tests to check on what browser it is running. If I write code, I don't wan't that mess (Luckily, I I'm not a web developer).

Re:Got it wrong (3, Informative)

erlando (88533) | about 6 years ago | (#24690469)

Leaving the language itself aside, the big problem I see when reading javascript is all these tests to check on what browser it is running

In modern Javascript usage you leave that to a framework library such as Prototype, mooTools, jQuery, Dojo etc.

Re:Got it wrong (3, Insightful)

dword (735428) | about 6 years ago | (#24690645)

That's not really the problem. Standard JavaScript is supported on most browsers (all popular browsers) in a more uniform way than anything else is. The real problem is the way access to the DOM was implemented, not the language it's self. People realized there were certain needs for certain features (ie, like selecting text in an input element) so they implemented those features in their own proprietary ways and left them the way they were done.
Some browsers include newlines in the DOM, some don't. If you have something like <ul> followed by a newline followed by a <li> you'll find that IE doesn't consider the newline to be a child of the <ul< but FF does (I find that annoying).
What we really need is a standardization for working the DOM in the browsers, the language it's self is fine.

Re:Got it wrong (5, Insightful)

Cecil (37810) | about 6 years ago | (#24690351)

But guess what, that's how PHP started out and look where it came.

What it became? A tool for quick and dirty hacks that many people use to create applications that inevitably turn into a quick and dirty hack?

Re:Got it wrong (1)

lastchance_000 (847415) | about 6 years ago | (#24690357)

One of the biggest issues I've had with it is the poor performance (relative to what it's being asked to do) in the current browser engines. The good news is the current advances (e.g. WebKit) give me great hope.

Re:Got it wrong (2, Insightful)

mcvos (645701) | about 6 years ago | (#24690495)

One of the biggest issues I've had with it is the poor performance (relative to what it's being asked to do) in the current browser engines.

One thing I learned to avoid is big iterations. Keeping your loop as short, efficient and preferably absent as possible has a surprisingly big impact on javascript performance.

Re:Got it wrong (2, Insightful)

mini me (132455) | about 6 years ago | (#24690301)

Javascript is an amazing language. The C-like syntax gets in the way occasionally, but all-in-all it's up there with the best of them.

The problem is that most people do not even realize that it is an object oriented language, let alone containing functional language features as well.

Re:Got it wrong (1)

AxelTorvalds (544851) | about 6 years ago | (#24690591)

Better isn't the right word.

It's ubiquitous. good enough and it runs everywhere you want it to.

Re:Got it wrong (1, Interesting)

wild_berry (448019) | about 6 years ago | (#24689969)

My opinion (and the opinion of many others) is that Javascript is a very powerful LISP-like langauge capable of far more than its given credit for

Firefox is a good OS. All it needs is a decent web browser.

Re:Got it wrong (1)

GeneralTao (21677) | about 6 years ago | (#24689997)

Here's an even better idea: The HTML DOM would be the View, the Javascript would be the Controller, and the server would be the Model! I'll bet I'm the first one to think of that...

You took the words right out of my mouth. I mean seriously.

Re:Got it wrong (5, Interesting)

tomtomtom777 (1148633) | about 6 years ago | (#24690011)

I strongly agree.

I even believe the features of v4 will unnecessarily complicate the language. Most problems in javascript arise when people try to mimic 'normal' OO-behaviour instead of using javascript's powerful prototype-based system as given.

Javascript is extremely useful to create large scale applications but most programmers are to much educated towards 'convetional' OO-programming to use it right.

I guess it is the same problem as with functional programming, which is often preferable above OO-programming for the server-side model layer. The mindset of the common programmer is simply not diverse enough to use a completely different approach, such as prototype-based or pure functional programming

Re:Got it wrong (1)

Smidge207 (1278042) | about 6 years ago | (#24690041)

You are in a "web" of computers all linked together. It is getting dark. You are likely to be eaten by a Linux sys admin.

=Smidge=

Re:Got it wrong (1)

Bryansix (761547) | about 6 years ago | (#24690383)

What nobody has mentioned this far into the discussion is that a vast majority of the web pages that display things in javascript are not even written in javascript. Many are server side like aspx files that are then interpreted in a dynamic way into a combination of HTML and javascript to do the work that needs to be done on the client side.

I brought this up a while back when there was an article about how Microsoft was abandoning javascript in favor of something else for use in the next .net framework. I think that was a mistake. Javascript can be made to do anything that is needed client side. Anything else should be handled by a post back and taken care of server-side.

Re:Got it wrong (1)

larry bagina (561269) | about 6 years ago | (#24690539)

"Web 3.0" stuff (gwt, sproutcore, objective J, etc) move much of the server side stuff to the client and use the server primarily for serving itself and db access.

Re:Got it wrong (1)

ultranova (717540) | about 6 years ago | (#24690457)

Javascript is extremely useful to create large scale applications but most programmers are to much educated towards 'convetional' OO-programming to use it right.

Do you have any links to where one could learn to use it right ? Reading the source code of various web page scripts seems like a bad idea if most of them are done wrong.

Re:Got it wrong (4, Informative)

AKAImBatman (238306) | about 6 years ago | (#24690523)

Start at the source:

http://developer.mozilla.org/en/Core_JavaScript_1.5_Guide [mozilla.org]

That document may be nearly 15 years old (plus/minus revisions along the way), but it's still the definitive method of learning Javascript.

For those who actually take the time to read it, that is.

Good luck! :-)

Re:Got it wrong (2, Interesting)

betterunixthanunix (980855) | about 6 years ago | (#24690037)

Wait, nobody has come up with a language better than Javascript? That's funny, because when I think of useful scripting languages, I tend to think of...AWK, PERL, Python, etc. There is nothing stopping someone from integrating one of those languages into a web browser, nor anything stopping a standard "Web Python" from being created, with a specific standard library for web apps (on the client side, that is).

Re:Got it wrong (1)

IntlHarvester (11985) | about 6 years ago | (#24690573)

That was done years ago. Any scripting language which plugs into the Windows Scripting Host can be used for web scripts in IE. So ActiveState Perl and Python can be used in a suitably controlled environment.

Re:Got it wrong (1)

betterunixthanunix (980855) | about 6 years ago | (#24690685)

I guess you missed that part about "standard." Or about non-Microsoft browsers. Or non-Microsoft operating systems. Cross platform programming has been important since before Microsoft, before the Internet, and certainly before the world wide web. There are other, better designed ways of creating distributed applications.

Re:Got it wrong (2, Insightful)

kingmundi (54911) | about 6 years ago | (#24690105)

>> It's just that no one has come up with a better language. If no one comes up with a better language, why reinvent the wheel?

The best language does not always gain mindshare.

Re:Got it wrong (5, Insightful)

Blakey Rat (99501) | about 6 years ago | (#24690123)

I agree that Javascript/ECMAScript is an excellent language.

Real web-application development isn't being hampered by JS, it's being hampered by the crappy and woefully insufficient DOM API.

For example, make a Visual Basic (or RealBasic if you're rabidly anti-Microsoft) form and add a scrolling textarea to it. Take a look at the properties inspector, and notice how many properties it has.

Now do the same thing in DOM. Can Javascript tell which text is selected? No. Can it set the text color, size, or font? No. (There is such a thing as a rich-text textarea, with those options, but DOM API has virtually no access to any of it.) It's simply ridiculous how incomplete DOM is, and that's where your true problems lie.

Of course, most people (even a lot of web developers) confuse Javascript with DOM and assume they're the same thing. They aren't; if you used python or ruby or any other language, you'd still be limited by a crappy DOM.

Re:Got it wrong (5, Insightful)

Anonymous Coward | about 6 years ago | (#24690425)

The other big showstopper is the total lack of multithreading/multitasking. Javascript has an event system, but it can never interrupt a function. This makes it excruciatingly hard to keep a DOM UI fluid while the application handles big chunks of data, and consequently most developers simply stall the UI (for example: Slashdot AJAX UI.)

Re:Got it wrong (1)

Millennium (2451) | about 6 years ago | (#24690459)

Now do the same thing in DOM. Can Javascript tell which text is selected? No.

Actually, it can.

Re:Got it wrong (1)

Stooshie (993666) | about 6 years ago | (#24690277)

... It's just that no one has come up with a better language. If no one comes up with a better language, why reinvent the wheel? ...

ActionScript3.0 anyone? As client side languages goes it's pretty solid. Fully object oriented and ECMA compliant.

If anyone hasn't used flash for a while, it's a whole other beast now. It's not an animation package with a scripting language slotted into the side any more.

Re:Got it wrong (4, Insightful)

AKAImBatman (238306) | about 6 years ago | (#24690397)

ActionScript3.0 anyone?

ActionScript 3.0 == ECMAScript 4.0

Re:Got it wrong (5, Insightful)

hey! (33014) | about 6 years ago | (#24690499)

Some day, I may write an essay "Model View Controller Considered Harmful".

It's not that MVC is a harmful pattern. It's a natural pattern that often emerges from an application of sound design principles to many problems. It's that it has become such a design buzzword that it encourages a kind of "design first analyze later" phenomenon. People are so sure they're going to find MVC that they start with it and go looking for ways to fit the problem to it.

And they find them. The problem is that the first way you find to apply it isn't necessarily the best one or the only one. I think you're brining up an example of how the design first mindset introduces blinders into people's thinking. They can't see the obvious because they're too wrapped up in the idea that MVC will magically simplify design, whereas simplifying design will often generate MVC.

I've seen so many "MVC" designs that were superficially structured as MVC, but were in fact heavyweight, somewhat arbitrary abstractions through which all kinds of responsibilities are squeezed like so much meat through the grinder.

Got it wrong (1)

maestroX (1061960) | about 6 years ago | (#24690683)

Javascript is the glue and the glitz for web apps.

McAlister points out that Javascript is inept for maintaining large apps, with which I agree.

The hours burnt at getting javascript right and maintainable are ridiculous compared to other modern languages.

No alternative for frontend web programming, fine, but I'd never consider javascript for the backend.

yes, this language is a mistake. (0)

Anonymous Coward | about 6 years ago | (#24689837)

yes, this language is a mistake.

javascript:alert('1/0: ' + 1/0 +'\n -1/0: ' + -1/0)

Clearly (1, Funny)

Anonymous Coward | about 6 years ago | (#24689853)

We should patent Javascript right now! It's not like the patent office would reject it on the basis of prior art or anything since they don't seem to know what prior art means.

Re:Clearly (0)

Anonymous Coward | about 6 years ago | (#24690173)

This is why it would be helpful if the editors would correct their stories instead of counting on people like this AC to read enough comments to discover that a given story is completely wrong. (Beyond the fact that he doesn't understand the difference between an application and an approval...)

Javascript/HTML are the way of the past (0)

Anonymous Coward | about 6 years ago | (#24689869)

I foresee API-based web development, and web pages/apps are done programatically, rather than as text markup.

Re:Javascript/HTML are the way of the past (4, Insightful)

AKAImBatman (238306) | about 6 years ago | (#24689993)

I foresee API-based web development, and web pages/apps are done programatically, rather than as text markup.

You forgot to add "I have a dream!" in your one-liner.

Let me get out my crystal ball here... *clunk* *crash* *bang* sorry *oof* *whump* haven't *whim* *whim* *whim* used it *whack!* in awhile. So where was I? Ah yes. I am staring DEEP into the past. Looking at the days when UIs were programmatic. I see when UIs caused long lengths of repetitive and ugly code. I see resource files being invented! It's a miracle! UI programmers no longer have to keep their layout in their code! These resource files appear to be getting more complex... they are supporting graphical layout... productivity is improving!

Wait, what's this? Some silly person on Slashdot is attempting to derail the web form of resource files! He thinks that the DOM should be constructed... programmatically? Has he ever tried building a UI 100% programtically? It's a nightmare!

Levity aside, it can be done, but it's far from the ideal solution. New document formats like XUL may pop up, but suggesting that we move away from keeping layouts separate from our code simply smacks of inexperience.

"Those that fail to learn from history, are doomed to repeat it." - Winston Churchill

Layering is good... (1)

William Robinson (875390) | about 6 years ago | (#24689895)

As all architects say. But I guess the problem will be making everybody agree with it. Because, similar to me, many think that there is never going to be 'one solution for everything.'

JavaScript was a horrible mistake (0)

Anonymous Coward | about 6 years ago | (#24689909)

If it wasn't for JavaScript, the web would be fully interactive, supporting millions of users and creating a marketplace for billions of dollars of transactions.

"Monoculture" (0)

Anonymous Coward | about 6 years ago | (#24689951)

Kind of funny how FOSS advocates only use the term "monoculture" as an attack against Microsoft, and never as a practice among their own projects.

Re:"Monoculture" (1)

mweather (1089505) | about 6 years ago | (#24690175)

Probably because their projects use code from many other projects. It's hard to be a monoculture in FOSS without reinventing the wheel a lot.

Why use Javascript at all? (0)

Anonymous Coward | about 6 years ago | (#24689979)

Why would you do anything on the client at all? For one thing you can't rely on it being available and not disabled.

But the real kicker is that you can't really trust it anyway (for validation and/or screen flow) so you have to do the work on the server anyway.

So that leaves only the 'glitz' for Javascript. Best not to use it then.

For a web application, use it as it is intended. If you need a rich client, just use a client-server architecture.

Re:Why use Javascript at all? (0)

Anonymous Coward | about 6 years ago | (#24690575)

> For one thing you can't rely on it being available and not disabled.

In today's web2.0 world, you make that assertion? Anyone with javascript you can simply write off, the numbers are going to be pretty small.

Re:Why use Javascript at all? (1)

Keeper Of Keys (928206) | about 6 years ago | (#24690599)

Almost right. You can't trust javascript on the client, but there is still a reason to use it. Once you have a solid, server-side application which works over HTTP using regular HTML, javascript is a great usability enhancer. Got a long list of options in a form in your plain vanilla site? Use js to hide the less-frequently used options unless needed. Enhance search boxes with autocompletion. Validate client-side as well, to save a server hit. etc. That's not glitz, it's making the experience better for users with js enabled.

Re:Why use Javascript at all? (1)

DamnStupidElf (649844) | about 6 years ago | (#24690609)

But the real kicker is that you can't really trust it anyway (for validation and/or screen flow) so you have to do the work on the server anyway.
...

For a web application, use it as it is intended. If you need a rich client, just use a client-server architecture.

Guess what, "rich" clients can't be trusted either! Just ask Blizzard or any other company that makes MMORPGs. All the "glitz" is in the client in those games too, while the real work gets done on the server.

I'm always appalled to see how many traditional (e.g. rich client) database applications have a SA level database account and password embedded in the client so that they can perform direct queries against the database. Would you include the database username and password in the HTML you send out to the browser?

I Question McAllister's wisdom (0)

Anonymous Coward | about 6 years ago | (#24689987)

'nuff said!

No scripting language is going to solve (4, Insightful)

godefroi (52421) | about 6 years ago | (#24690007)

... the browser-as-a-ui problem. Browsers are great for online brochures, and terrible for anything more complicated than that. If browsers were a good application framework, we wouldn't need Flash, Air, Silverlight, Java applets, XBAP apps, XUL, etc, etc etc. The sooner we realize that trying to build an "application" directly in html+javascript+whatever-server-side-tech-you-like is a losing strategy, the sooner we can move onto something better.

Re:No scripting language is going to solve (5, Insightful)

avandesande (143899) | about 6 years ago | (#24690225)

I guess the last 10 years where I have put food on my table and deployed 10s of applications that are used by thousands of people are really a loss.
Thanks for clearing that up.

Reasons why browsers are poor application runtimes (4, Informative)

betterunixthanunix (980855) | about 6 years ago | (#24690429)

  1. HTTP is connectionless, but many applications don't make sense in a connectionless setting
  2. Client side privileges are difficult to control, and relying solely on the server for security is not always possible
  3. HTML/XML requests use more bandwidth than binary protocols, which strains slow connections (yes, some people still use dialup, especially mobile users, and here in America many mobile users still rely on 9.6kbps cell phone connections). *ML requests also include a lot of useless tags that describe the "document," even though it is really an RPC request.
  4. XMLHTTPRequest is not standardized across all browsers, and multiple copies of some sections of code must be sent, wasting even more bandwidth.

Anyone who wishes to amend this list is welcome to. I'm *ML requests sure there are even more reasons, that I am just not thinking of at the moment.

Re:Reasons why browsers are poor application runti (1)

avandesande (143899) | about 6 years ago | (#24690497)

You can poke holes in any programming environment, it doesn't make it a 'losing strategy'.

Re:Reasons why browsers are poor application runti (4, Insightful)

betterunixthanunix (980855) | about 6 years ago | (#24690635)

Yes, but those "holes" are usually evident when you try to force an environment to do something that falls way outside of what it was designed for. HTTP is a connectionless, stateless protocol, by design. It makes a lot of sense for document retrieval. Forms make sense, even email front ends make sense. Instant messengers, word processors, spreadsheets, etc. make no sense in the context of document retrieval or exchange. We are going down a fundamentally misguided path when we try to force those applications onto the web. That was my point.

Re:No scripting language is going to solve (1)

DarkOx (621550) | about 6 years ago | (#24690613)

I am sure they are not losses. They are probably successful in that they get the job done and meet the criteria required. Mostly likely they leave a lot to be desired as well. End users more the likely feel they are slow clunky and offer a tedious work flow due to the limitations of the browser paradigm.

Maintenance programs probably cry, because its hard to write JS apps that seem to be sensibly designed to everyone more them a few of them probably thing your reasoning is bassackwards. They probably spend a great deal of time struggling with understanding data flow, and then coupling and cohesion issues. This is not because you coded the app badly but because JS in a web environment just lends itself to that and forces compromise. They would be happier with something that offered a more JSP(Jackson Structured Programming) or OO approach, perhaps even function if they are into that sort of thing.

Managers probably like the low frequency of end user problems and zero setup time. They also probably like short development cycles for new features and fixes. They probably don't like the fact their app that they have invested so much in is tied to the browser technology of the day, won't age well and will ultimately have to be replaced with a ground up rewrite once browsers eveolve some compelling new features.

Re:No scripting language is going to solve (4, Insightful)

AKAImBatman (238306) | about 6 years ago | (#24690365)

If browsers were a good application framework, we wouldn't need Flash, Air, Silverlight, Java applets, XBAP apps, XUL, etc, etc etc.

Newsflash! We don't.

Flash was never welcome on the web. It was responsible for some of the most horrific, unusable sites known to man. For the most part it has disappeared from common UI use. However, it did manage to find two major niches:

1. A standard for Web Video (because no one can friggin' agree on a standard)

2. Online Games

#1 may eventually be taken care of by the new HTML5 <video> tag. Unfortunately, the powers that be still can't agree.

#2 *is* taken care of. Javascript games already exist:

PentriiX Online Multiplayer [wiicade.com]
DHTML Lemmings [elizium.nu]
Hull Breach Online [hullbreachonline.com]
Tetris using Canvas [dnsalias.com]
Pac Man using Canvas [youtube.com]

XUL is a Mozilla technology primarily used to construct Mozilla apps. It is not a web language per se.

Air and Silverlight are solutions looking for problems. The latter is supposed to be a Flash killer at a time when Flash is already at the end of its life. Smooth move, Microsoft.

XBAP is effectively the heavy-weight daddy of Silverlight. Except that it's not really a web app.

The sooner we realize that trying to build an "application" directly in html+javascript+whatever-server-side-tech-you-like is a losing strategy, the sooner we can move onto something better.

So what you're saying is, the sooner we shut down GMail, Yahoo! Mail, Google Docs, Google Maps, Digg, Meebo, and every other DHTML app in existence, the better off we'll be*?

* Ok, maybe in the case of Digg we would be, but that's the exception that proves the rule!

Re:No scripting language is going to solve (1)

avandesande (143899) | about 6 years ago | (#24690439)

You forgot slashdot.....

Re:No scripting language is going to solve (1)

jojisan (465449) | about 6 years ago | (#24690381)

Completely disagree. There are tons of "Browser" app's out there. The whole point is that you have an easy to create model for the display using html, dhtml, css etc. The browser model for app's is perfect because if implemented correctly, it is very portable, both across os platforms and across types of internet devices and even flavors of browsers. I would love to see a form of javascript that is even more powerful and easier to code to. The whole point is making the tools to make applications easier, html and javascript for making the UI is great. Now if someone could actually make the event handling and data processing and I/O functions as easy as the html part then application development could be done by the masses, the same as static html pages. The whole point of making the browser to begin with.

Re:No scripting language is going to solve (2, Interesting)

betterunixthanunix (980855) | about 6 years ago | (#24690487)

As I recall, the point of making the browser was document retrieval; the name "browser" should give you a clue on that one. Let's see...the model of it was...right, hypertext documents that were linked together, thus forming a "web" of interconnected documents -- the "World Wide Web." Where does "application runtime" fit in with that?

Re:No scripting language is going to solve (1)

mabhatter654 (561290) | about 6 years ago | (#24690395)

I agree, I think it's time for HTML5 to be the last web page spec then move on to the next thing.

We need and application framework. It has to break fundamental features of the HTTP/HTML model. It has to be authenticated at OSI session level that fixes huge problems trying to work around statelessness. It has to have something OBDC-like built in to handle data transfers. It can still keep XHTML markup, but streamline it for "moving" apps. It would look a lot like remote X sessions. It would be subject to all the same issues network apps have now, dropped connections would require starting "at the beginning" like other protocols do. I'm thinking something like 5250 or 3730 but with XHTML markup as the stream instead of ugly green-screen. This would require a new kind of server that manages sessions/authentication directly rather than applications managing them, that's more overhead but it would simplify application stacks greatly.

Re:No scripting language is going to solve (2, Insightful)

Bryansix (761547) | about 6 years ago | (#24690579)

This is moronic. The browser has been awesome for applications even simply for the fact that it forces user interfaces that are usable as opposed to some of the shit I could come up with in Flash for instance that would confuse the fuck out of people. Have you ever browsed for flash based UIs? Its like stepping into the twilight zone. I mean seriously, tell me one thing you would like to do in an application that you can't do in a simple browser without some plug-ins. I mean obviously some things won't work well like highly interactive games or image editors. But for like 90% of all the business applications out there which account for more than 90% of the market for web programmers I can't think of anything wrong with using the browser the way it is.

Re:No scripting language is going to solve (2, Funny)

oyenstikker (536040) | about 6 years ago | (#24690637)

Java Web Start!

Re:No scripting language is going to solve (1)

JakeD409 (740143) | about 6 years ago | (#24690675)

Tell [google.com] that [google.com] to [google.com] Google [gmail.com] .

No ActionScript is great! Really! (2, Interesting)

thestudio_bob (894258) | about 6 years ago | (#24690059)

An external browser module capable of executing most of the proposed ECMAScript 4 specification already exists: It's the Adobe Flash plug-in. Other platforms are available as plug-ins, as well, including Curl and REBOL.

As Web developers, we tend to shy away from these alternatives, but only because of the never-ending efforts to refine and standardize JavaScript within the browser itself.

Paid shill maybe? Sounds to me like Adobe is trying to persuade the public that "their" Flash ActionScript [slashdot.org] additions to the standard should have been the way to go.

Adobe AIR does this (1)

foniksonik (573572) | about 6 years ago | (#24690083)

AIR lets you pick your language... it is practically a browser replacement using WebKit as it's html/dom render engine which lets you script however you like.... well, it supports javascript, actionscript and can be extended [onflex.org] to allow for coding in C/C++ and all the other languages that sit on top:

Java, Python, Ruby, PHP, Lua, Perl, C# (Mono), JavaScript

Java (1)

Mr. Slippery (47854) | about 6 years ago | (#24690085)

Well, you could always use a Java applet.

Or implement another language - say, Python [jython.org] - in a Java applet.

But few seem to have had a burning desire to do so. Javascript, bless it's heart, actually works pretty well now.

Re:Java (2, Interesting)

betterunixthanunix (980855) | about 6 years ago | (#24690183)

Javascript works well when you have a program that writes half of the Javascript code for you. Try to write an AJAX application on your own, and see how far you get.

Java applets have an unfortunate reputation for taking a while to load, which is really the only reason they never took off.

Re:Java (2, Interesting)

truthsearch (249536) | about 6 years ago | (#24690443)

I write all of my Javascript by hand, including AJAX. Just like my HTML. With libraries like mootools it's easy. And I'm referring to large, complicated sites that take many months to build. I've never found a program that generates JS for us that I've liked. And I don't see the need when good JS is easy to create when it's done right.

Re:Java (1)

betterunixthanunix (980855) | about 6 years ago | (#24690515)

Last time I tried my hand at that, with browser compatibility being a concern, it wound up being a disaster and we were forced to move to a toolkit. Luckily, the problems started early on, from the very first stages of a prototype, so we didn't lose that much time. Since then, I've moved as far away from web development as I can.

Re:Java (1)

coryking (104614) | about 6 years ago | (#24690543)

I'd go so far as to argue Javascript used to get a bad wrap because only a handful of people bothered to learn it. "back in the day", my javascript experiance consisted of searching google for "Javascript Image Swap" and copy & pasting whatever bit of code I found. I used to comment to colleagues that nobody really knew javascript because I figured 99% of all javascript code was copy & paste garbage.

Once I bothered to learn Javascript and use it ontop of a good cross-browser library like Prototype, I've come to really like Javascript. It is like a cross between my beloved Perl, C# and C.

Javascript is great. The DOM, the tools and web-browsers are what sucks.

XMLHttpRequest aught to be enough for anyone (4, Insightful)

Lord Ender (156273) | about 6 years ago | (#24690095)

The combination of HTML's form controls and Javascript's XMLHttpRequest gives web app designers the power they need to implement 99% of applications as webapps with very little compromise vs. thick-client apps.

Personally, I care very little about the rest of Javascript's abilities. Most often when I see them used, they add nothing useful to the functionality of the applications--just complexity and gee-whiz UI silliness.

Re:XMLHttpRequest aught to be enough for anyone (1)

coryking (104614) | about 6 years ago | (#24690445)

The combination of HTML's form controls and Javascript's XMLHttpRequest gives web app designers the power they need to implement 99% of applications as webapps with very little compromise vs. thick-client apps.

Hahaha.. Yeah. Right pal. Sure you could do it all in HTML/DOM/Javascript, but Jesus, I'd like to ship a product on time and on budget.

Do you have *any* idea how much of a pain in the ass any kind of *serious* web development is? The minute you want to do something interesting, like oh, fire an event when the page is done loading, you are in a world of pain.

No, I see the future as Flex & Silverlight. Both are basically really, really, really beefed up versions of Prototype/Scripalicious (or however google spell checks that for me) and jQuery. When properly used, all your javascript code does is act as a shim between the wild wild west of HTML/DOM and your nice, comfy stable runtimes.

I predict within a year, we'll see many of the "rich" UI controls and "rich" interactions be migrated to Flex/Silverlight. Libraries like Prototype/jQuery will be more centered around acting as shims.

"Web 2.0" companies that do not adopt Silverlight/Flex will not be able to remain competitive. Sure they might be able to crank out the same stuff a Silverlight/Flex shop will be able to, but their development costs will be 10x higher.

No. Javascript/DOM is a dinosaur and the faster we can more to a better runtime stack on these great intertubes, the better we all will be.

Better than other "standards" (1)

pubjames (468013) | about 6 years ago | (#24690131)

Some things are standards by default. Like Microsoft Word format. So by comparison Javascript doesn't look so bad.

lol wut (2, Insightful)

Alex Belits (437) | about 6 years ago | (#24690143)

1. The author is stupid.

Language for client scripts is standardized not based on its convenience for web site developer. It has to be implemented in all clients, and all implementations have to provide clear separation of actions that happen within interface handled by this language's implementation, an anything that affect client platform's security. More things to implement means more incompatibilities and security holes, so standards have to limit the amount of things to implement and clearly provide limits to their functionality. Microsoft tried to break this principle with ActiveX use in its "web technologies", and ended up destroying compatibility and security even within its own product lines.

2. "Model-view-controller" is a misnomer.

Properly it should be called "model-view", there is no "controller". Internal representation of data the program operates on is the "model". Interface between program and everything outside provides "view". Program itself would exist regardless of someone calling it "controller" or not, because without a program nothing would be there to implement model, view, and their relationship, so their description would not be applicable to anything at all. No other term specifies both design principle and simultaneously treats the mechanism that implements it as a component of the principle -- it's not even apples and oranges, it's apples and Z axis.

Re:lol wut (1)

ultranova (717540) | about 6 years ago | (#24690657)

Properly it should be called "model-view", there is no "controller". Internal representation of data the program operates on is the "model". Interface between program and everything outside provides "view". Program itself would exist regardless of someone calling it "controller" or not, because without a program nothing would be there to implement model, view, and their relationship, so their description would not be applicable to anything at all.

Suppose you have a webstore. The "model" would be the data sitting on a database, the "view" would be your browser, and the "controller" would be the web server.

When the student is ready the master will appear ? (1)

what about (730877) | about 6 years ago | (#24690169)

The web was invented right, HTML for documents, HTML forms for simple data entry and APPLETS/OBJECT for complex and "rich" content

The problem is that not all developers look for the right tool for the job, they have a screwdriver and think how to adapt it to a wrench

Of course the correct solution is to use the right tool, but, hey, this means learning something new !

Having javascript doing what java/C# does is just reinventing the wheel, it can be done, someone will even be happy to slam Java once again but really it is just pain
can you immagine having to support all the variations of javascript what will be coming out ?? even if you use google web toolkit the pain will be there in the form of something not working on some browser (with associated angry customer)

I hope that the developers thinking "KISS" (Keep It Simple Stupid) are not too few and apart

Yes, I know, the managers are the ones demanding the wirl, sliding, panning, fading, zooming, jarring, smearing... effects on a simple dataentry web page, I suppose is the Peter Law

Bypass the eBrochure Model (1)

Tablizer (95088) | about 6 years ago | (#24690179)

The HTML browser model is currently an eBrochure model. If one wants to create CRUD screens (business forms and grids), you have to make the eBrochure model bend over backward to achieve it. To allow a more desk-top like feel, the widgets and screen need to be more state-ful. That is, if you issue the command "draw screen X", screen-X will stay there until you tell it to close screen X. (For security-related isolation, an MDI model can be used.)

Further, we need a GUI interface language/standard that is more declarative. Current GUI techniques seem to tie the libraries to specific languages. We need to get away from that. The protocols cannot assume just Java-type inheritance or just Python-type polymorphism, etc. They need to find something that works well despite the paradigm and typing model of the application or scripting language used to process events. A movement away from the influences of ParcPlace-style MVC may be needed to pull it off. It's grown a bit long in the tooth.

What is "Model-View-Controller" (MVC) (1)

SplatMan_DK (1035528) | about 6 years ago | (#24690193)

Having used the Model-View-Controller (MVC) Design Pattern for years, I know that many people (even programmers) are not aware of what it actually is.

I recommend skimming through Martin Fowlers excellent description [martinfowler.com] .

You can also get additional links to PHP, .NET, Ruby, Python and Java examples from the main Wiki article on MVC. [wikipedia.org]

If you have never heard about it (and many of you haven't), you are missing out on a great design pattern.

- Jesper

Oh please... (0)

Anonymous Coward | about 6 years ago | (#24690227)

So why JavaScript? Why not Python, or Lisp, or some other, new language designed with an alternative Web application development methodology in mind?

GWT and Haxe compile to javascript, then there are solutions like hotRuby. Javascript is fine for what it is, Microsoft may want to push their CLR and fanbois their pet languange but I'll never be running these in my browser and ultimately feel there's nothing to be gained by reinventing the wheel.

MVCVC (1)

Doctor Crumb (737936) | about 6 years ago | (#24690273)

"Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.'"

Has the author ever actually developed a web app? Javascript may be doing things like fetching data and sorting lists, but I have never seen a real application that had sufficient non-display javascript to justify splitting it into a MVC pattern. Despite the fact that we have heavyweight JS frameworks like JQuery and mootools, those are still spending their time rendering the view.

Oh quit worrying (0)

Anonymous Coward | about 6 years ago | (#24690289)

Does the name Silverlight mean anything to you??

Since when is javascript only one language? (4, Insightful)

MarkusQ (450076) | about 6 years ago | (#24690303)

We standardized on one language?

Cool. I must have missed that. Now I can strip out all that browser and version detection cruft and just code to the one standard language, right?

--MarkusQ::sarcasm

JavaScript Great! Need Standard DOM presentation (1, Insightful)

Anonymous Coward | about 6 years ago | (#24690327)

Javascript isn't the problem, it does a great job. The problem is all of the presentation differences between browsers. Having to code for every nuance in every browser makes things difficult. Show me a standard that insures that all of the browsers (IE, Firefox, Opera, Safari, etc.) display the DOM the same way and that is what I will back.

Short Answer (1)

CrazyTalk (662055) | about 6 years ago | (#24690399)

Yes. Yes it was.

End the web-apps (1)

evilviper (135110) | about 6 years ago | (#24690405)

I have a better idea. Give up the "web app" mentality all together.

When you need to access your e-mail, load up an MTA. It works an order of magnitude faster, without maxing out your CPU to display a message. It requires an infinitesimal amount of bandwidth, and allows you to read and respond to e-mails even when you're nowhere near an internet connection.

When I'm looking at several items, and want them sorted by popularity, I REALLY DON'T NEED to see an animated status bar show up to tell me that the page is being loaded. Come to think of it, I don't need that fancy menu, made up of hundreds of images. A plain old HTML listbox works better, and IMHO even looks better.

If you have a break-through network application that's going to change the world... GREAT! Write an actual program that will merely communicate over the net. Not some hacked together Javascript that just barely works on a good day, on the right version of the right browser, with all the settings done by your CTO.

Tell me... how would you feel if "whois" was implemented entirely as a web-app? Only way to get whois information was to load-up netsol.com, input an IP/URL and parse the output? It would sure suck, wouldn't it? Yet the trend of the week is to lock-up as many of our programs as possible just like that. And usability suffers dramatically. For all the complaints about Microsoft, I bet most people would be extremely happy with a slow computer if it wasn't for browsing with multiple tabs of unresponsive web-apps that max-out your CPU and RAM. Of course Mozilla and kin are partly to blame as well, but that's rather high hanging fruit when the root of the problem is glorified Visual Basic apps redone over again, even clunkier, in HTML.

I would think... (2, Interesting)

SirGarlon (845873) | about 6 years ago | (#24690449)

Now it's been what, almost 10 years since The Cathedral and the Bazaar, and we still have guys like this author telling us the Wisdom of the Enlightened Few should be dictating standards to us ignorant masses who are, well, doing all the productive work.

I would think we'd be beyond that point by now.

Plug-Ins? (1)

Underfoot (1344699) | about 6 years ago | (#24690501)

Did anyone else read this and think... doesn't this already exist in the form of plug-ins? Flash, QT, Silverlight, etc. They provide this "seperation from the browser for the scripting layer". Not that I'm a fan; I would much rather work natively in the browser with a well crafted javascript library.

AJAX is doomed (1)

c0d3r (156687) | about 6 years ago | (#24690505)

It is my opinion that AJAX is doomed, because all of these toolkits have come out that are essentially complex Javascript libraries that jump through hoops to work on all browsers. What happens when a new browser is released? What happens when an old browser is used? Its not like there is some company qualifying javascript interpreters to meet some standard so a toolkit can be written that will always work in all cases in the future. Its probably going to go back to a Java VM scenario, which is exactly what silverlight is - a minimal .NET VM. Flash/Actionscript (which is an ecmascript interpreter and library in a VM shows hope), but then they don't want to standardize on the ecmascript 4 that it is based on. I just find hopeless to try to write an AJAX application for the enterprise that will work on all browsers since the standardization of Javascript is such a cluster f*ck that we can't be certain whether a script is going to run on all browsers or not.

When it's all said and done... (4, Insightful)

klondike (9378) | about 6 years ago | (#24690507)

...you have reinvented X11

It's for scripting, silly! (2, Interesting)

Pedrito (94783) | about 6 years ago | (#24690513)

I think the problem is the failure to distinguish a scripting language from an application development language. JavaScript is designed for the square hole of scripting. It shouldn't be mashed into the round hole of application development. Nothing lives in a vacuum. Different tools are used for different jobs. Look at any major web app and you'll probably find compiled code and scripting languages like JavaScript and maybe some Perl and maybe some other stuff.

If you make all the tools do everything, then they'll all be cluttered masses of junk. If on the other hand, different tools perform different functions, then instead of using one cluttered mass of junk, you can uses several tools that each perform specific types of tasks that they're appropriate to, as it should be.

Sure, it can be a pain in the butt to learn to use different tools, but it's far less of a pain in the butt than trying to maintain a big app written with a nasty language that tries to do more than it should.

Was Standardizing On JavaScript a Mistake? (1)

fartrader (323244) | about 6 years ago | (#24690549)

> Was JavaScript a Mistake?

There, fixed it for you.

Plugins get a bad rap. (2, Insightful)

argent (18001) | about 6 years ago | (#24690577)

I agree, plugins get a bad rap, but the biggest problem with plugins is that they are restricted to a little box in the browser window. What is needed is not a better Javascript, but a better way of doing plugins. What he's talking about, I think (correct me if I'm wrong), is this: let a web page have a Java component (for example) that doesn't run in a little box... but instead runs in the background and updates the page, hiding and showing components, triggering little bits of javascript glue, and generally doing the heavy lifting without having any graphical elements of its own...

Mistakes? (1)

LibertineR (591918) | about 6 years ago | (#24690587)

Not after I built more than 40 web sites on standard ASP with VB Script.

Not after I became a Fireworks god, because Photoshop wasnt supposed to be a 'web tool'.

Dont you dare ask me about Alpha Channel support under IE 5-6.

Mistakes,...I've had a few,.....and now I reach.....the...oh fuck it.

In this case, the real question: is ECMA a mistake (4, Interesting)

expro (597113) | about 6 years ago | (#24690593)

Netscape went with ECMA early on and got good results standardizing Javascript. Since that time ECMA whole-sale sold out to Microsoft. Ask any normal party that has been involved and I think you will get the same answer. They are to be blamed for not only this Javascript failure, but for the whole OOXML fiasco. Microsoft went there with a single goal in mind: to block Javascript to allow their own .net-related standards to become relevant, which they get rubber-stamped through ECMA.

To a lesser degree, W3C has also sold out to Microsoft in their efforts to sell SOAP, deemphasize all the web standards Microsoft does not want to be important so, for example, they don't have to waste effort competing in the browser wars when they think they should just forever be declared the winner without having to do anything that benefits the web in general.

Should Javascript be the defacto standard on the web? Only in so far as it is useful. Like anything else on the web, if it ceases being useful, people will build a new path and do something else (whatwg, anyone?). But it is silly to call it useful or not useful based upon Microsoft/ECMA blocking the way. It sounds to me like there is some good work going on inspite of the monopolist blocade. I would hate to never see it come to light because of the many formal committees that sold out to Microsoft.

I love competition and would love to see something an order of magnitude better take over and rule the day, but that should be based upon technical merit and competing against the current success, ubiquity, and any irreparable flaws of Javascript.

I have every confidence that as ECMA continues to be paid to make good things irrelevant and bad things relevant, other standards organizations, which may start out being ad-hoc, will rise up to fill the void, and Microsoft will continue being irrelevant to those they do not own until they can really come up with something generally useful as a standard.

Standardization vs. invention (1, Troll)

Hugonz (20064) | about 6 years ago | (#24690633)

Had the work continued, McAllister argues, it could have ushered in an era of large-scale application development that would ensure the browser's ability to meet our evolving needs in the years ahead.

This is simply a misconception. The idea that creativity can come out of a standards body is flawed. Individual coders and companies come up with the tools, the implementation and the interaction, and standard bodies later take notice... they cannot usher in their way out of a paper bag....

ECMA and ISO are pawns for large businesses (1)

Locutus (9039) | about 6 years ago | (#24690665)

so the development community should do what is right and forget what business interest(s) have done to manipulate those organizations committee projects.

If MS-Office Open XML did not show you this then I would have no idea how else to make this so obvious.

So the community should either just get it done on their own or find an organization which has not shown they can be bought and/or over run by business-only interests. IMO.

The ECMA and ISO have outlived their usefulness.

LoB

Was Standardizing On JavaScript a Mistake? (1)

John Hasler (414242) | about 6 years ago | (#24690681)

Yes, as was standardizing on HTML. We should have used S-expressions, which would have led naturally to Lisp as the standard scripting language.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

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>