Stop Standardizing HTML 302
pfignaux writes with an interesting view on the place of centralized standardization in modern browsers. From the article: "When HTML first appeared, it offered a coherent if limited vocabulary for sharing content on the newly created World Wide Web. Today, after HTML has handed off most of its actual work to other specifications, it's time to stop worrying about this central core and let developers choose their own markup vocabularies and processing."
Instead, the author proposes that CSS, Javascript+DOM, the W3C's accessibility framework, and Web Components are sufficient to implement the rendering of smaller, domain-specific markups.
Nope (Score:5, Informative)
Re: Nope (Score:5, Funny)
Re: (Score:2)
If I had mod points, you would get one!
Re: Nope (Score:5, Funny)
A flu? Have they been updating the moderation capabilities again?
Re: (Score:2)
I can't help but wonder how much he was paid for his, "insight?"
Re: (Score:2)
I've had the flu before, but you may be happy that I'm telling XML people similar things: put down the schemas...
Re: (Score:3)
"His books include XML: A Primer, XML Elements of Style, Cookies, Office 2003 XML, and the XML Pocket Reference."
Re: Nope (Score:4, Funny)
"His books include XML: A Primer, XML Elements of Style, Cookies, Office 2003 XML, and the XML Pocket Reference."
This is what people who never encounter S-expressions early in their life end up doing. :-( Parenthetical vaccination would prevent him from developing a cancer of the angled brackets.
Re: Nope (Score:4, Funny)
He seemed to me like a proponent of XML. I hope he catches the flu.
X7ML9?
absolutely (Score:3)
Re:Nope (Score:5, Informative)
close enough standards compliance?
please. Microsoft tries to break standards by introducing their own. Don't blame HTML for that.
Comment removed (Score:4, Interesting)
Re: (Score:2)
As it's in Google and Opera's interest to have an open web, I'd have a closer look at people using the un-forked WebKit as being more likely to not play nice. I'm really hoping everyone keeps working together though. The 'defacto standard' approach seems to be working relatively well so far.
Re: (Score:3)
language (Score:5, Insightful)
Re: (Score:2)
well yeah, but standardizing html was always a fantasy.
like, they're playing catch up with the standardizing anyways and arguably it has been proven that browser manufacturers do what the hell(what a product they have in the pipeline depends on!) they want anyways - including google and apple.
Re: (Score:3)
Standards don't lead, development does. However, standards provide guides for how that development is carried through, resulting in greater adoption of them by new developers and a common goal among competing or conflicting interests.
A dictionary is never at the forefront of development, but is it fair to say dictionaries are useless?
Re:language (Score:5, Funny)
You're overstating the meerfage of sharing a common briogib. As long as the sufrabork is cognatious, the central mordage doesn't need to be the same.
Yes, by all means! (Score:5, Funny)
Stop making our job skills transferable!
HTML isn't anymore (Score:2, Interesting)
What was once a standard for rendering text and images together in a single document has suffered from severe scope creep over the years. With the addition of multimedia, HTML crossed the line from static to active content markup, which in my opinion defeated its original purpose. HTML needs an active companion language, an actual programming language, one that will replace the disparate third-party technologies in use today. Just eliminating Flash and Javascript for example would eliminate a vast majority
Re:HTML isn't anymore (Score:5, Funny)
HTML needs an active companion language, an actual programming language, one that will replace the disparate third-party technologies in use today. Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.
I agree!
I shall call this new language "Jscript"!
-Bill
Re:HTML isn't anymore (Score:4, Funny)
That's never gonna win against the implementation of COBOL* that I am about to release shortly.
*CuteObjectBasedOnlineLolcode
Re:HTML isn't anymore (Score:5, Interesting)
You ask for a companion programming language and at the same time propose eliminating Javascript. I see a contradiction in there.
Re: (Score:3)
You ask for a companion programming language and at the same time propose eliminating Javascript. I see a contradiction in there.
As someone who uses JavaScript daily, I see no contradiction. Perhaps you've confused it with an programming language?
Re:HTML isn't anymore (Score:5, Funny)
Ok, I'll take the bait. How in the hell is JavaScript *not* a programming language?
1. It is a language
2. I write programs with it
Re: (Score:3, Insightful)
Ok, I'll take the bait. How in the hell is JavaScript *not* a programming language?
1. It is a language 2. I write programs with it
There isn't enough snarky elitism associated with it yet for it to be a "real" programming language. As soon as you can get to the state of natural obfuscation that Perl enjoys, you'll see an uptake with the true nerds.
Re:HTML isn't anymore (Score:5, Funny)
OK, honest question about JavaScript, since I don't know it. Does JavaScript enclose blocks of code in curly-braces?
As we all know, curly braces are the One True Distinction between real profession programming languages and toy scripting languages. For example, everyone knows C# is a real profession programming language, but Visual Basic is a toy scripting language, despite offering nearly-identical functionality on top of the CLR. However, C# clearly encloses blocks of test in curly braces, and Visual Basic laughably doesn't, toy that it is!
So, let's settle this JavaScript debate once and for all: on which side of the curly braces line does it lie?
Difference between scripts and programs (Score:5, Insightful)
Then let's define computer program (Score:2)
A computer program is defined [in the U.S. copyright statute] as "a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result"
The problem is that the definition you quoted is too broad.
Tell that to Congress. In any case, I'm willing to work with any other reasonable definition of "computer program" that you can cite.
I am typing these words (statements) and will then click some buttons in order to cause a post to appear on this topic (bringing about certain result).
Ow. Mind screw. By your interpretation of the copyright definition, any HOWTO for an app or walkthrough of a video game is itself a computer program.
Re: (Score:2)
Are you going to take the "Java" part of "JavaScript" literal too?
Why aren't you complaining about "Python" being too snakey?
Re: (Score:2)
Re: (Score:2)
, and Javascript is essentially in the same boat as other interpreted languages, or in my opinion
These days, other interpreted languages includes machine code and C++.
Re: (Score:2)
I agree, one could argue that of it requires a separate program to run it, rather than being compiled to a program, it could be called something else. Though personally, I believe that of It's Turing complete it is a programming language. The language remains the same whether compiled or interpreted, so I'd think that's a silly distinction to classify a language (additionally, a language can have a compiler or interpreter built, or even exist without either (though it wouldn't be so useful in the last case).
Indeed. If "requiring a separate program to run it" was the qualifier for exclusion, the only thing a programming language could write is operating systems...
Re: (Score:2)
These days even compiled and assembled languages actually run within a run-time environment (and actually is run on a virtual machine that is interpreted in firmware by the CPU and its friends), making the distinction even less clear or useful. It's been a long while but IIRC, just running "Hello World" in C brings in a dozen or two libraries and the running program will likely be 100K+. And I once worked on a FORTRAN system where the same code could be run using an 'Incremental Interactive Compiler' - ef
Re: (Score:2)
Re: (Score:2)
Yes. Javascript is Turing Complete.
Re: (Score:3, Interesting)
So is lambda calculus. There's more than a passing simularity there, too.
Re: (Score:3)
Re: (Score:3, Insightful)
There is no language in which amateurs should be writing code that runs on client's machines.
Re: (Score:3)
Re: (Score:2)
Re:HTML isn't anymore (Score:5, Insightful)
Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.
If you know of a language that will do what Flash and Javascript will do with no headaches, please share it with us.
Re: (Score:2)
If by operating system, you mean one that loads from a remote location then look up PXE
If by operating system, you mean desktop environment, look up anything ranging from RDP and VNC to Chrome OS to eyeOS, Cloudo, Glide or tons of others.
Re:HTML isn't anymore (Score:5, Insightful)
We are so close to a Web-based operating system I can taste it.
One of the things I like to say is, "In the long run, all file formats become programming languages". When somebody says they need a simple format for a config file or something, inevitably scope creep causes them to ask for something like a conditional (can you have a config setup so that if we're running offline it does this; but if the network is available it does that?). For the developer of the file format, *any* file format, it's a good idea to have a language developer's perspective.
Now, once you look at programming languages you start to get drawn into operating systems. C was developed in conjunction with Unix. Forth tends to become an operating system. Lisp, although it runs in userspace is used as a shell via Emacs and some have compared that to an OS. They talked about building Java chips at one point, and a Java OS certainly would have been written to go with it--it's only natural.
Thus I feel compelled to revise my little one-liner. "In the long run, all file formats become operating systems".
The next time the boss says he needs a flat-text config file, think about what kind of scheduling algorithm you want to use.
Re: (Score:2)
The next time the boss says he needs a flat-text config file, think about what kind of scheduling algorithm you want to use.
That's hilarious.
Re: (Score:2)
Unless you count Java Card based devices, which are pretty widespread. But yeah, why make hardware that does less than the least common denominator of practically every viable microprocessor ever designed?
Re:HTML isn't anymore (Score:4, Insightful)
Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.
HTML needs an active companion language, an actual programming language
The big problems inherent to Flash and Javascript are not that they don't work. It's that both involve letting arbitrary code run on your computer and their security isn't perfect.
Replacing them with a new programming language that will run arbitrary programs on your computer is not going to solve that because a new language isn't going to have perfect security either.
With a new, active language, you'd still get annoying ads, drive-by malware downloads, pages that load a several megabytes of crappy code to display three lines of text and all of the other problems that make people hate Flash and Javascript.
Re: (Score:2)
Replacing them with a new programming language that will run arbitrary programs on your computer is not going to solve that because a new language isn't going to have perfect security either.
Why people seem to think security is something that can never be perfected is beyond me. Just because people fail at it regularly, does not mean it actually is impossible.
Re: (Score:2)
Replacing them with a new programming language that will run arbitrary programs on your computer is not going to solve that because a new language isn't going to have perfect security either.
Why people seem to think security is something that can never be perfected is beyond me. Just because people fail at it regularly, does not mean it actually is impossible.
No, Goedel's Incompleteness Theorem [wikipedia.org] means it actually is impossible.
Or, to put it another way, imagine two trees in a space of all possible 'statements' (programs) in any useful language. One covers all provably false/wrong statements, the other covers all provably true/correct statements. Not only will there be spaces not covered by either tree, there will be spaces covered by both trees.
Re: (Score:2)
We are so close to a Web-based operating system I can taste it.
Technically, we're there [bellard.org]. Runs on the iPhone, too, so if you ever dreamed of running Linux on your iPhone, there's your chance.
Re: (Score:2)
Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.
CSS3 allows to do some animation effects that are currently done in Javascript, but that's probably the best you will ever get. I don't think we will ever get completely get rid of Javascript, it has just become to integral to what people do on the web these days.
But it's not just the web developers that are to be blamed for this. Browser developers have done extremely little to actually derive benefit from the HTML markup. Stuff like Readability should have been a standard part of all browsers years ago, y
Re: (Score:2)
Once a standard, now a crowd of sub-standards (Score:2)
What was once a standard[...]
Mod parent up.
Yes, IMO it's realistic right to talk of the 'standard' in the past tense. Now many web-pages seem to have been affected by a 'tower of Babel' syndrome, with everyone asking their visitors to use their favorite subsidiary language upgrade -- but each new 'sub-standard' seems to have its undocumented variants.
-wb-
what are you even saying? (Score:5, Insightful)
Re:what are you even saying? (Score:5, Insightful)
Yep, the author doesn't truly understand WHY HTML works and that's because it's interpreted by the browser a certain way. There already exist a plethora of differences between IE and firefox/chrome, de-standardizing HTML would make it impossible to create websites that look consistent to all users.
Re: (Score:2)
The author doesn't seem to be a credible source of information for standards and compliance. Judging form his resume, he seems to just be a web developer by trial through fire. More of a technical writer if anything.
http://www.simonstl.com/resume.htm [simonstl.com]
Fix it.... (Score:3)
Just like the good ol' MSIE days! (Score:5, Insightful)
This post optimized for viewing with with MSIE 9.3.
People have short memories it seems. (Score:3)
Netscape navigator introduced the notorious BLINK tag and things like frames, back in the early days it pretty much was a free for all.
Re: (Score:2)
Yes, but as annoying as that was, at least a human being could still read the code.
Re: (Score:2)
The only problem with the blink tag is that it was ugly. Too be fair, you really don't need a blink tag to create ugly websites and blinking effects are just one of many, many different ways to make websites ugly.
Re: (Score:2)
But the good new is that, even if they do obsolete the BLINK tag, we can replicate it with a Javascript timer with little trouble. Hell, with the new CSS3 control of alpha, you can make it throb! That can be really annoying! BLINK forever!!!
Please standardize more (Score:5, Insightful)
The web worked when it had a simple standard that worked in every situation.
We've put layers on top of that, and now it's chaos. A bloated, irregular, often incomprehensible chaos designed to allow people to make custom interfaces out of the web.
The whole point of the web, versus having an application for every specific task (like we did on desktops before the 1990s, and like we now do on smartphones), was to have a standard and simplified interface.
The web grew and thrived under that goal. It's become more corporate, nuanced, isolated, sealed-off, etc. under our "new" way.
Re: (Score:2)
like we did on desktops before the 1990s, and like we now do on smartphones
I get your point, but the above quote contradicts it. We've gone 'back' to the stovepipes of the pre 90s with phones and apps. I'd say it's a reasonable question to ask if technology has made stovepipe systems palatable and/or feasible now.
Or putting it another way, see Apple's superbowl commercial...sometimes having differences is a good thing. Of course sometimes its not, but knowing the difference is tough to deduce sometimes.
Re: (Score:2)
Not so much that as there's new ways to do things, you can still make a plain html / css / jscript site just fine, it's just that jQuery may solve a lot of jscript headaches for you & a server side language can allow you to data mine, as well as google who can keep track of your traffic.
Those layers have made the web a lot more capable to the point where you can administrate an enterprise network through a browser.
Why would you want to do that? Well, nobody wants to be attached to their work computer a
Re: (Score:2)
The 'web' works as well as ever.
HTML afterall was written back when they just wanted to show people documents. It 'hardly' worked in every situation. It worked in the very limited case of presenting a documenting.
Then people wanted to do more with these documents and we end up with what we have now.
It's really not unlike the various attempts to make word processors interactive.
The author's point that many have chosen to ignore is that the actual 'markup' part of HTML is pretty much good enough. I think he i
Re: (Score:2)
sorry... the google web component part appears to have been consumed by slashdot comment.
It looks something like this:
Extending the DOM; WAI-ARIA in search engines (Score:4, Interesting)
"Instead, the author proposes that CSS, Javascript+DOM, the W3C's accessibility framework, and Web Components are sufficient to implement the rendering of smaller, domain-specific markups."
In other words, implement everything new as polyfills [wikipedia.org]. But how would one have implemented new HTML5 features, such as the 2D Canvas, WebGL, and the video tag as polyfills? Even if one doesn't standardize new extensions to HTML markup, one still needs to standardize new extensions to the DOM. In addition, no new elements means that user agents that do not process script or WAI-ARIA, such as robots used by search engines, won't be able to make sense of pages. Do any current web search engines process WAI-ARIA?
Re:Extending the DOM; WAI-ARIA in search engines (Score:5, Interesting)
The author's proposal sounds suspiciously like he has fallen for the seductive path of elegant generalizations(that are too theoretical for the ugly details to yet be visible) instead of confronting the ugly details that our current attempt at standardization has made visible...
To be sure, the sausage-by-comittee that tends to result when you try to standardize something is quite ugly and takes ages to settle down; but if the proposal is "Just let people use whatever shims they want for everything" you haven't really solved the problem, just comitted yourself to standardizing a suitably powerful interface for the shims to sit on, along with giant piles of shim-dependent code that crawlers and any other applications that break the shims' assumptions won't be able to make the slightest sense of.
Heck, for maximum elegance in the core standards, we could just replace virtually everything with the "Object" tag, and let people embed whatever they want, or abandon this 'HTML' nonsense entirely and just make Native Client [google.com] the standard, freeing developers to implement pretty much any conceivable structure, from a legacy browser engine, to a Flash client, to a TECO interpreter built entirely out of Minecraft redstone logic, as the shim for their 'site'. A glorious age of unfettered freedom!
Re:Extending the DOM; WAI-ARIA in search engines (Score:5, Funny)
But how would one have implemented new HTML5 features, such as the 2D Canvas,
Simple. Each pixel is a separate div.
WebGL,
Lots and lots of divs. Lots of divs.
Re: (Score:2)
Hey, an X-by-Y 'table' object populated entirely with 1-pixel images is just waiting to be turned into a javascript-controlled framebuffer!
DOM for new input devices (Score:2)
Standardize! (Score:5, Insightful)
Re: (Score:2)
The only cool thing about the web is the delivery model.
CSS, HTML and Javascript should be optional components you *can* use to build web apps, not "the one way" because they're horrifically shitty for anything but simple use cases.
If the web was more bare bones, it would be a much richer, faster, better, diverse place... as long as the security model works. Something like Google's Nacl would be much better than web sites as we know them.
But isn't it part of the beauty of the web delivery model that it works across different devices and OS's without having to target them separately/distribute a new runtime environment (repeating Java/Flash..)? Good luck getting Nacl onto iOS devices fx.
Native apps that just use the internet for communication really isn't new at all, have been quite common all along (I'm fx running streaming Spotify in the background here), but isn't the web.
There is a great quote from a former coworker of mine.
Anal works on both genders too, that doesn't make it great, or even less shitty, or that working on all genders in the same way is something you should strive for just because you can.
This rule should have a number: (Score:3)
If in doubt, add one more complexity layer.
No, Instead kill the Multimedia extension (Score:2)
Ever since Multimedia was added to HTML the spec has gone to shit:
-What codec to choose
-Patents
-And now DRM
Not of these are compatible with the idea to allow compatibility between all sites and all browsers
Re: (Score:2)
The codec/patent issues aren't from HTML. HTML itsself is content neutral. Things like this have happened before - most noteably the GIF format was patent-encumbered for many years, and the PNG format many proposed as an alternative was not fully supported by Microsoft*.
We're just repeating the same issues now that we already went through with image standards: HTML doesn't specify a media format, and there are no media formats that everyone can support. The open source side cannot support formats encumbered
Re: (Score:2)
Random idiot makes inflamatory remark (Score:2)
News at 11.
Thank you, /., for thinking this matters.
It's he retired from lack of oxygen? (Score:2)
Everyone ought to see TFA and look at this fedora-wearing douche opining on subjects in which he clearly has no practical knowledge.
As if browsers need to be an even more disarrayed kludge than they already are? Yeah, 5 or more browsers and rendering engines that all have their own unique languages and markups, great idea!
Seriously, no. Just no.
Re:Is he retired from lack of oxygen? (Score:2)
Yes! (Score:3)
I like it. Let's just find a good name... lets see.. we can mark up everything now... so I guess we keep the "ML" part. And content authors can create new and unknown tags, the traditional symbol for unknown is X.. I know, lets call it XML!
HTML5 is a design by committee failure (Score:5, Interesting)
"Pave the cowpaths" is an excuse to appease a bunch of zealots that are hellbent on pushing their personal preferences and egos into a standard rather than designing something that is quick/easy to parse and universally render across platforms. It's only going to get worse as the standard is never completed over the next decade.
XML serialization of HTML sucks. It's verbose, and it's ugly. But it's effective because it's well defined and it leaves very little room for interpretation.
Honestly, I'd like to see two standards. One, is XHTML5 Strict that follows the XML serialization. This will be left to the big boys who have real work to do. The other standard would be an extension to MarkDown to allow CSS customization with classes and ids. This would allow the path the cowpaths crowd to get things down as fast as possible and keep the verbosity of XML out of their way.
We need better web tech PERIOD. (Score:2)
I find it rather abhorrent that the "Web Development" has become a mish-mash of technologies: HTTP, HTML, JS, CSS and extensions: DOM, AJAX.
As a software developer this is a nightmare scenario. When we program computers, we should be programming for the web or directly on the client in a unified way that hides the intricacies of the base technologies from the developer. Imagine writing a program not knowing where it was going to run? Because you just wrote what it should do, and some compiler took care of m
Re: (Score:2)
I find it rather abhorrent that the "Web Development" has become a mish-mash of technologies: HTTP, HTML, JS, CSS and extensions: DOM, AJAX.
Has become? Back in the day HTML was a mish-mash of tags and (eventually) DOM models that were abhorrent and incompatible across browsers.
As soon as you standardize one thing, then the big boys are on to the next big thing. You still have a myriad ways to generate web content, all of which should shield the developer from most of the madness. Standards are good for taking a snapshot of the state of the art at a point in time, allowing developers to say "I support this version" and browsers to guarantee
Over engineering in Slashdot too (Score:2)
First, we'll stop using tags and titles, it's a clear case of over categorizing
Then, let's stop using english as a standard. Letters were meant to be used freely, not rigidly as used in english.
Finally, we should remove links in stories, so that people can freely search these in the web.
Web? Not anymore (Score:2)
I notice that these days the pendulum is swinging again. Away from thin clients that just render what the software sent them. Towards thick clients running on the user's PC that handle the bulk of the processing, talking to a remote server to get the data and then using that data in a local program. The programs are written in different languages, Javascript instead of C/C++, and the data's XML rather than the various formats of a couple decades ago, but we're swinging back to the PC running the programs in
How about you just make your browser (Score:2)
Stop Standardizing HTML Badly (Score:4, Interesting)
HTML5 is riddled with faulty logic, flawed reasoning, and bad semantics. Even reading the spec gives the impression that the writing is of lesser quality than pervious versions. Why this is the case after 9 years completely baffles me.
Selected points:
Last but not least: enough with the XML hatred. XHTML5, with proper XML syntax, should be the focus instead of an afterthought. XML syntax compliance isn't that hard or time consuming. Markup languages are for machine consumption, not human readability. Not requiring tags to be closed, bare unary attributes (ie, checked instead of checked="checked") and all the other shortcuts are asinine and only foster laziness and sloppiness... which would not be tolerated in any compiled or interpreted language.
Stop trying to make everything XML gratuitously (Score:3)
Markup languages are for both, that's what distinguishes markup languages from, say, binary data formats. And HTML5 has parsing rules that are just as unambiguous for machine reading as XMLs, defined in the standard, and don't need the verbosity of XML to ach
Stop: I need to sell more JS/CSS O'Reilly Books! (Score:2)
subject (Score:3)
That's too verbose for him though, so he wants to be able to write this:
You'll notice that all this does is push the HTML spec into the CSS spec. I don't see much of an advantage to that. And it makes it impossible to get even a basic understanding of HTML document structure without constantly referring back to the CSS.
He also wants all new features that would previously have been implemented by adding tags to the HTML specification to be implemented by way of shims (polyfills). But who standardizes the behavior of shimmed constructs? Well, nobody. People just pick the shims they like. And because the shims are JS + CSS, the W3C is in charge of making sure the browsers execute them properly. Kind of like how today the W3C is in charge of making sure browsers execute HTML properly.
I think this guy might be happy if we got rid of every tag except <canvas> and all reusable components (e.g. <button>) came from third party vendors. E.g. <include src="http://html6.google.com/button.polyfill">. Oh boy I can't wait.
Re: (Score:3)
This isn't some huge problem that hasn't been resolved. Whitelist the sites that actually need it and leave Javascript disabled for all other sites. It's not difficult and it takes only a few moments to do it and reload a site when you need it.
Of course that would require a few minutes of work on your part and you seem to be too busy whining to do it.
Re: (Score:2)
Search engine support for JavaScript (Score:2)
Then enable Javascript then
Which web search engine supports indexing text added to the DOM by JavaScript? Otherwise, any web site that relies on JavaScript for basic functionality isn't going to get indexed well.
Re: (Score:2)
If someone is hiding their content behind JavaScript walls, they don't deserve to have it indexed.
--Jeremy
Until user agents (Score:2)
Re: (Score:2)
Unfortunately, my bank's, broker's, credit union's etc ... websites are unusable without it
Then use NoScript and temporarily allow those sites when you need to use them. Or just permanently whitelist them since your are screwed anyway if your banking sites have been compromised with malware.
To be fair... (Score:4, Insightful)
His point was about web content being more dynamic than he thinks is required. A fair point, nowadays a straightforward web form with very limited scope is frowned upon if it neglects to do some sort of javascript trickery or another. He isn't after *more* capability, he seeks a more constrained experience and to have more developers exhibit a shred of restraint rather than mandate moderately more open ended access to the client facilities for superfluous bells and whistles. If a browser hangs up nowadays, it's almost certainly due to badly written javascript or javascript implementation gone insane in the face of valid javascript. Simplistic content doesn't choke up browsers and in a lot of cases, that simplicistic content model *could* suffice for the purpose. There are cases where javascript can enrich the experience beyond what is reasonable without it, but web developers immediately jump to the deep end without a second thought today.
Now, in terms of 'powerful and flexible', I'd argue that inherently it cannot hold that crown precisely because javascript is restricted from doing things like opening arbitrary filehandles and such. This isn't a bad thing, but it means the claim of 'most powerful' is flawed. Javascript is a popular language not due to having 'the' best set of capabilities or the best syntax (everyone bundles some sort of 'library' precisely to bandaid over javascripts failing at the low level), it's popular by virtue of being ubiquitous.
Oh god (Score:3)
Yeah, and if people just used the amount of car they need to get from A to B, polution would plummet and fuel prices would go down and the roads wouldn't need so much maintenance. You FIRST!
The original web was designed as a gigantic book where instead of footnotes, you could click on a reference and read it from there. Everything else is fluff but it is that fluff that made the web. Want to see the original web, just browse wikipedia. It is very useful, even essential perhaps BUT it is not all of the web.