Slashdot Mirror
Was Standardizing On JavaScript a Mistake?
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.'"
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...
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?
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.
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.
Javascript + Nintendo DSi = DSiCade
yes, this language is a mistake.
javascript:alert('1/0: ' + 1/0 +'\n -1/0: ' + -1/0)
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.
I foresee API-based web development, and web pages/apps are done programatically, rather than as text markup.
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.'
hilarious
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.
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.
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.
'nuff said!
... 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.
Karma: Poor (Mostly affected by lame karma-joke sigs)
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 additions to the standard should have been the way to go.
The real Sig captains the Northwestern. This one captains
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 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
A fool throws a stone into a well and a thousand sages can not remove it.
Well, you could always use a Java applet.
Or implement another language - say, Python - 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.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
Some things are standards by default. Like Microsoft Word format. So by comparison Javascript doesn't look so bad.
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.
Contrary to the popular belief, there indeed is no God.
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
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.
Table-ized A.I.
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.
.NET, Ruby, Python and Java examples from the main Wiki article on MVC.
I recommend skimming through Martin Fowlers excellent description.
You can also get additional links to PHP,
If you have never heard about it (and many of you haven't), you are missing out on a great design pattern.
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
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.
"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.
Does the name Silverlight mean anything to you??
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 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.
Yes. Yes it was.
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.
Palm trees and 8
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.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
You can poke holes in any programming environment, it doesn't make it a 'losing strategy'.
love is just extroverted narcissism
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.
I mentioned tinker-toys once in a post - now I'm modded down for life.
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.
...you have reinvented X11
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 JavaScript a Mistake?
There, fixed it for you.
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...
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.
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.
Comment removed based on user account deletion
The "real" way is via the DOM.
window.onload is the DOM event you're looking for.
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....
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.
Palm trees and 8
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
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
Yes, as was standardizing on HTML. We should have used S-expressions, which would have led naturally to Lisp as the standard scripting language.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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
1. Just treat HTTP as a message passing facility and build a connectionless layer on top of it when you need to.
2. Client side privileges are *impossible* to control, period.
3. Turn on gzip compression for server responses, and send your own requests compressed if you really care about it that much. Or simplify the requests.
4. The semantics of "open" is not standardized across all operating systems. You may or may not have file locking, 64-bit offset support, long file name support, case insensitivity, extended attributes, ACLs, alternate data streams, or a host of other features. Welcome to programming.
1. IP is connectionless, but somehow TCP works anyway. Session is a layer.
2. Client side privileges are IMPOSSIBLE to control, relying on the server for security is mandatory.
3. Bandwidth does not govern RPC performance -- service time does.
4. The W3C is addressing XMLHTTPRequest standardization.
Liberty you never use is liberty you lose.
1. By Many you mean 1% of the total applications excluding games written. Most frameworks for applications are this. Take Input process data produce output. Step one takes time so there is no need to keep a connection there. step 2 - 3 is done on the server. After you get the data you don't need the connection until the next input. Your way will have the server get overloaded much quicker then with Web Apps as it needs to keep connections until they quit.
2. I have heard this argument before however I have NEVER in 10 years ever seen this to come across a situation where not relying solely on the server for security didn't work. The server controls what the client see and it also can filer or reject what the client asks. The only case I can think of preventing someone from printing your document... However this exists across all other apps where doing a screen shot and printing that works too.
3. Most of the bandwidth used is not text data but binary information like pictures which take the most time. 9.6kbs is 1k a second. normally an complex page is about 10k so that is 10 seconds. But wait most browsers will render the html before it is completely downloaded so you can read input before it completes. Secondly most mobile users who use this speed are on phones that aren't designed well for the web and not recommended to for use of most apps. The iPhones and other smartphones more suitable for wireless web use a faster connection.
4. The extra stuff will only take a fraction of a second.
Techniques such as AJAX actually improve speed as it allows the server to handle smaller chunks and send it smaller chunks using the clients PC (which normally has a LOT of CPU Free to do most of the work) Covering the gap you mentioned in 1.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
What is with this strange new breed of programmer who thinks that everything should be crammed into the MVC pattern?
Sensibilities be damned, they're going to make it work like Ruby-On-Rails if it kills them. Why not look at the requirement and then decide on an established design pattern (if any!)? Don't go trying to change a language we're all very happy with just because your knowledge is limited to one paradigm.
We should going back to designing things that work, not working things to a design.
Javascript (well, ECMAScript) is actually quite powerful. True it lacks a few of the features you'd expect to see on common UI languages (multhreading anybody?), but you can't have a strop and fragment ECMAScript because of that.
It is, by the way, a prototype-based language, so the sooner you stop deluding yourselves into thinking that you can code like it's OO, the better.
If you want to complain about something, whine about the totally fucking USELESS Document Object Model (DOM) we're given to work with today, talk about the weakest link... If there's ANYTHING that needs a total overhaul on the web today, its the DOM.
You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
1. You mean stateless but that's been solved with sessions.
2. Privileges must be controlled on the server. That's the only reasonably safe place to do it. If you don't have access to the server, don't expect the app to be secure.
3. Enable gzip on the webserver.
4. XMLHTTPRequest might not be an official standard but it is supported in all major browsers so it is a standard that way.
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
I've never tried it, but there's "com.sun.java.browser.dom", which is supposed to let your applet access the browser's Document Object Model. In keeping with the applet security model, there are limits on what can be done to the DOM; I think access is read-only, although the documentation isn't clear.
In typical Sun fashion, rather than having a basic API that works, this is tied in with "Project Metro" and "GlassFish", and is supposed to work with a Java applications server, so Sun can make some money on the server side. Try these JMaki examples, which correspond to simple AJAX applications but are implemented in Java.
Java itself would be a good alternative to JavaScript. At least it scales up better. But Sun insists on burying the language under a mountain of mediocre and ever-changing libraries.
As we all know, all manner of rich web applications can be created using ONLY XHTML and Javascript. So I must assume that the REAL problem this chap has is ease of use.
Now I'm sure there's something to be said for that, and yes, it'd be nice if browsers could agree on an implementation and stick to it, but shit happens.
However the when you start sacrificing power for ease of use, you'll eventually end up with RoR. At which point all the serious developers will tell you to piss off and you'll end up with a language good for doing about four things.
You feel sleepy. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise.
Take it for what its worth, but OO is a more prevalent model, than proto-type based languages or for that matter functional languages; we need an alternative.
It would be easier to keep working with the same OO mind set, instead of switching back and fourth between javascript and your language of choice.
These days #3 is dealt with by using JSON, which has very little bloat over a binary protocol.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
This post could be rewritten as "Reason browsers are the most popular runtimes"
Business. Numbers. Money. People. Computer World.
Reason why users like web apps even though they kind of suck: can go from computer to computer and still get your stuff. Not limited to a particular OS or browser.
Ad hoc standards? Interesting. If we can open source the code, and have an open standard, both of which are made up of volunteers' work, maybe we should open the standards bodies, as well? It's an interesting thought that if a standards body were to become corrupt, you could fork it and keep on truckin'.... :)
1) Why are languages like Java used for web applications when they are used for not many local applications?
2) Why is every web app, after loading fully, very sluggish in my experience? Is the Java(script) inherently slow or do people just implement it poorly?
"I zero-index my hamsters" - Willtor (147206)
Agreed. I'd actually call it a great language, in the abstract. I was poking fun at the implementations, many of which aren't so hot.
Whoa. Where the heck did that come from? As someone who started OOP with Simula in the '70s, and has actually implemented several OOP languages, including one that was prototype based and one that was method pattern based (sort of like CLOS, but not as ambitious) I'd say you were way out of line with that remark.
Don't automatically assume that you know more than everyone you meet on line, you'll just wind up looking like a jerk.
--MarkusQ
The Javascript from a few years ago is gone (even though the actual language hasn't changed much).
.js these days, and the trend is accelerating due to the rapidly improving quality of both Javascript frameworks and the browsers themselves...
There are some very slick applications being written in
Not convinced?
Take a look at qooxdoo: http://demo.qooxdoo.org/devel/demobrowser/
-Chris
Internet is connectionless. It is based on exchange of data packets. If you need connections, you have to emulate them over the underlying packet protocol; the only question is whether you do this on OS (TCP/IP) or application (session id's) level. Both work.
Relying on a client for security is unbelievably stupid when that client is running on the machine possessed, owned and operated by the very entity the security is directed against. You either implement security in the server or not at all.
How likely do you think those cellphones would support the new, non-browser webapp client ? Which, in all likelihood, would be geared towards presenting lots and lots and lots of graphics and animations, in the exact layout the graphics designer intended and damn the different resolutions ?
True. However, if you add a new contender, and it starts gaining popularity, Microsoft will simply publish their own, slightly incompatible client in an attempt to get lockdown, which will return us to the current situation.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
I agree. HTML is good at rendering documents, not advanced 2D or 3D graphics which is what people seem to want on the web on the web right now. You might be able do this with ECMA Script + HTML5, but you might as well shove a watermelon down a garbage disposal.
If you want graphics on the web, just combine ECMA Script with a runtime environment desgined for rendering graphics. No surprise, this exists in the form of Flash. The only problem with using Flash as the 'view' for web applications is that it isn't very well integrated with DOM. Flash also isn't fast enough yet to do advanced 3D graphics very well yet, but this should change with the next generation.
Standardizing ECMA Script was not a bad idea, but standardzing the ECMA Script 4 draft specification used for Action Script 2 would be a bad idea since it would take the crux of a commercial technology and make into a web standard.
Just because it's not an ECMA standard, however, doesn't mean the technology can't be used by people other than Adobe. If Microsoft or Mozilla want to roll out commercial browsers with an OpenGL style implementations the ES4 draft spec, no one is stopping them.
That wasn't directed at you. It was a general "you" directed to those who complain about the lack of features such as inheritance.
You mean we could - theoretically - use browsers for what they were meant for (browsing hypermedia) and NOT try to turn the browser into the all-in-one universal application delivery platform????
BRILLIANT!
I'd like to hear more about your ideas, please subscribe me to your newsletter.
// TODO: Insert Cool Sig
The HTML DOM is the view, the Browser is the Controller, the Model is implemented in Javascript, and the server would be a source of data.
You have to implement some of the model on the server too. Otherwise, it will become possible to make the data inconsistent. In addition, you may have to make the data accessible to user agents that do not implement script.
Client side privileges are difficult to control, and relying solely on the server for security is not always possible
Bullshit. Client side priveleges are impossible to control, as someone else said. Just ask the RIAA or MPAA is you can control the way someone uses their own computer.
As for why servers can't control security, I ask you why not? Everything that takes place between computers takes place on the server. All of the code that actually processes and stores the request happens on the server. What access would you like to control in an application that you can't control on the server?
1. This is a feature, not a bug - stateless connections force you to push the state elsewhere (database,client) and allow you to scale easier to large user bases
2. As a user, I like having control over the client side thanks
3. mod_deflate
4. Not a fundamental flaw, and something that could easily be addressed if certain browser makers didn't want to strangle the web
There are certainly some applications where web servers are not well suited like real-time video editing, but the success of the web has partly been due to these deficiencies that you point out (stateless, anarchic). In fact I think you'll see it encroach more and more on traditionally desktop areas - already many help documents, most email, and many online shopping activities are done via the browser.
Anything involving fetching/editing/sharing discrete resources is well suited to the web and the strictures it imposes. That includes most of what we consider to be natural desktop applications today.
Please stop saying HTTP is connectionless, it is not. It is only stateless.
We are going down a fundamentally misguided path when we try to force those applications onto the web. That was my point.
Then what should we use instead of the web to instantly deploy these applications to end users?
Ever heard of this little thing called "native applications running on your computer"?
Ever heard of this little thing called "not owning the computer you use therefore not having privileges to install native applications"? What about "owning a Dell PC running Ubuntu when the developer uses a Mac running Mac OS X"?
you are asking the question "what is the best way to build applications on the internet?"
you should be asking the question "how can i do {xyz} without needing an application at all?"
Browsers are great for online brochures, and terrible for anything more complicated than that.
you are 100% correct. but in that observation of yours is not the weakness of the internet, but the reason the internet is as popular as it is, its strength: anyone can get on there and build something. low barrier to entry. thats why it so popular
you assume the internet exists so that developers can write applications easily in their ivory towers of clean and robust code. wrong. the internet exists so joe shmoe in his rec room pc can paste something up there in mangled html without closing tags
in other words, get used to the tower of babel. it rankles that wing of the developer community which is extremely anal retentive. now, being very anal retentive is a very useful skill when being a programmer. but its not a very useful tool for figuring out why the world is as messy at is
so let me explain it to you one more time: sure, you can build some sort of application interface that you infer is the "superior" way to go in your comment above, but this will be an esoteric niche development environment not many people familiarize themselves with, while everyone else keeps cranking out html. such that, when it comes time to finally build a large complicated application, the developers will be catering to the most popular environment in the house, the html one, even though they would have a much easier time of it in your specialized environment. your "superior" interface will remain dusty and forgotten and unused
repeat after me: low barrier to entry is a more important consideration than writing clean code
low barrier to entry creates popularity. popularity establishes dominance. domainance dictates the environment in which you code. that's why
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
A new application-serving (rather than text-serving) Internet protocol.
You know how FTP, email, and the web are all different types of Internet connections? Yes? Ok! Now imagine an Application-Web designed from the ground up for serving applications.
Upon a cursory glance, Javascript seems like a good language. It takes elements from some of the most popular and well-known languages (C,C++,Java) and makes it into something appropriate for scripting. But with experience, I've found that Javascript really only borrowed the most trivial features of those languages, and forgot everything we learned about computer science in the last 20 years.
The most awful example is the concept of "undefined." Javascript is the only language I know of where it is legal to say:
if (MyObject.NonExistantVariable == 7) // Do some work
{
}
(BTW: This expression returns false)
That is the source of most Javascript errors in a large project. A property was removed, a variable renamed, or misspelled, or never initialized. The value of the non-existant variable is "undefined" which is the bane of Javascript. There's even a special === operator for specifically comparing to undefined! And people thought NULL was bad!
It gets worse because Javascript is a glue language between other things like the HTML DOM or XML/SOAP/JSON so those object definitions can change at any time, and you won't know it broke your Javascript until you hit the right line of code in the right order.
Javascript is a language with totally dynamic typing and scoping. So it is impossible to compile, or type check. Even most scripty languages like PERL can detect more errors at load-time of the file than can be detected in Javascript.
just make a web page that contain nothing but a Java applet that connects back to your server. See http://www.mudmagic.com/java-client/ for example.
This breaks for customers who use any of several non-PC platforms such as Wii and iPod Touch/iPhone. Neither has a JVM. Compare the number of angry customers who use an obscure setup for which your JavaScript code breaks to the number of angry customers you'll get when Java applets don't work at all on several common setups.
JavaScript is designed for the square hole of scripting. It shouldn't be mashed into the round hole of application development.
What application development language and deployment method do you recommend for applications that can be deployed from a web site to end users, even if the end users are not the administrator of the computer that they happen to be using?
underlying client-side logic... the browser handle the View.... Controller exist somewhere else.... independent of the presentation layer.
I have to listen to this architectural BS two hours every day at work, you insensitive clod!
Joke aside, I read TFA - it is naive.
Like, 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.
So, you mean build the site with flash? Btw, Curl and REBOL - what are you smoking! If the browser capabilities are so unpredictable, which baseline do I target? How many assumptions can I make?
But if sticking to a single way of doing things is what we want, .... at thousands of enterprises worldwide, right now. It's called Lotus Notes.
God.
Life is just a conviction.
Now imagine an Application-Web designed from the ground up for serving applications.
So how would you recommend to deploy this Application-Web browser to end users?
Great! First we had browsers which never could quite follow the HTML standard in the same way. Then we get Flash for Windows and Mac with second class Linux support, no chance of support on any other emerging desktop platform and embedded support that doesn't seem to acutally do anything. (Ever seen flash for Windows Mobile actually render something?). Now we have silverlight, and if this guy has his way...
I can't wait to have to install Microsoft Python to get website A to work which breaks Website B because it conflicts with Mozilla Python Browser Plugin while Website C is still waiting for a decent version of Adobe C# plugin to be released on Linux and Yet another website requires D# which requires F# which circularly depends on D#...
And that's on the user's end, can't wait to deal with these issues as a developer!
Please, XML, CSS and ECMASript with a few annoying missing features added and let's be done with it.
Right. I even gave several examples of such platforms (I'm talking platforms, you're talking protocol, but I think you mean platform).
Air, Flash, Sliverlight, Applets, ActiveX, there've been lots of entries.
Karma: Poor (Mostly affected by lame karma-joke sigs)
It's not specifically JavaScript that's the problem. The problem is thinking that one language will solve all application requirements.
What we need is a way to write applications for this (web) platform with any language you want/need... just like the desktop.
Ideally we'd first have a VM of sorts on the browser... Separate the language from the execution. This would allow people to use their language of choice, and to take advantage of existing languages in order to write web-based display applications. For example, if you look at all the display methods right now: JavaScript, Flash, Java applets, etc. They all have pros and cons to their underlying technologies and browser tie-ins, but they're all tied to the specific language... I may like Java's concept of having a VM/byte-code interpreter, but I'm stuck with doing everything in Java. For some tasks, that just may not be ideal.
Once you've got that separation, then you can do some interesting things and actually learn past lessons. This whole concept of networked computing, remote displays, and server-oriented applications is actually quite old. The primary thing that's changed in the past 20 years is that we have smarter terminals.
So the next step is to develop something like X11 (or perhaps just extend X11?), but take advantage of the fact that we have smart terminals. Allow for the widgets and toolkit stuff (eg. gtk, Qt, etc.) to be loadable onto the remote display. This would provide the benefit that we want... low network overhead and high user interactivity for applications.
This would also allow us to standardize on UI toolkits much more so than we do now with AJAX, et. al. But because the UI can now be standardized, they can also be cached. Once you download a toolkit, you don't need to download it again.
But at the same time if some developers don't like the toolkit, you could easily have others without having to re-write your entire infrastructure. (Think Xaw, Motif, GTK, Qt. If you think that's too many, try to count the number of display toolkits commonly used in today's web application space).
The other benefit this gives you is the ability to just write applications once. You'd actually be able to share code bases when trying to support applications on the desktop and on the web. And this would be no more work than supporting, say Windows and Mac.
So the mistake we actually have has developers (in my view) is not recognizing that the web is a platform just like any other platform. And that we should treat it as such.
Talk to someone who knows the inside story and can tell you (because you work for the same company and can discuss what happens at W3C) what happened to the DOM committee and vigorous efforts to add modules, cleanup, or take other actions to solve precisely those deficiencies at W3C.
Hint. For the sake of argument, assume Microsoft owns W3C control to some extend the same way they own ECMA (now obviously after .net, OOXML, and Javascript subversive actions).
Comment removed based on user account deletion
I have absolutely no idea what you're talking about.
Comment of the year
We have networked window systems for people who don't own their own computers.
Which such window system is widely deployed in both homes and businesses as of 2008?
Writing a portable native app is no harder than writing a portable web app
Citation needed. The developer needs to own and maintain at least one machine of each architecture and operating system to compile and test on, which can get prohibitively expensive for hobbyists and small businesses. In particular, this would mean that a developer who had previously tested web apps in Safari for Windows would have to buy a Mac to reach Mac users. Worse, on several platforms such as Wii with Internet Channel, PSP, PLAYSTATION 3, and iPhone/iPod Touch, DHTML apps will run just fine, but native apps need to be digitally signed by the platform vendor or the operating system will refuse to run them.
One of the biggest issues I see with the current system is that you have to have business rules in two places with no easy way to synchronize between those two places. You have rules on the back end server and data base and you have to re-implement those rules again in all your client software that runs in someones browser. This sucks and leads to a lot of errors.
We know.
Focusing on one standard to an ever present tech problem isn't bad. However, hemming, hawing, messing about and eventually chickening out of a process well underway *is*.
I was struck with bedazzlement when I read some hissy-fit sissy problem in getting the next technology upgrade for JS underway. WTF?
Imagine this with the Linux kernel. It would be less popular than Hurd, if they'd constantly pull such amature shit.
We've got Linus Torwalds, who, as far as I can tell, does a really good job at gouverning the kernel. And unless he suddenly does something completely insane, like demanding that all FSes get removed in favour of a FAT16 clone or something other equally bizar, what ever he decides for the kernel trumps everyone else. And since he - and everyone he listens to - is involved in kernel developement on a daily basis, all infighting takes place by praticed & educated professionals, well before they go public with a new stable.
You *ONLY* get such PR disasters as the recent JS standardisation botch with to many PhD-cert waving wisecracks involved in the decicision who actually don't do any real day-to-day work on the project. Such as a relevant reference implementation of JS or something. Add in a few companies with diverging commercial interests and some academic pissing contests and shit like this happens.
Another example:
PHP is a lovable quirky piece of domain specific language. Each time they do an upgrade it breaks the last one. Yet how many do actually complain? Nearly zilch, compared to the size of the userbase. People are aware that all involved in the upgrade did carefull considerations of all cons and pros of each aspect, so the can easyly accept the specs of the new release. You don't see PHP fraying about into different dialects, *because* it's a fairly tight professional crew who's responsible for it.
Bottom line:
Nothing to see here, move on. Let's hope they don't do such PR disasters again.
We suffer more in our imagination than in reality. - Seneca
One thing I've learned over the years is that any technology declared to be "the standard" is probably not anywhere near being a standard. Just because a lot of people use something doesn't make it a standard. Furthermore, when something is declared "the standard" I usually find myself using non-standard stuff that does things better than the supposed "standard" stuff does. The last thing I've noticed is that even the most standard standards don't work as well as they should across multiple platforms or the Internet, so why the hell bother with a standard in the first place?
You were 100% right on the deficiencies of the DOM. Sorry I can't spell it out for you. Since W3C participants sign a non-disclosure, speculate for yourself why, and as a clue you have the advantage of seeing exactly what Microsoft is doing to Javascript through ECMA and seeing how they would just like those troublesome browsers to go away due to their neglect.
Were all the bright browser vendors previously at the W3C working on DOM and related standards just too stupid to see that DOM had deficiencies with respect to good web applications? Did they all just lose interest? If you think that, you haven't looked very hard.
I never understood why more browsers don't support arbitrary scripting languages. The DOM isn't ECMAScript specific. Microsoft did this for a while with vbscript, and the html standard supports both the language and type fields to specify the script you're using within the script block. Rather then overly complicate the original JavaScript programming paradigm to support new web standards, why not just support python/perl client-side in addition to javascript?
I got the impression that the W3C decided that "XForms Is The Future", and therefore was steadfastly ignoring the deficiencies in HTML forms. (Which are still virtually identical to those found in Netscape 2, and never were completely documented in "DOM0".)
Obviously MS and other W3C companies have their own competing technologies, but prior to HTML5 I don't know of any efforts to improve the state of HTML forms.
Business. Numbers. Money. People. Computer World.
HTML forms is not DOM, Javascript, or the bulk of web applications, nor am I aware of significant support of XForms from any browser vendor. Deficiencies in DOM would have nothing to do with XForms. Interesting, though, how HTML5, too, was mostly forced to occur outside of W3C and the participants were, to the extent I know of, browser people. Is a pattern emerging?
The premise of this discussion was the need to design something completely new, which would replace HTTP and HTML in order to support easier to develop Web apps.
Slash does not allow a comment to have more than one parent. How should I have made it clearer that I was replying to both your comment and mabhatter654's comment?
You are against the core philosophies of the web, whether you realize it or not.
Your vision of the future of the web is my worst nightmare.
Well, the original complaint was about form elements and 'widgets', so yes I believe it's directly relevant. How much javascript "gunk" is directly related to data input?
Business. Numbers. Money. People. Computer World.
You don't HAVE to use XML for RPC requests. Heck, the XmlHttpRequest object doesn't even force you to use XML.
JSON is a much more concise RPC vehicle.
Further, HTTP isn't SUCH a bad RPC protocol. It's remarkably light-weight. HTTP Headers can be a little as 2 lines of text. And a lot of RPC functionality that doesn't involve sending or receiving much data (for example, marking a message as Read in Gmail) you can use a simple HEAD request instead of GET or POST and use the HTTP Status code to determine success/failure in your browser.
A binary protocol would be faster. No doubt about it. But if a dev understands HTTP and uses JSON, it can be pretty speedy.
The only problem with javascript is lack of tools for it. I work on a large web app that has tons of javascript, but we use Eclipse and the only decent syntax checker out there for Eclipse, Aptana, causes my Eclipse to become unstable and constantly crash.
1) Others debunked quite well. :(
2) When is relying on the server for security not possible? That's really the only time you can guarantee that a modified client isn't doing bad things.
3) Ah, but once the main page is loaded, XMLHTTPRequest lets you get smaller chunks of data than you would normally get. With JSON, you can reduce that even further. And nothing's stopping you from writing your own codec to send information down the pipeline.
Slashdot is a great example of AJAX making things lighter. With Discussion2, I don't have to download the entire Slashdot page to view nested comments. I just click on the comment, and it loads the relevant data.
4) Yeah, standardization is a problem
ES4 didn't prevent any of the prototype-based coding techniques used in ES3 (aka "JavaScript") -- in fact, it bent over backwards to preserve them.
Rather, it added an additional, *optional* set of tools for the programmer to use -- classes, namespaces, early binding, optional typing, etc.
I realize most Slashdot readers probably won't have any experience coding in ActionScript 3 -- OMG, a "proprietary" language! -- but it's essentially a subset of the proposed ES4, and being able to use the above tools, in addition to prototypes and completely soft typing, makes for a wonderful coding experience IMHO.
The Google Web Toolkit has it right: treat JavaScript as a fancy virtual machine, and compile full featured languages down to it. I don't worry about JavaScript any more.
Javascript and the DOM API are by different organizations! DOM could use work and better support but javascript is fine.
Javascript can add some minor changes but nothing major like class definitions and strict typing are required nor should they be desired.
Javascript is a SCRIPTING LANGUAGE!
Javascript doesn't need to evolve into JAVA, we already HAVE JAVA!
Somebody make DOM for JAVA applets before they screw up Javascript!
How about better integration of JAVA applets into webpages? If you want major desktop application development on a website you can use the #1 programming language with its tons of bloated features and slow compilation (and tiny executable foot print) that is ALREADY powering massive desktop and web applications.
Democracy Now! - uncensored, anti-establishment news
If that is the best you can do, I apologize for wasting your time.
Or, maybe, we can have some programs that run localy to the client, they can send files throug the net if needed. I know it is a new, untested idea, but makes some sense to me.
What is really annoying is that distributing ECMAScript apps over the web is a solution to a legal problem (licencing), not a technical one, that a few players decided to create and could be solved by several ways (one of them being free software, but there are others). Now everybody is strugling to reinvent lots and lots of weels just because of that.
Rethinking email
Ok, not by that margin, but Java Script is still worse.
Rethinking email
Who happen to think javascript is a particularly cheezy dynamic scripting language and would jettison it in 14 milliseconds if there WAS any way to have a viable alternative.
The only reason javascript still exists is because any author of client side code that tried to use anything else would have to get all their clients to download another plugin. Worse, you would have to implement said plugin for at least 4 browsers on 3 major desktop platforms and who knows what all on mobile.
So really, javascript need not be anything beyond marginally functional to be de-facto the one and only client side scripting language.
I won't even go into its deficiencies. Suffice it to say we are all paying for Brendan Eich's hubris in thinking he was the next Larry Wall. Sorry, not hardly.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
JavaScript 1.5 already allows different modes of programming, procedural, functional (functions are first class citizens, supporting closures) and various flavours of OO (It could provide slightly more support to make inheritance more effecient. Freeing up __proto__ would be nice as well).
I even implemented a simple property list unification facility, allowing some logical programming tricks.
Agreed, the main problem is the DOM.
But still, there have been a number of core differences over the years, from event bubbling to Function#caller(), some edge cases w. nested functions, things like (1 != "1"), Date#getYear(), string subscripting, and so on.
Nothing as bad as the DOM differences, granted, but enough to gripe about in what is, after all, a pretty small language. -- MarkusQ
You CAN call java from javascript, and the other way around too. The hitch is you still have to have a BIT of javascript in there, but it could be as trivial as an event handler that proxies to java.
There are plenty of other issues with applets though, trust me, I've written some fairly decent complexity ones. The only GUI library you have is AWT, which is best not described, the expletives would be unpleasant...
In any case, you can do what you describe now. Frankly though if JS was a better language this would not be an issue, but it isn't...
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
". Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.'""
Then you've just created JSF...which to pretty much the whole web, for some reason I don't understand, hates. Yes, that's a harsh hate [for Java]--maybe due to the huge contingency of PHP/Python/Perl/Ruby/C# folks which write code that powers most of the 'free' web? (needed to jab)
The "problem" with web applications is that most people don't ever think of upgrading their browsers and some will refuse to simply because it's new and because their existing browser works, thus the huge number of IE5 users in the wild.
So if you want to get a better platform for web applications what you need to do is convince Microsoft of installing it by default in windows and wait.
Of course there is no way Microsoft is going to cooperate with a GPL scripting engine, it will have to be BSD if not "Shared Source" licenced with copyrights assigned to Microsoft. And you can bet your shoes it is going to be extended in incompatible; Windows oriented ways.
Mind you, isn't this what Silverlight is about?
Ok, right now Microsoft is being very cooperative with Silverlight since it has to beat flash before E.E.E.-ing it. Flash got there because people *DID* install it so perhaps a better javascript can be distributed in the form of a free plugin for IE et all.
The second problem of course is that document oriented programing is very easy. perhaps web applications *are* the way most applications should be organized because document orientation mkes a lot of sense.
But... the future refused to change.
Javascript fails miserably. It needs the same things that made old school POSIX C a standard:
- A good language (e.g., multiple return values)
- POSIX like libraries as standard features
- A compiler/syntax/semantic checker
I'm hoping that silverlight (ugh Microsoft fear!) actaully becomes an ISO/ANSI/ECMA standard so that I can develop multi-platform for both desktop forms based applications and widgets hosted in the browser.
Well, maybe I'm a little sensitive to the now standardized swipes at perl, but may I point out that perl does indeed have lexical namespaces? It could be the author was thinking of PHP (which if I understand correctly, also has namespaces now, though only in it's latest version).
In any case: does anyone have any real evidence that strong typing actually works? Java was sold to people on the basis of it's maintainability -- was that claim true? How would you know?
Myself, I've been primarily a perl programmer for a decade, and you can easily count the number of occasions I've had my fingers burned by type-confusion on one hand. There are CS geeks out there who are incredibly strong-typing fanatics, way out of proportion to how useful the feature is.
(Just a hint: if you want to attack perl intelligently, try "lack of standardization". For example, there are multiple ways of implementing perl objects, if you just pick one you'll probably get it to work well enough for you. But if you use someone else's modules, there's no way to know in advance what kind of objects they're using -- you've got to inspect the code before you can even think about sub-classing it.)
Perhaps it's time for a standards body that won't take money or volunteers from corporations.
"We are Microsoft. You shall be assimilated. Competition is futile."
Well, yes, it really is true. And further, plug-ins are apparently a severe pain to implement in a cross-platform way -- I use AMD64 boxes myself, and there's still no native flash plug-in, for example. And if firefox extensions are any guide, we can also look forward to plug-ins breaking when you do browser upgrades.
Further, the entire premise (what the web needs is more languages!) is fundamentally flawed, because it obsesses about the technical characteristics of languages, and ignores the social aspects -- as you get more languages in play, you sub-divide the community of developers and complicate the sharing of techniques and so on.
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.
If the tool doesn't allow you to meet your requirements, then you should change the tool.
What's so wrong about trying to capitalize on the webapps advantages ?
If our expectations reveal that HTML is no longer adequate, then let's make it evolve or create something else.
Or maybe let's keep everything as it is and see webapp development become even more of a pain than it already is.
I for one can't take it anymore, this endless tweaking of HTML and CSS to get a site to work on the major browsers (and i'm not even talking about js).
I am now a happy flex developer.
There's a team of developers who've been able to build the Cocoa frameworks for JavaScript - MVC if you will. 280 Degrees
Java and C#? When I started writing web apps, we had C and the CGI spec. Your new-fangled languages don't bring anything new to the table, they're just marketing buzzwords!
Everyone who continuously complains about the inadequacy of the web browser needs to step back, and remember that it is designed to be crippled. If it were as fully functional as the desktop, any yahoo could come by and completely replace your desktop with something of their choosing. I don't need DHTML to watch movies and read the news. I need Firefox and some interlinked markup. Anything more than that is opening up the web to all sorts of attacks that don't need to happen. We don't need a better JavaScript. It would be nice for programmers, but less secure for users.
I don't think he meant "you" personally, but was referring to the large number of people who don't understand how to use JavaScript properly.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Uh huh.
It really should be WebDev 101:
Rules 1 & 2: Don't trust the client!
Me lost me cookie at the disco.
I don't think the author really understands what TBL's original vision was, except in the narrowest of contexts. The idea of code on demand was certainly described as part of REST.
The problem with JavaScript standardization arguably comes down to vendor politics (as do most standards efforts). We're in a wave of proprietary "innovations" being pushed, like MS Silverlight, Adobe AIR, Sun JavaFX, etc. It's not in these gorilla's interests to commoditize a richer browser experience before they try to take over a portion of the web on their own.
-Stu
So what this gentleman is proposing is that we scrap client-side functionality and go back to dumb terminals?
1. Connection-oriented protocols can be implemented in lower-level, connectionless protocols using a session id. HTTP/1.1 keeps its connection alive, which mitigates the overhead in establishing new connections.
2. Don't quite understand what you have in mind here.
3. XMLHTTPRequest can send text or binary data, despite its name.
4. We are talking about ~1 kB of code, to be loaded once per website.
Except it, you know, exists. And it works on my PC.
Help poke pirates in the eyepatch, arr.
> If the tool doesn't allow you to meet your requirements, then you should change the tool.
If you want to invent a new internet protocol that lets the remote server take over your desktop, feel free to do so. The reason you run into so much backlash is that you want to ram *YOUR* singing/dancing Web2.0 "goodness" down the throats of people who merely want a lightweight browser that browses the web. Ever heard the joke about how an elephant is actually a mouse designed by a committee? That's the problem we're running into now. The same applies to assholes who want to turn email clients into singing/dancing Web2.0 "rich media experiences".
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
That is a good point, but I feel it's just too many layers; you're being very inefficient.
On IP (connectionless) you add TCP (adds a persistent connection), then you add HTTP (takes that persistence away), then you add session state (adds persistent connection again). You solve the same problem if you take HTTP away, but with about 1/10th of the bandwidth (and that's a conservative approximation).
Err, maybe you're forgetting that XMLHttpRequest was originally created by Microsoft as part of MSXML. It was then copied by Mozilla and everyone else.
Opinions differ on that last topic. There are perfectly good scripting languages Netscape could have chosen to embedd which are both standard and considerably more suitable for non-trivial use.
It is water under the bridge now at any rate, we have js and we'll just have to live with it.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
HTTP is connectionless, but many applications don't make sense in a connectionless setting
Which ones? Connectionless != stateless. See: REpresentational State Transfer
Client side privileges are difficult to control, and relying solely on the server for security is not always possible
Why? This seems like a pretty sweeping generalization. What kind of use cases are you referring to? Whether you're writing the client side in javascript or gtk or some winforms control, it's *never* a good idea to rely on the security of the client. See: DRM
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.
Perhaps you're unaware of this, but those verbose tags can be gzipped into an incredibly tight binary. And unlike most everything else, it's even a (well supported) standard. As for javascript and css, it's trivial to minify or pack and then compress for deployment. As part of a tool chain, devs get all this for free (unlike someone hacking together their own binary wire format).
As for your assertion that most requests are ultimately very similar to RPC, you are correct. However, you are certainly not the first to notice this: see JSON-RPC (I would have mentioned XML-RPC but JSON even disposes of those pesky tags you so disapprove of).
XMLHTTPRequest is not standardized across all browsers, and multiple copies of some sections of code must be sent, wasting even more bandwidth.
And the code to abstract away XHR differences is trivial, a few dozen lines at most. Standard in a decent dev's toolchain -- see: minification and gzip compression.
So by all means, keep adding to the list. But from where I stand I don't see any real architectural downsides to web apps listed (not that they don't exist).
Yeah, damn Microsoft always dicking everything up. I mean look how they always want to add proprietary extensions to everything like JavaScript. I remember when they added this one proprietary extension to JavaScript called... hmmm... what was it, oh yeah XMLHTTPREQUEST!
How many of these fucking clown shoes JavaScript developers dog Microsoft for "blocking" the JavaScript process, when JavaScript would have died as it should have years ago if not for that little idea that let you dumbasses stuff way too much client side logic into your web applications.
The sooner we realize that client side web application programming is going to only serve to create heavier and heavier web applications and turn the web into even more of a gaping anus of security vulnerabilities, the sooner we can get down to restoring the browser as a client side view of server-side web applications.
Standardizing on JavaScript was a mistake. But it wasn't as stupid as standardizing on the alternative.
[signature]