Slashdot Mirror
HTML Web App Development Still Has a Ways To Go
GMGruman writes "Neil McAllister was helping out a friend whose web developer disappeared. Neil's journey into his friend's website ended up being an archaeological dig through unstable remains, as layers of code in different languages easily broke when touched. Neil realized in that experience that the ever-growing jumble of standards, frameworks, and tools makes web application development harder than it needs to be. Although the Web is all about open standards where anyone can create variations for their specific needs and wants, Neil's experience reminded him that a tightly controlled ecosystem backed by a major vendor does make it easier to define best practices, set development targets, and deliver results with a minimum of chaos. There's something to be said for that."
Knowing how to code is easy. Being a decent software engineer isn't. 90+% of web developers fall into the first category.
"Neil McAllister was helping out a friend whose Web developer disappeared."
What? Can you DOS people now?
It is an ever-growing jumble of different libraries, standards and tools.
The problem with web app development is that the environment was never intended for interactivity, it was designed for displaying information. Everything added since then to create 'apps' has been bolted on (sometimes cleverly, sometimes not so cleverly) and implemented differently between browsers and (relating to plugins/extensions) differently between operating systems. Developing for x86 machines running Windows and/or Linux isn't a "tightly controlled ecosystem" but you can certainly develop excellent applications, why? Because the environment was intended to run applications.
Loading...
The problem in his example is with the serverside code not html.
And if you want to, it it simply to choose just a single vendors framework and use only that.
I can agree with all of this except the "backed by a major vendor" part, which seems superfluous... Design is all about maintaining a coherent vision of the end product, whereas hammering a tin shed on the side of the Taj Mahal is always a bad idea, particularly for maintainability and robustness. What isn't clear to me is why I need a vendor to supply my vision when I've already had years of education and experience...
It is an ever-growing jumble of different publishers, style manuals, and editions.
Even for excellent software developers, web development is difficult. It's not the concepts that are difficult, per se, but rather the jumble of half-backed hacks that make up ever layer of the web stack. The foundation is so weak that anything built upon it just can't stand well, even if it itself is well-designed (given the constraints of web development).
Just look at the common open source technologies used by many web sites. MySQL is one buggy hack upon another. PHP is much the same, plus some security holes.
HTTP has been over-extended well beyond its original use (cookies are a hack to get around its statelessness, it's caching mechanisms are fucked to high heaven, SSL and TLS are hacks).
JavaScript is perhaps the most horrid hack of them all. Something meant for adding minor interactivity to a page has been misconstrued as being suitable for large-scale application development, although it lacks many of the most basic features necessary to do that sort of development effectively.
It's difficult enough to fight with unclear and conflicting requirements alone. Toss in shitty technology, and it becomes very difficult even for the best seasoned professionals to develop even just mediocre software systems.
The ultimate glue language. It's not pretty as python but it's a woodchipper when it comes to parsing and re-gluing outputs. Indeed that's what the acronym P.E.R.L strands for. My favorite reason to use perl is that you can do more things more easily with the core language. You don't have to depend upon importing libs. The surprise is that it's also not bloated at the core level: compare the thickness of the perl pocket ref to any other language. it's tiny.
The suggestion that "Web application development [is]harder than it needs to be" is a false premise. It is because of this assumption that many developers choose the web application framework du jour, and then move on when something 'easier' comes along.
In 6 years we haven't had to change our procedural plpgsql backends to our web apps. Changing from PHP smarty templates to Django templates is relatively hard.
HTTP needs a replacement for application development. It was designed for document retrieval not applications. For the past 15 years all these frameworks have been a hack to get over the limits of HTTP as a protocol used in application development. AJAX is the latest hack to overcome limits in this aging protocol.
Way to troll. It's so sad that every one of your points is fairly well wrong and could earn you a post nearly as long in refute for each. If you read that post and thought it was insightful, you've been trolled.
Goodbye.
2^3 * 31 * 647
Neil's experience reminded him that a tightly controlled ecosystem backed by a major vendor does make it easier to define best practices, set development targets, and deliver results with a minimum of chaos. There's something to be said for that.
So if that's the best ecosystem to work in... and Visual Studio is one of the best IDEs out there... we should all be .NET programmers?
Which features are missing, exactly? Cappuccino, for example, implements almost exactly the same APIs and conventions that native Mac/iPhone developers use, only in Javascript.
The serverside part of creating web applications is actually the easy part. It is indeed as you say: just pick a platform and a framework and use that. In most cases you have full control over the server side part of your web application, so you create it just the way you like it. The hard part is creating a good looking and well functioning interface for your clients using HTML, CSS and Javascript which will deliver (somewhat) the same experience, whatever the clients software, hardware or screen size may be. It's hard exactly because you don't know what the client will be using to access your application, as you have no control over this whatsoever.
Pretty good is actually pretty bad.
If it was 'never intended for interactivity', why are POST and DELETE part of the spec? They are designed for interactivity.
If you want to get picky, 'computer' were 'never designed' for media playback, using your criteria. (That criteria being that only the initial thought counts, and not the years and years of changes afterwards.)
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
I have built web applications that attempt to mimic already established GUI applications. One of the biggest problems I face is trying to recreate the GUI experience with widgets that are not available. Take for instance a true combo-box. This is a widget that looks like a dropdown, but allows the user to type in the text field as well. In trying to recreate a simple widget that is available in GUI toolkits, I have to mix javascript with a traditional select input field along with changes to the css and div tags. It is a lot of code to perform a basic GUI functionality. If we are moving toward a world of web apps, then the html standard needs to provide GUI-like widgets. Displaying video natively is great, but I want all the different selectors, calendar widgets, etc. to be standard. Otherwise it is still a lot of code to perform smoke and mirror tricks to look like an application.
Flexible bare-metal recovery for Linux/UNIX
Is not "ways" a plural? Can article "a" be used in front of it? Ever?..
Could a native English-speaker kindly explain it to this Ukrainian immigrant?
In Soviet Washington the swamp drains you.
Has the 'too many frameworks' argument every held water? 'Too much choice' is not a problem, especially for a seasoned developer.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
The problem is not the tools (well, not *always* the tools), but the developers. You can provide the best development tools in existence to an incompetent developer, and you will end up with a crap website. It has nothing to do with the quality of the tools or the maturity of the application frameworks.
Hell, humans have been building houses for 1000s of years, yet an incompetent builder can still build a house that will fall apart. I don't think the problem is that the hammer and saw still have a ways to go.
Life is like a web application. Sometime you need cookies just to get by.
I honestly don't understand how an anecdote about a seriously fucked server setup is relevant in the slightest to the pros or cons of "HTML web apps" or their development.
With HTML, whether the shiniest of web 2.0 or the seriously old-school stuff, there is clear separation between the client(where "standards" such as they are, matter) and the server, which can do absolutely whatever it likes, so long as it responds correctly to a few HTTP messages.
If you want to deliver a webapp, the development of your client component is, indeed, somewhat constrained by the fact that "web standards" are more evolved than designed, and are somewhat inconsistently implemented. If you want to discuss the cons of web-apps, horror stories in this vein are the anecdote to use. If you want to discuss the pros, heroic tales of multiplatform, install-free deployment are to be used.
On the server side, though, the vices and virtues of web standards(aside from seriously uncontroversial stuff like TCP/IP and HTTP GET) are basically irrelevant. It's your server. You can do whatever you want to deliver HTML, CSS, and javascript, and interpret responses from your clients. Totally in-house stack? If you feel like it. Modestly customized OSS job? Sure. Some single-vendor enterprise development solution? If that is how you roll. The fact that somebody's web-dev fucked up and then disappeared just seems completely irrelevant(can you think of any type of development, application or otherwise, where "the developer fucked up, then disappeared, and we had to call somebody else in to do a mixture of archeology and pacification" has ever been a good thing?)
Ruby on Rails
Perl is for coders, not web designers. As the former, I can pull together and correlate data from all over the place. The only problem is my output is ugly as hell. Since I don't do commercial work viewed by the general public that isn't a problem but it would be nice. Whenever I right click and look at the source for a fairly complicated webpage I get depressed. Seems way, way too complex and you are not seeing everything being brought in via CSS and JS libs.
I keep looking for a way to bridge the gap between WYSIWYG page designers and plain text perl backends. Any and all suggestions are welcome.
-Xanthos
Average Intelligence is a Scary Thing
Merely copying a site to another server won't do, you need to make sure you have correct extensions, and hopefully, the developer was conscientious enough to allow for easier relocation of the site so you can just change some settings on just one file rather than do a full-blown hunt throughout the code. Tweaking the primary navigation also heavily depends on the architectural design of the website. In summary, I think the developer just did a poor job of doing some basic designing prior to the creation of the website. Therefore, I think the article is just a big complaint to write something before the drop time for his article.
Java was on the right track, but was, perhaps, a little ahead of its time. Instead of rendering HTML, the browser needs to provide a virtual machine environment in which applications can be downloaded over the network, much like how web applications are loaded today, but implemented in languages suitable for development (which can include, but should not be limited to, Javascript).
HTML does not need to go by the wayside, of course. If your goal is to display an HTML document within the browser, you can link to the appropriate rendering engine application. The cool thing about this is that you would have the power to instruct Internet Explorer, for example, to download the WebKit renderer in order to display your HTML. If your need is HTML with some wiz-bang feature that nobody has thought of yet, you can write or extend your own HTML rendering engine and have the browser use your engine instead.
Where Java failed is that it tried to mimic the way native applications were installed and executed. It provided no benefit to the end user over a native application. WebStart attempted to solve the problem to some extent, but still did not hit the mark. We do not need to replace the browser, we just need to rethink what the browser needs to be capable of. A full virtual environment accessible to developers through the browser opens up a world of possibilities.
Which features are missing, exactly?
How about procedural audio? Say I want to write a speech synthesizer in JavaScript. How do I send the samples to the speaker?
POST and DELETE
You're confusing HTTP with HTML.
If you want to get picky, 'computer' were 'never designed' for media playback, using your criteria
Uhm, you're completely missing the point. Computers don't have to be 'designed' for media playback, media playback is simply an expression of the inherent capabilities available to a computer. A web browser is an application, not an operating system or hardware, that people are trying to force into being an application container. It is not meant for these types of things. People have found ways around these shortcomings; however, they generally tend to be poor, kludgy, and overly complex. This is, again, because HTML, XHTML, and such, are not intended to be used for application development.
Flash is another example of something that was not intended to be used for application development, yet it has grown to accomodate these type of possibilities and since the introduction of Flex, it's far less horrid than previously - but it still isn't a good development environment because of all its legacy baggagejust like web browsers.
Loading...
Actually, web development is pretty easy. Just that you got to stay away from the "do it all frameworks" that you want to "customize".
Either build it yourself or use off the shelf, but when you try to combine the two you get a mass.
The tools/languages he mentions all do their own things. And since when are html, xml, json and css a language? Might as well call headers in C a separate language.
Neither is cross-browser all that hard or rather, it doesn't need to be.
As an experienced web-developer I see some very simple problems with web-development:
Really, web development ain't all that hard, but the customers often make it far more expensive then it needs to be.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Say I want to write a speech synthesizer in JavaScript.
There is no emoticon for what I am feeling.
Populus vult decipi, ergo decipiatur...
"Force shits upon Reason's back." - Poor Richard's Almanac
You mean PUT and DELETE, which came in HTTP 1.1, significantly after HTTP 1.0 had defined all the methods as GET, HEAD and POST. These deal with the HTTP's resource model, which only deals with the URL notion of thing, not page-level interactivity which is what I think the OP was talking about.
Still, I do like HTTP 1.1 and one thing I like about REST is that it builds on what appear to me to be fundamental assertions about the HTTP model. You're not fighting the model, you're working with it. Still, I do wonder about how we got where we are today. Things are much harder than they need to be. Many of the things that help initially wind up hurting in the long run, and staying current is a constant battle.
x86 frameworks have been around for how many decades? HTML5 has been around for how many months?
Web development may seem like a pain, but last I checked, it's the only truly cross platform development environment that has ever existed. If your bank, for instance, had to develop binaries for every platform, you'd never be able to login and move your money around at 2 in the morning.
It's taken time to develop the standards that enable platform agnosticism of more vanilla HTML standards, and it will take time to flesh out new standards that compete with native toolkits for interaction. But it will happen, and compiled, single platform application development will be nearly unheard of.
You don't need to know many languages to develop a good webapp! It only takes HTML, CSS, Javascript, SQL, PHP and a bit of Linux knowledge to put together a simple app!
Which features are missing, exactly? Cappuccino, for example, implements almost exactly the same APIs and conventions that native Mac/iPhone developers use, only in Javascript.
Holy mother of god. That's so incredibly scary ... from their site ...
Fucking hell. This is a hack built on top of a kludge built on top of a monstrosity and then delivered through your web browser. Make it stop!!
This is just shit piled on top of shit, with HTML and HTTP still sitting at the bottom. The web has done more to mangle software development than almost anything else. It's all workarounds to try to overcome the fact that the underlying technology is outdated and useless.
There's been so many attempts to make something workable on top of this mess -- having one's browser running an object-oriented framework and platform abstraction layer in an interpreted language is about as boneheaded as you get.
It's all one big giant steaming turd.
I've been around for a while, dealt with a lot of code that had a missing developer, and one thing I noted was this simple truth:
Every significantly complex piece of code you didn't write, every system you didn't design is "bad".
It doesn't matter if it's well formed, makes sense, works well together, you'll always find a way to complain about the coding style used, the design choices made, the libraries used or ignored, and until you've sat in it for a while, none of it will make sense to you. Not sure what I mean? Try spending some time in a few of the programming centric IRC channels, and watch everyone rip into someone else's code. The #python channels are especially funny since the loudest individuals there appear to be some sort of religious adherents in the church of python. In general, these folks won't even answer simple questions until the code is reorganized in the manner they're accustomed to.
The thing is, we're all like that. It's the same each time you pick up a new language, or you're tackling a new library. This isn't a web-based phenomenon - this is every piece of code ever, regardless of it's actual quality of lack thereof.
This is the sort of thing that you can't fix with single-vendor lock-in, or strict adherence to protocols, and it's not exacerbated by mixing and matching OSS projects. Inside a given company, it can be regulated to a point by having architectural guidelines, strict coding conventions, and well spread code reviews that ensure conventions are used - but the code will still be 'bad' to people outside the company.
I do have a fix for it, but I don't think the author will like it. You should make sure that YOU as a developer experience as many of the frameworks and languages and systems and such that are out there, continue to expand your awareness of program design from data structures to lifecycle management, and that way, when you experience one of these 'bad' systems, you'll be able to absorb what the previous developer was thinking a little quicker than otherwise.
of course, it could just be terribly written code, and not just subjectively bad, in which case I always end up voting 'slash 'n' burn'.
As a webmaster, if found the article strange.
We have better tools today, than years ago. Firefox and his amazing extensions (like Firebug or Webdevelopper) make analizing what is going out here, much easier. JQuery itself make writting javascript predictible (so if it works here, it will work on other browser). There are not lacks of good Code Editors. We use to have good HTML Wysiwig editors, but these are outdated by now (I could be wrong, but the better pad nowdays seems the brain of the designer).
So.. what you need? REDMINE to track proyects? Good debuggers? Inspectors? Documentation?
Working with HTML could be hard (specially if you have to support webpages that have to run on Internet Explorer 6), HTML itself is crap, Javascript is much more evil than people know (but I love it, like a bad girlfiend)... but.. the tools? what tools you need? tools that automagically write code (good code) for you? Visual Studio seems to have some of these, and while I don't use these myself, I have ear good things... (if you are into wysiwig and how bloated any code touched by microsoft looks. ). What you want exactly?
Could be, maybe, that you don't know what tools we the professional webmaster have available? :-)
-Woof woof woof!
I think the problem with looking at html code from many webpages today is that it is all auto-generated by a back-end server. And, IMO, auto-generated code is almost never pretty, producing a jumble of hard to read code.
Yes, it is a mess, no doubt. But the features are not missing.
Fail. And he was doing so well up to that point. A decent software engineer doesn't need the software equivalent of a drug pusher (IBM, Microsoft).
There's also something to be said for a tightly-controlled economy backed by a government with absolute power. Nobody starves, and all that.
Alas, that situation turns out to be unstable in the long run because it can't cope with an ever-changing, inherently uncontrollable world, the "absolute power" thing corrupts absolutely, and various other defects not visible within the tightly-controlled system, even after they are visible to everybody else.
Long run, it appears that the unplanned, unmanageable, chaotic, unstable, failure-allowing "free" system actually works better. It even let fewer people starve, oddly enough.
Since communism provably killed and tortured more people than Nazism, the rhetorical device is at least as offensive and overblown, so I would now like to claim the fastest implementation of Godwin's Law in Slashdot history!
JavaScript on the HTML DOM is the lowest common denominator in much the same way that Java applets used to be. If not in JavaScript, then how else should I make an app that synthesizes speech on the client side without requiring me to write a native app for each platform, get the app digitally signed by the platform's controlling organization (in the case of non-PC platforms), and convince PC owners to allow its installation?
Neil's experience reminded him that a tightly controlled ecosystem backed by a major vendor does make it easier to define best practices, set development targets, and deliver results with a minimum of chaos. There's something to be said for that."
So whatever you do, don't use open standards, open standards screw up everything. Only develop for MSIE, and other "standards" used by major corporations to embrace-extend-extinguish.
And this coming from infoworld? Why do I smell a corporate propaganda thinly veiled as some sort tech commentary?
Even for excellent software developers, web development is difficult. It's not the concepts that are difficult, per se, but rather the jumble of half-backed hacks that make up ever layer of the web stack. The foundation is so weak that anything built upon it just can't stand well, even if it itself is well-designed (given the constraints of web development).
Just look at the common open source technologies used by many web sites. MySQL is one buggy hack upon another. PHP is much the same, plus some security holes.
Uhm, deficiencies of MySQL and PHP don't necessarily mean that web development in general has to suck. What about the Seaside framework? To me, Seaside is a clear demonstration how much it helps sometimes to step away a bit and rethink an old thing.
Ezekiel 23:20
The problem is JavaScript. It's the tranny hooker of web development: looks like OOP, wants to be OOP, and you can try to use it like OOP, but once you get her skirt off you want to run from the building screaming.
Not pictured: The author's big fat cheque from Adobe
"Neil, we don't care that you don't know much about web dev. Just make up some really bad anecdote and hope it sticks"
Shit sux.
having one's browser running an object-oriented framework and platform abstraction layer in an interpreted language is about as boneheaded as you get.
Sorry. I thought that was how 50% of the web "worked". :)
Why is it so hard to only have politicians for a few years, then have them go away?
In my experience, the tools for web application development are overwhelmingly crufty, and a stateless, connectionless protocol is a nuisance.
Then make your application architecture stateful! Use continuations, Luke.
Ezekiel 23:20
There are a couple of problems I see in web development:
1) Unlike the systems programmers, myself included, for a given topic area tools are adopted and standardized.
Web developers seem to get jobs based on the flavor scripting language of the year.
(All of which is crap in my opinion....i.e. php, javascript....python...)
It always seemd too me, that XML, XSLT CSS and Java servlets are really all you need and you can build marvelous interfaces. Tried that once, but the response I got was (thats too hard, lets use javascript).
2) The closest I have come to a decent application framework for building web apps is Java. It has clear security controls, recognizes the importance of Virtual Machine technology to compartmentalize access in a dangerous online world. It even has a very straightforward debugging environment which is quite impressive to track down bugs.
But curiously, it is shunned because if you don't know the scripting language flavor of the day, people don't want to build web sites or won't hire you.
Which is one of the reasons why I don't write web applications anymore. Because when your job and pay is based on how fast you can memorize the scripting flavor of the year, and it doesn't bring anything new to the table (in many ways it can be even worse) to solve the problem of writing a web app, well...it becomes just a money game.
I mean really, I don't mind learning new languages, but I haven't seen anything new since Java 1.6 was released that is any better...just mostly worse.
3) Finally the field has become too greedy. I mean, there is no reason why it has taken this long to standardize video and audio, except for the fact that greed is everywhere.
It is really sort of disgusting, and the crap you have to go through to get video onto a persons browser is just way over the top, mainly due to Adobe and Apple being greedy idiots.
Maybe when the Video and Audio tags get full support for open protocols I will write web apps again. It isn't rocket science, but it is currently a science of idiocy.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
There are so many web frameworks out there, like the author says. New ones are released and existing ones are updated on a regular basis. The truth is it takes time to learn a framework and become comfortable with it. We can't possibly keep up with it all.
While i am one to admit that Web Dev is, for some parts, a bunch of hacks, most of it isn't.
JavaScript, the DOM, and CSS are all highly detailed on W3C site. The only ones who chose to ignore the standards was Microsoft. (although it seems they are turning around now)
All the stuff you said is literally the exact same crap we deal with in Operating Systems NOW.
Not all programs run on all OSes the same. I've had cross-platform programs run faster / slower on other machines, use more / less memory, look different occasionally, etc.
Let's not forget how much of a bitch it is in the first place to MAKE a cross-platform executable. Compared to web dev, web dev is making a cup of coffee, cross-platform software development is like building the machine to make the coffee granules. (actually make them, AKA 3D printer or something like that)
If you actually READ the standards on W3C and work with them, you shouldn't ever screw anything up outside of IE browsers, or working-drafts, or on the rare occasion where there is a legitimate bug in finished implementations of standards.
JavaScript doesn't lack a damn thing when it comes to application development for the most part, it is the DOM model that is the mess, and methods and attributes across some browsers. (see keycodes and other such things)
You either haven't used JavaScript at all / are trolling, or you just plain suck at it.
The only other problems are really memory management and leaks with functions and objects. (which varies between each browser)
Again, this is all just sounding more like software development in general: it all sucks, it is all a mess, but those who stick to the standards get by fine without any problems, it is the ones who have to deal with the idiots who went outside the standards and generally fail at decent coding styles (no indent, awful naming, etc)
The worst thing of all web development is the web browsers.
All these people developing them refuse to do huge changes to the base code to actually stick to the standards simply because it will break websites.
SCREW THEM, if the developers in both cases stuck to standards, none of this mess would exist!
People who code shit deserve to suffer incompatible mess.
If everybody done it at the same time instead of pussyfooting around with minor changes, we'd look back at this day with a smile and sigh of relief.
Ditch compatibility modes as well. If people refuse to update, they don't deserve to be on the web.
Backwards Compatibility is the worst thing in development, it just results in a mess.
You can use data: URIs to send the generated audio data to the browser's media player. Not exactly pretty, but it is possible. Wrap it in a sane API and it needs to be no more difficult to use than a native audio API.
I think he's talking about JavaScript missing critical language features. You know, things like proper namespaces, exceptions, static typing, a sensible object model (or even something like the approaches to prototype-based OO that Self and Io take), and so on.
There's a big difference between a scripting language like JavaScript, and scripting languages like Python, Perl and Ruby that are much more advanced and suited to large-scale development. Even then, there's a much bigger gap between those languages and languages like C++, Java and C#, which are suitable for huge-scale development projects.
Are there actually ANY good development environment for working with PHP and Javascript simultaneously? I use NetBeans but it doesn't really keep track of say, when a javascript function loads data from a php with the xml loader and things like that. I always end up with a strange hybrid of serverside and clientside code that is impossible to sensibly keep track of. Any suggestions?
The other point is typography was a (still not completed) after-thought. At the outset html was for replicating the scientific paper and HTML's terseness and simplicity was its strength. Control for layout was given to the client browser and academic papers could be read in Mosaic or in lynx; one need not worry about what the user was using. Tables and images were added later because these are needed for academic writing. Because there is a standard flow of information in the academic paper and because the entire paper is the singular object of interest, the need to break up presentation with content wasn't manifest.
The web took off, and, as is human nature, folks looked at this low cost communication medium as an opportunity for commerce. Now, that brings in security, authenticity, state, content/presentation separation and typography. Persuasive communication is very important to effecting a sale. Persuasive communication is structured and in the specific cases of visual advertising, the movement of the eye and the rhythm of presentation matters a lot. Now page hosts had to have a large degree of certainty that the elements of their page did not more around as they were transmitted to their visitors, even though the heterogeneity of the client machine was and is a complication. The grid is a fundamental graphic design and was not (is not?) available explicitly in html and the later css. So, designers went and hacked the best alternative, using the <table> element. We also had spacer or invisible.gif, a one pixel by one pixel non-visible <img> element. I've always been a hand-coder, so I have no idea if the professional tools of fifteen years ago were using the hacks in order to provide a rigid structure to the page. I do know, from helping co-workers learning Dreamweaver, that ten years ago the font stuff was still being set per paragraph.
Incidentally, Flash provided a grid which helped it spread and why it is (my opinion, formed in the days of dial-up) overused.
As for the op, I'm okay with it being a jungle out there. While the computing analog of the strong man brings with it consistency, places where it happened also demonstrate how often power corrupts. Sun wanted everyone to use java, but didn't want java to be of more benefit to another vendor's products. Understandable, but it should seem obvious that their motive conflicted with the write-once run-anywhere mission. Everyone uses their products to cross-promote other products of theirs. Thus, the browser wars and the remaining inconsistencies in document models and rendering, like so many trenches, craters and unexploded ordnance in the 1920s Belgian countryside.
Any way, the web is what it is. As the world wide web was an outgrowth from academic communication, vendor neutrality is in its DNA, to use a cliched construction of the day. And there is a lot of bad web design/interactivity implementation out there. Oh indeedy, some clients will have and are going to pay to have their prior designers' works unraveled. Some of that is a natural consequence of multitudes shooting at a moving target. Some of that is because the clients didn't spend the money at the outset to hire someone who would do it correctly.
And that is exactly why I wanted xhtml2 instead of html5. It has a real framework for web applications between xforms and xml events. It is almost exactly what I would have done for my perfect web application format. The only thing I would add would be the ability to send a model from one page to the next without transmitting the data to the server.
when so many frameworks are available that if the original developer of a site gets hit by a bus, they'll be no person in the world qualified to maintain it.
It's not like that is likely to fail in every non-IE browser
Not to mention all the vastly different things a web developer needs to know to even stay afloat - a single project usually requires knowledge in CSS, HTML, JavaScript, some form of server-side language (PHP, ASP, etc), a database (MySQL, MSSQL), etc. Add on top of that all the different browser quirks one has to take into account (like how the 3 major flavors of IE - 6, 7 and 8 all render differently and require different hacks to make standards-compliant markup actually render properly) and the different vectors of attacks that have to be accounted for (XSS, SQL Injections, Local/Remote File Includes, Cross-Site Request Forgery, etc.).
Not to mention the disdain that web developers see online all the time regarding their profession from their kin in the software development world, or the fact that the rising popularity of do-it-yourself CMS systems like Drupal, Wordpress and Joomla are bringing mom and pop into the picture...
What's the word for it? Ah yes, "clusterfuck"...
database ->
stored procedures ->
ashx (c#, know your libraries) ->
xslt (still version 1.0, grrrr) ->
html (which version?)
+ css
+ js support files (javascript, know your libraries)
+ maybe flash, which is its own parallel universe
the js part is a huge deal when dealing with ajax schemes, xmlhttprequest... which loops back to another completely parallel track of the main DSAXH sequence above
and then you need to take into consideration the different browsers and their rendering quirks
it really is pretty nutty the number of languages and open windows you need to jump back and forth between and what you need to take into consideration
you also need to set up and configure the web server os and webserver software
but you know what? you look at the early industrial age, when they were still just imagining locomotives and automobiles and airplanes, and you're talking about guys who had to be good draftsmen, machinists, metallurgists, mechanical engineers, office managers, etc. and you think "how the hell did they do it?"
so when you think about all the disparate languages and moving parts you need to integrate, just to build a coherent, not very complicated, website, you think you know some small pantomime of the complexity of the world the early industrialists had to work in. its not that bad, its a living. what can one ask of work except that it challenges you and doesn't bore you and might offer some sort of exciting fruits from your labors? a chance to change the world? you are demanded to do many things and wear many hats, and this means you work in an environment where YOU are important, where YOU can prove your mettle and prove valuable above other "wed developers" who just find nothing but tedium in the whole endeavour and disparage it
they apparently yearn for a world, some future generation of web programmers, who will operate more along the lines of "buy car, press start button. if car breaks, take to repair shop. end job function"
i don't envy this less complicated world. in such a world, web programming will be as a exciting as being a check out cashier (and pay at the same rate too, and YOU will be as completely interchangeable and forgettable as a coffee filter)
revel in it, don't disparage the complexity. in full work mode, all 400 cylinders firing, you are something of a god, bringing forth new technologies that might still be used hundreds of years from now, and be the very backbone of human society. enjoy living in the dawn of a new technological era, which is what the web still is, so much of the ground beneath our feet is still in play, and some of us get to be influential in that, in much the same way that early railroads shaped the fate of nations and ideas and the birth of cities
we are doing something of the same today, and by necessity, by working on the cutting edge, that is complicated, difficult, and messy
and that's good
roll up your sleeves, and shape the world. if all you can think is "this is too complicated", you're in the wrong line of work
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Other than the horrid startup time, I actually quite liked Java applets for exactly the sort of reason you mention.
in an interpreted language
What, you haven't switched yet from Internet Explorer to a modern web browser?
Ezekiel 23:20
The tools/languages he mentions all do their own things. And since when are html, xml, json and css a language? Might as well call headers in C a separate language.
I never understood this argument about what defines a 'language'. Why aren't HTML and XML considered languages? They've even got "language" in the name!
And the C header argument doesn't convince me. Headers are simply a subset of the C language. Sure JSON started off as a subset of JavaScript, but I'd argue that it's a full-blown language since it's often used independently of JavaScript. C headers are not used independently of the C language.
These arguments about what makes a language really a language seem overly pedantic to me (a la hacker/cracker debate). They're all "languages" in my view.
You're thinking of the Dunning-Kruger effect.
A study appeared recently in the journal Internet Standards, detailing disturbing findings that, as usual, the mainstream tech journals chose to ignore entirely. This study showed that on a per-bit basis, HTML 5 ranked, in terms of standards, almost at the bottom, just below Microsoft and above North Korea. Walt Mossberg's comments in today's Wall Street Journal are interesting, because they are technically accurate. He called HTML 5 a "standard", something you will almost never hear a mainstream reporter say. He also pointed out, truthfully, that Youtube now "uses" HTML 5. He made no mention of dissenting opinion, but that is hardly unusual. What is interesting in this case is that just two days ago, the International Court of Justice released a one hundred and seventy-three thousand page report on HTML 5. This fact did not get reported either in Mossberg's article or elsewhere in the mainstream press. The ICJ report is interesting in two respects. First, the finding is unanimous not only among the seventeen justices who drafted it, but across 190 nations, with two exceptions. Israel and the United States. Israel, we will remember, is one of the fastest growth areas for technology companies such as Microsoft and IBM. Capital is just flowing in. The United States, for its part, represents the interests of almost all of the big technology names you can mention, everything from Microsoft, to Google to IBM, just all the big names. Now in the United States, these companies have powerful lobies, in fact they have freedoms no one posses. The United States vote was almost entirely determined by this lobbying. Unusually, the United States chose not to hear petitions from any citizens. That is rare. More commonly, anyone can make a petition, it will just end up in the garbage can if you're not a Fortune 500 company. I don't want to go too far, but if we look at it in a historical context, this motion is similar to what Sophie Scholl, the famous dissident in Nazi Germany was told when she made her case to a judge, pleading her right to publish fliers detailing the truth about the regime. The judge told her "the time for political opinion in Germany is over." In developed, modern democracies, we stop short of saying those words, but the spirit of that statement is fully present in all aspects of the HTML 5 process.
I'm sure Cappucino is great, and no offense to you, but it seems every time I point out that Javascript is horrible, someone tells me that no, it's not horrible, and all the features that are implemented or emulated by X Y and Z new frameworks, and I go back to Javascript and try those things, it still strikes me as still crufty and horrible. Why did I have to go out and get a framework to implement features that I should already have?
HTTP != HTML
Dumbass.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
there are countless frameworks like this, stop plugging :)
..."I inherited a pile of crap so I'm going to blame the state of the web for my pain." Even a Ferrari can be ruined by a bad mechanic.
This is how the web should be structured in the future. "Pages" can still be written declaratively, just like our interfaces for desktop software can be designed and stored declaratively. However, they can be compiled into bytecode classes that get sent back and forth in serialized form over "HTTP" (or whatever new, stateful protocol someone comes up with.) The browser will become this: A Virtual Machine and a Layout Engine/Server - The VM will "run" the site as bytecode and directly manipulate the site's layout. . This can still look and feel very much like the web today.
But under this paradigm, you can write your apps all in one language, be it Java or any other language. After all, there's no reason VM bytecode couldn't be generated from any number of languages, just like Java bytecode today. If you want you can, as I said, still declare your user interface in HTML and "connect" them to actions on the client or server side or as outlets to Java classes. This will also allow transparent server-client interaction - methods can be moved from the server to the client at will, also making offline browsing more flexible.
People might point out that you can already write your application in one language using GWT. Yes, GWT might be a good candidate for a layout toolkit to run purely from bytecode on the client side. However it cross-compiles Java to Javascript. I don't want things getting cross-compiled from a bytecode compiled language to an interpreted language. They should be written in a compiled language and stay there. The point is to jettison Javascript and to allow a fully featured object-oriented language or language(s) to run inside a secure VM sandbox.
A lot of people will probably tell me they don't want this. One objection(out of possible thousands): They might say it would a lot of people who currently doing web design would be prevented from doing so because of the high barrier to entry of learning a new programming language. My reply would be - in order to develop modern web sites, these people already program, badly, using two or more programming languages. What would be lost in switching them to a good language for the benefits of greater security, more powerful applications, and being able to write solid web applications rather than barely standing constructions made out of the digital equivalent of wood glue and toothpicks.
For all the idiots saying 'HTTP != HTML' ... HTTP is useless without HTML. If you don't even know that...
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
"Yeah IE6 failed - And we don't ever want to go back there again."
Are you joking? IE6 was such a phenomenal success that industry still can't shake it. You can't possibly justify calling it a failure. By every metric it's a piece of software that succeeded. I'm replying to your message using IE6 - 9 years after it was introduced.
Had it failed, it wouldn't still be holding back the web.
Personally I think this desperate need to shove everything in a browser is a retarded sickness that needs to die. It's like trying to shove a potato through a straw. The solution isn't to adapt the straw to be potato-friendly.
Just look at the common open source technologies used by many web sites. MySQL is one buggy hack upon another. PHP is much the same, plus some security holes.
PHP has matured over time. It has certainly matured faster than MySQL. PHP is an extremely flexible language, with a robust syntax. If used properly, it is a powerful language that can do quite a bit. I've written daemons in PHP that have outlasted the JAVA applications they are connecting to, processing millions upon millions of documents. PHP may not be multi threaded, and that's a huge drawback, but you can fork. It's a decent work around if you know what you're doing (like any good parent, keep your children in check!). The hate against PHP is unwarranted now.
HTTP has been over-extended well beyond its original use (cookies are a hack to get around its statelessness, it's caching mechanisms are fucked to high heaven, SSL and TLS are hacks).
With the soaring popularity of "RESTful APIs", I would argue that HTTP is going back to its basics and we're finally ditching XML-RPC and SOAP and what not that aim to reinvent the wheel. Besides, what is "over-extended"?. HTTP works well for Meebo and it's doing STREAMING.
JavaScript is perhaps the most horrid hack of them all. Something meant for adding minor interactivity to a page has been misconstrued as being suitable for large-scale application development, although it lacks many of the most basic features necessary to do that sort of development effectively.
Hold on, you're telling me that a prototype-based language with strong emphasis on events and closures is bad for UI? JavaScript itself was never a problem. It's DOM that's a problem. Luckily, DOM is hidden away by some fantastic frameworks, the most powerful of which IMHO is jQuery. jQuery makes client-side javascript extraordinarily elegant. Then there is NodeJS. Server-side javascript. I suggest you try it out.
It's difficult enough to fight with unclear and conflicting requirements alone. Toss in shitty technology, and it becomes very difficult even for the best seasoned professionals to develop even just mediocre software systems.
I really fail to see how a seasoned developer can't pick up a OOP language like JavaScript or PHP quickly. These are syntactically simple languages similar to Perl or Java. It should be simple to pick up by a seasoned code warrior and that code warrior could probably create large scale applications with intuitive interfaces in your web browser with ease using PHP and JavaScript.
Good troll though. I'm sure you've really ruffled up some feathers.
I'm god, but it's a bit of a drag really...
And if you are a good software engineer, you can overcome these minor inconveniences...
Javascript is actually a pretty nice language. Browsers, on the other hand, suck. HTML web pages are a terrible place for application development, no question.
You, of course, never need a framework. You can do everything that Cappuccino does yourself. Frameworks are what make development happen, though. No matter what language you develop in, you are going to use a framework of some sort unless you are crazy like RMS and feel the need to write absolutely everything from the ground up.
You can use data: URIs to send the generated audio data to the browser's media player.
And then you can file bugs in each major web browser's bug tracker asking why your test case of sending a data: URI containing a .wav file to an <audio> element doesn't work.
I believe 8^O~~~ (eyes wide, mouth vomiting) is what you were looking for.
God invented whiskey so the Irish would not rule the world.
There is HTML5 Solitaire so what else do you need?
The things you mention aren't so much hacks (HTTP and MySQL are hadly hacks... PHP, well OK) as technologies that aren't a part of a coherent design philosophy. Web development barely has a design philosophy (REST is an interesting idea, but it's hardly an architecture). Compare this with other complex software ecosystems, UNIX in particular, and you can see that it's the philosophy that makes many of the warts go away. In UNIX, your whole toolchain just hangs together naturally, and using it is a pleasure.
It's absurd that to write a web application, you need to minimally know some kind of database query language, many forms of markup, at least one server-side language, and Javascript (the most horrid language of all time). And due to Javascript's horribleness and lack of platform-consistency, people use Javascript frameworks, which, surprise surprise, themselves have issues which must be tracked. Kinda makes you wish you just had a C compiler again.
We're at the point now where cross-platform rapid application development for Desktops (e.g., GTK#) is vastly easier than writing the equivalent web app. I love the idea of universal access, but trying to use Javascript to cram data through HTTP just ain't cutting it. I've come to the conclusion that if you want a 'rich' application, don't target the web as your platform.
The problem I find with web developers is that they are too busy chasing the "Ohh shiny" of the month.
I've seen the same thing with "regular" developers. I can't tell you how many times I've seen the same thing that the original poster pointed out in code. I saw one guy who did his front end in Java, text parsing in Perl, some back end stuff in C++, I even think there was some other things mixed in for this one application - all under the excuse of "the best tool for the job". It was a buggy flaky piece of shit. And the kicker was the coder rewrote a 'C' program that was working perfectly and just needed some modifications. 'C' was "old fashioned" and "not suited" for the application according to him.
RIP America
July 4, 1776 - September 11, 2001
And I'm sure the ancient artists went through the exact same thing.
The things change the more they stay the same - I guess.
RIP America
July 4, 1776 - September 11, 2001
... to have a scripting language that worked equally well on the browser and on the server and wasn't a complete piece of shit like Javascript? One programming language, one presentation language, one style language.
I'm not trying to discount current solutions here, I'm just saying that there has to be a better way.
Works fine Chrome and Safari via the <audio> tag. It works fine in Firefox through the <embed> tag.
I do not have IE installed to test, but I suspect it does fail. However, who cares? If users really want to use your TTS system, they will install another browser. They are going to have to install a native application to achieve the functionality no matter how you look at it.
On top of the individual problems of those technologies you mentioned (PHP, MySQL, JavaScript, etc.), the fact is writing a "web app" requires you to be proficient in at least all 3 of these things. On top of it most of the time JavaScript and PHP end up being so intertwined you end up with what amounts to self-modifying code.
And of course HTML is not always HTML... neither is JavaScript (browser variations). I don't see how anyone can really write maintainable code for the web given all this stuff. I'm sure people can write "more" maintainable code than others. But it really doesn't compare to desktop applications.
And you just have to look around for proof. It's been 15+ years since the web took off.... and we're /still/ trying to figure out how to have windows and dialogs. Yes, maybe we finally have some decent web-based email clients now. But really the ones that existed 15-20 years ago were quite nice as well. It's true... the web has set computing back 30 years.
Comment removed based on user account deletion
We keep making the web browser do things it never was and should never have been intended to do. Instead of writing an actual interactive, client-server application, we kludge together something for a browser which then becomes vulnerable to bugs in the browser, the various technologies used to make the page interactive, the back-end services, etc.
We have a hammer, the current WWW stack, and we see all problems as nails, even when said problems are screws and would be better handled with a screwdriver.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
I hope that those in Development have a greater understanding of the Languages they use to program than does the author of this piece ... "Ways to Go"??? The proper syntax would be ... Way to Go. Definitely a compiler error waiting to happen!
Comment removed based on user account deletion
MySQL sucks? Don't use it.
PHP sucks? Don't use it.
Hackiness in the backend is not a difficult problem to solve. Most Web developers use PHP and MySQL? Well, that's because they're bad programmers, and these tools are targeted at bad programmers. Use something better.
You don't even /need/ to use JavaScript. Things won't fly around the screen and people might have to wait a microsecond for their FIOS to download an entire new page, but Web 2.0 cruft is hardly a requirement. You're free to use no JS at all, dab it in where it's useful, or be a jerk and make your whole app JS-based if you want.
. . . as soon as everyone agrees on the HTML5 standard.
No one will live long enough to call me on that one.
I recently tried out basically all the calendering programs available as native applications on OS X and linux that had a chance of being able to sync with the iphone calender (which can use a standard webdav protocol for syncing). I wound up settling on Google's calender, which is a web application (even though it has had its own issues). (I used remind, and its curses front-end wyrd, for years, but no caldav sync there.)
Just thinking here...
HTTP is actually not bad for simple forms of AJAX. AJAX is just a fancy method of one-way message passing (and basically a form of RPC).
Where HTTP breaks down is when you want to send events from the server to the client. Say you are facebook and want to update everybody when a friend logs in. To do this, the client either needs to listen on a port for messages from the server, keep a session open with the server at all times, or poll the server every so often for any new events. HTTP wasn't designed for keeping a session open*, polling the server isn't "instant", and the idea that the client should listen on a port is just a security nightmare.
I'd vote for holding a session open with the server. But there are problems--every major site is sitting on a cluster of servers. Every HTTP request is routed to a different server. You dont want to hold a session open on a single server as you'd overload it. Even if you tossed out HTTP and did some other protocol, you'd still have to deal with the load-balancing issue.
Maybe polling the server isn't so bad? Yeah it might generate more needless load on the backend, but it is also much simpler to implement than holding a session open the whole time.
I dunno.. I'm not a CS major. Probably somebody with a PhD in CS could invent a more elegant way of doing large-scale two-way message passing.
* Yeah, keep-alive, but keep-alive isn't meant for the same thing as what I'm talking about...
Everyone LOVES doing the design and implementation phases. Except most people don't even get that right and sort of "design" it as it is being "implemented" (hack it until it APPEARS to work).
When the correct approach is to start from the maintenance point-of-view and work backwards.
Design and implementation are easy and fun and best of all they can be done during the regular work day/week.
With maintenance, you often have to schedule an outage, which means off-hours. And people have a strong opinion as to how it USED TO WORK BEFORE YOU TOUCHED IT. Being a day behind on design or implementation is one thing. Being down a day because of maintenance is another thing entirely.
If you design it to be easily maintained, and you correctly implement that design ... it will be easy to maintain.
Sorry, my previous attempt at submitting this comment had a paragraph chopped off
I recently tried out basically all the calendering programs available as native applications on OS X and linux that had a chance of being able to sync with the iphone calender (which can use a standard webdav protocol for syncing). I wound up settling on Google's calender, which is a web application (even though it has had its own issues). (I used remind, and its curses front-end wyrd, for years, but no caldav sync there.)
I found it amusing that this web app was prettier, more responsive, more intuitive, and more capable than any of the native applications that I had tried to use (well, maybe Apple's iCal is about as pretty). All the native applications were either too slow, too buggy, missing some essential feature, or some combination of these. Amusing, because people have had decades to try to come up with a decent calendar app, and here is Google stringing one together to run in a browser, and it's better, even in ways (responsiveness) that you wouldn't expect.
No, it's really not. The development tools are ass and the language itself fails with its non-intuitive comparison operators. Being prototype based leads to really nasty code and "creative" ways of scoping variables. But that's if you want to be pedantic. If you are willing to lump the standard library in with the language, then you've got even bigger problems. What's actually cross-platform is a pretty small subset of anything useful, leaving people to roll their own hacks.
The revolution will be mocked
Look to Native Client and its sound API.
1. The Win32 API ? .NET Forms API ? .NET WPF API ? .NET Silverlight API !
2.
3. or actually the
4. No, wait, the
5. Nobody has Silverlight yet, MFC is way better !
6. Desktop APIs suck, let's use Flash 9. It rocks every where... that's the way to go.
7. Flash 10 is newer . Let's use that.
8. Nah, Flash crashes too often on Mac. Let's use Carbon.
10. Oh wait Carbon is old school. Let's use Cocoa !
11. mmh iPhone version ? or the Mac OS X version.
12. Even better let's use java awt.
13. oh wait. that was the initial api. Swing ! Yeah , that's modern.
->
tightly controlled is still crap.
->
open is also crap. but at least it is open.
Eyes wide, mouth vomiting is not what that looks like.
Everything I say is a lie. Except that... and that... and that, and that, and that, and that... and that.
I'm not saying that it's impossible. It's just really hard. Google has the money and people to make that stuff happen. You can use Google's toolkits, and that makes development easier in some places, but it still does not address the fact that things are done wrongly in the first place.
I grew up in Massachusetts, and I've lived in Boston for the latter half of my life, so I've grown accustomed to our bizarre system of roads. I always thought that they had a certain charming quaintness to them. But then I travelled to new cities, like Miami, where they've had the opportunity to actually plan a city, or Manhattan, where they have enough money to level things and start over again. The difference is night and day. Modern cities have this property where you can go where you need to without needing to plan a route. Just go. Everything's on a coordinate system. In Boston, you are forced to ask some irritable local, who barely knows anything outside his neighborhood anyway. That's the difference that proper architecture makes. The web platform is like Boston, which makes sense given that the W3C is headquartered here.
Come on everyone knows you use the right tool for the job. You shouldn't even be considering JavaScript when the correct answer is obvious, Flash.
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
> And if you are a good software engineer, you can overcome these minor inconveniences...
Minor??
It's bad enough, that writing a Web application can take at least 5 times as long as writing the equivalent app for a well-designed and mature platform. Not leastwise because once you finish implementation, you have to track down all the side-effect bugs in the Web frameworks etc. that make your application fail (or just look ass-tastic) on certain browsers and OSes.
You're missing the difference between a language and libraries. A language is keywords, syntax and grammar, operations and expressions. Libraries (and frameworks) are bundled pieces of prewritten functions that actually let you do something. Libraries are the "features" let the language interact with its environment and/or accomplish real work.
Javascript is actually not a bad little language, but it has a limited feature set (bundled libraries) and the environment js typically lives in (a web browser) is a complex tree of rendered elements. Worse, different environments behave in slightly different ways, meaning that a piece of code that worked in Safari might not work in IE. (Okay, WILL not work. Happy?)
Frameworks iron out those differences in such a way that you can usually ignore them, and get on with actually accomplishing something. Yes, you could do without them, but now you're the one that has to get your code working everywhere, and, basically, reinventing the wheel. Add that to the fact that most employers would rather have you generating visible results...
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
...the desire to provide users with a stateful experience in a inherently stateless environment.
A tightly controlled ecosystem will only mask the issue, allowing people to blame MS and rally for Open Source when neither matter.
Hold on, you're telling me that a prototype-based language with strong emphasis on events and closures is bad for UI?
No. It's not that it's directly bad for the UI, it's bad for maintainable code. Closures are a great idea (and work very well with Ruby), but with Javascript nearly everything turns into a closure.
The revolution will be mocked
You shouldn't even be considering JavaScript when the correct answer is obvious, Flash.
The article is about "HTML Web App Development". Flash doesn't run on a lot of non-PC devices that have HTML5 browsers, and as I wrote in another comment, it'd be a pain to have to make native apps and get them certified just for one missing API.
No argument there; I just found their calender to be an instructive example. I have no idea how painful its creation was for their programmers.
I don't think so. Manhattan evolved haphazardly from the south; when they hit what's now Houston street they started to lay the roads out on a grid, more or less. Try to navigate my old neighborhood in southern Manhattan, or the warped spacetime of W. 4th St, and it will be much more confusing (and interesting).
It was never meant for fancy interfaces and detailed interaction (i.e what ajax does), just crude page-by-page apps (somewhat like CICS), and even that was possibly an afterthought.
Playing media is an application. Computers are designed to run applications.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
How about procedural audio? Say I want to write a speech synthesizer in JavaScript. How do I send the samples to the speaker?
Well, it depends on if you mean "in the browser" or "in JavaScript." If you mean that latter, I'd probably fire up Mozilla Rhino and put together something using the libraries that ship with Java. Some of those are still available in the context of the browser via applets in a lot of cases, too, so with some work, you could probably do it in browser as well.
If you mean in-browser, no Java libraries, I'd probably have the samples in an array of bytes which I'd base64 encode and stuff into the src attribute of an audio, embed, or object tag as a dataURL. This likely wouldn't work in realtime, but then again, you didn't ask for a realtime speech synthesizer. :)
(FWIW: I know Flash 10 has an audio buffer explicitly for writing to programatically in realtime, and I agree it's awesome I agree a lot of the people going on and on about how great Ajax was and HTML5 is and how it all renders Flash totally unnecessary are generally not thinking about features like this. Just pointing out that there is in fact more than one way to do it and some of the other approaches have their merits.)
Tweet, tweet.
There is an emoticon for how you are feeling, but we all know how ALAX (Asynchronous Logo and XML) lacks many of the most basic features necessary to do that sort of emoticon effectively.
Right. No, your other right. No, the other other right.
You are so far off the mark on Javascript it's not even funny. JS is a very good, if unconventional language. The problem is the shoddy implementation by multiple browser vendors. C would be a pain to work with too, if your interpreter was IE6.
Learn about Photography Basics.
PHP is flexible the way C is flexible, and its syntax is actually extremely fragile.
PHP has only one advantage over Python, Perl, or Ruby, and that's that it tends to come bundled with mod_php -- which is just an installation issue. It's the slower, bulkier, least organized, least strict, least explicit, and least powerful of the four.
See it in action here. If you're talking about that mess of cluster that is subclassing from Exception, yes it doesn't have that (perhaps Dojo or other js frameworks do?) However, unlike Java and the like, this language at least has closures.
Make sure everyone's vote counts: Verified Voting
Even for excellent software developers, web development is difficult. It's not the concepts that are difficult, per se, but rather the jumble of half-backed hacks that make up ever layer of the web stack. The foundation is so weak that anything built upon it just can't stand well, even if it itself is well-designed (given the constraints of web development).
Just look at the common open source technologies used by many web sites. MySQL is one buggy hack upon another. PHP is much the same, plus some security holes.
HTTP has been over-extended well beyond its original use (cookies are a hack to get around its statelessness, it's caching mechanisms are fucked to high heaven, SSL and TLS are hacks).
JavaScript is perhaps the most horrid hack of them all. Something meant for adding minor interactivity to a page has been misconstrued as being suitable for large-scale application development, although it lacks many of the most basic features necessary to do that sort of development effectively.
It's difficult enough to fight with unclear and conflicting requirements alone. Toss in shitty technology, and it becomes very difficult even for the best seasoned professionals to develop even just mediocre software systems.
One of the major problems with calling out problems with JavaScript, PHP, MySQL, and others is the fact that used by themselves, with no interaction with other languages or any bridges of any kind to pass data between them, they truly are horrible to use. But once you've gathered the right tools together and know how to use them - which is completely different from "knowing how to code" - you really can begin to build decent web apps.
Right now it is difficult figuring out which tools work best together, and that is most often the problem people run into. However, even if you were to get the right tools most of the time the design or talent/effort of the software engineer becomes the choke-point.
I think we've come a long way in web development. We still have a ways to go, but that negative attitude of yours towards the honest efforts of many aspiring developers that make the tools possible in the first place is a sad sight to behold.
You truly are an anonymous coward.
Life. Is. Good.
I'm not gonna feed the trolls for crying out loud!
2^3 * 31 * 647
How do I send the samples to the speaker?
I'm sure you think you're very clever, but that would be a limitation of the environment Javascript is running in, rather than the language itself, wouldn't you say? No, you probably wouldn't, but you'd be wrong.
C'mon, Slashdot, why do idiots like this keep getting modded up? Is that really all it takes, spewing a bunch of misinformed and unsupported "facts" which have no basis in reality? I suppose, though, if you're one of those developers who has no actual idea what they're doing, blaming the tools may well make you feel better.
I think we might need a new moderation value: "+5, proving the mods are as clueless as the poster."
Which features are missing, exactly?
I don't know about Cappuccino, but writing large apps in a dynamically typed language like Javascript doesn't seem to be a good idea. With application development, a large amount of time is spent debugging code so you really want to catch as many bugs as possible as early as possible.
If I am writing some kind of order system I might declare a variable called PackageWeight. I want that variable to always be a float. If it ever becomes a string or something else, then I have made a mistake in my code. In JavaScript I can't enforce the type of PackageWeight and this leaves my code open to more errors than I would like. Those errors will show up at runtime (and even worse, they may not show up all the time). In the particular case of Javascript the situation is even worse because you are not even required to explicitly declare variables at all. So if I mistype PackageWeight as PackageWieght, PackageWieght becomes a completely new variable, introducing bugs that could have you scratching your head for hours. The ability to mistype variable names without getting a compile time error is not a very useful feature.
Obviously having the ability to extend applications via scripting is a very useful thing, but the shortcomings of JavaScript have lead to various companies having to extend it to include static typing (e.g. Actionscript, Unity3D's flavour of JavaScript etc). These are all separate efforts though. It would be nice to have some standardized JavaScript that has been extended to include explicit type declarations. People who find it an effort to declare types could go on just using "object" types but everyone else could make use of static typing to reduce type-related bugs and frankly improve the readability of the code (e.g. It would be nice to see at a glance exactly what value types you are required to pass to a function). Static typing would also allow for more useful code completion etc, since more information about the code can be extracted by a compiler.
Hi AC,
I keep hearing this from time to time. It's actually exacly the opposite. The web stack is extremely well-designed and implemented rather cleanly, when you compare it to other programming environments. Do you honestly think Windows development is any better? Linux? Have you seen what happens when a Linux kernel boots? Are embedded systems not half-baked? Please, provide an example of a system that's actually useful, in active development throughout the globe, that hasn't got hacks here and there.
Well hundreds of millions of web sites beg to differ. There is technology for reaching the masses with text and graphics. There is technology for making it all scale. There's tech to get video out there, content delivery networks, caching. All in vanilla HTTP. There's technology to reach visually impaired people. All standards-based, it all works rather well. Heaps of frameworks are built on top, many of which are extremely stable and useful. Try jQuery for size. It allows you to do everything on any browser (yes, even IE6) with one common language.
You can't beat that, period.
Those are just two examples. MyISAM could be classified as such. Then again, you can use InnoDB. Or god forbid Postgres. Or NoSQL. PHP? You can use Symfony, cake, Zend. heck you name it! All with CSRF and XSS protection, all with advanced database drivers supporting bind variables; you name it. Or, gasp, you could try Python, Ruby, Java, .net. "the entire web" does not equal shitty PHP scripts + an aging mysql you know.
Cookies are a useful extension to a stateless protocol. Are you seriously suggesting you would prefer a stateful protocol instead? Please tell me you're making a cruel joke. You would need hundreds times the current server hardware to cope with that amount of traffic. In fact I don't think you could run the web in it's current scale on a stateful protocol. Which means you will never be able to do that.
Caching is fucked up? Citation please. Caching works just fine. SSL and TLS are hacks? In what way? How would you improve them? I have the distinct feeling you are completely clueless with regards to massive-scale protocol design. Say you don't like cookies because the name reminds you of how your mommy wouldn't allow you more than one a day. How would you implement a stateful protocol instead? My bet is you would probably need some kind of token, we could call this a ... a ... yes a legume, between client and server to maintain some kind of, hmmm, let's say a little piece of memory on the server. Yes that would be a great way handle state!
Again with the unfounded claims. You do realise that something meant for adding minor interactivity is able to grow, in order to support more and more interactivity? This is not a bad thing. Software APIs grow all the time, and something like javascript has actually matured really, really well. Sure enough it can do much much more than originally envisioned. But then again an open, standard
Countless, with this level of maturity? Seaside is just an example - albeit an example that has been proven as useful in practice (like, in real deployed applications with complex logic).
Ezekiel 23:20
Add to that that you have to support browsers which do not even follow any standards remotely and which are 10 years old to make this more miserable, but I agree as a seasoned web developer, the foundation at its core is broken for application models.
Interactive UIs in javascript plastered on top of an xml like dom model sheesh, where is the isolation of components, where is a fully working model of events (not the hacks which are currently in) where is the statefulness needed for those things, where is the real messaging which is needed to control this stuff.
This is a foundation which has been layed out at the Xerox parc and has proven for 30 years that it works, instead we have the dom, javascript and the web.
Add to that javascript, a lisp like wannabee, unsuitable for bigger systems, no common namespacing, everyone has to hack his own inheritance on top of a glorified function table the prototype, no typechecking whatsoever parameters are merely a little bit more than comments etc... While this all looks nice on paper, everything bigger than a hello world becomes a nightmare. Add to that that you have to add 20 lines of browser hacks and fallbacks for 5 lines of correct code to get the things up and running as expected (which means additionally on every IE there is) and you have something where X as protocol shines compared to it.
It's funny we consistently have debates about how Apple through non support is killing flash off. And you make a good point about how Silverlight has the potential to take over the web from W3C. I would argue that Flash/Flex is already way ahead of Silverlight and has the install base.
Developers here may hate flash/flex but it pushes the envelope in terms of features. And as the article pointed out having a third party push us to a Rich Internet over the monolithically slow W3C process isn't so bad.
As a developer I have no sacred cows and am pretty agnostic in terms of what I develop in. I will pick up whatever platform the web is now running on. What I do care about is install base and features. I want web apps to be as powerful as desktop apps. Give me the best platform for building a Rich Internet. I'd love to see an open spec HTML 5 and JS win this race if JS was easier to debug in and HTML 5 had the feature set. But for that to happen, you're right, W3C needs to step it up.
Well, the direct alternative to Cappuccino is Cocoa. Cocoa is implemented in Objective-C, a dynamically typed language. All of the large Mac and iPhone apps using Cocoa seem to manage just fine.
Qt is another popular choice for this type of development. Granted, C++ is not a dynamically typed language, but Qt implements a preprocessor to bring some dynamic-like features to the language.
Which brings us back to Javascript. Dynamic typing and user interfaces seem to go hand in hand. Even if you are not developing your application for the browser, there is a pretty good chance that you would be using a dynamically typed language anyway. That is not to say that static-typed interfaces are impossible. Just more complicated to implement.
Static typing may be useful for heavy lifting code that responds to events from the interface, but even with browser development you are not limited to just Javascript for those kinds of tasks.
Development is often a creative endeavor, and like most creatives there are myriad opinions on what the most important aspects of the craft are. This article seems to come from the angle that "structured development solutions are paramount." I have worked with a lot of developers who fell into this camp, and generally I agree that any network of developers (whether a programming pair, project team, or whole web development community) should strive to create a development vocabulary that puts people on a common ground. However, this single-mindedness ignores the fact that even this goal benefits from the waves and eddies caused by new models, new patterns, and experimental solutions that are the nature of what we do. We gain a lot from not treating a need for that structure as a limiting factor in how we evolve these technologies.
Web technologies are capable abstractions built on top of other more stable primitives. All programming languages and environments are just an ordering of primitives through various layers of abstraction. 1s and 0s are given meaning through a processor, assembly gives you a language to interact with that meaning, C creates a higher-level (but still generally considered low-level) abstraction to that, other languages are built on C (or interpreters are built on C) to simplify it further. As you go higher up the tower of abstraction, the more work you're trying to keep the developer from having to do themselves.
Many of the most contentious web technologies (PHP, HTML, Browsers, Javascript, CSS) exist on a pretty high tier of abstraction, and these and frameworks/environments built around these technologies have evolved with the goal of meeting the demands of an audience. It's mostly irrelevant at this point to say that a technology like Javascript is bad because "it was designed to make small interactive elements on a web page" -- because like all web technologies, it is evolving. PHP was created to do some very lightweight CGI tasks for its creator's resume website -- but 5 official versions later, it is used to drive many of the largest, richest applications on the Web - and it continues to evolve. All these things are getting more and more ordered -- hell, even Internet Explorer is responding to standards on its newer browsers with a relatively impressive pace. At the same time, the industry is recognizing that as painful a road as it has been, it was all made possible by the fact that there were a silly number of choices for how to do something, and you had competing clients and implementations. Even now, while the HTML5 standard is looking like it help unify rich interactivity in a Web environment in a relatively widely adopted way, it was also written with the understanding that different browser vendors will choose to vary their implementations and introduce experimental features that they would like to see in future standards.
What you end up with is a competitive model based not only on end-user products, but on the quality of tools to create those products -- the main difference from similar models in other industries being that the tools we use are often ostensibly free. It's not the only way it could work, but I'd point out, and this is my main point: it has worked well
Well structured, elegantly written code or not - web technologies have served to grow a humongous industry, built on interfaces and platforms that we all appreciate and most of us can't imagine living without. It has worked very well. It'd be pretty hard to argue that you could have anticipated the design the web should have followed and been successful. The ease of adoption of these scrappy technologies has been essential to the Web's growth. As frustrating as it can be to see things done in a stupid way, sometimes the people for whom something is being designed don't care about how it was done, just that it was done. I, for example, know some of how Yahoo does (or used to do) their templating and localization, and I think it's one of the pug-fugliest solutions I'v
I agree that for some people web development is not very hard. Just like for some people programming in assembly language isn't hard. It sounds like you're just saying that we should pay more for consultants like you and stop complaining. You'll take care of everything and send us a nice bill. But web development could be a lot better for everyone including you. For one thing, Javascript should be made type safe as it is with actionscript. There are lots of issues we've already solved with other languages and UI SDKs that have not been applied to Web App Development. Web App Development is stuck in the past. It was defined by people at Netscape who were innovating very quickly and didn't take the time to get it right. Now we have to live with their choices more than 10 years later; no tree control, no pop up menus, no grid control, no tab control, no split panel, no layout managers, WTF! Thank god there is dojo and other toolkits but they are a hack and those features would be much better if they were built into the browser. It is so frustrating to have people like you telling everyone not to worry about the difficulty of Web App Development because you think it is fine. The real issue is that many more developers suffer while you profit from their pain. Of course you want it to stay as hard as it currently is. You're like the big oil company telling us not to worry about lead in the gasoline because we shouldn't pay more at the pump. It doesn't bother you to rewrite someone else's poorly written website but it is a waste of everyone's time and money none the less. Following your line of reasoning, nothing would ever be made better because someone thinks it is ok the way it is.
I think this has been improved, especially with JavaFX but applets have had such a bad start and Flash made decent inroads so it'll be hard to get people to convert despite the fact Java would be superior to Flash.
I don't think it is so much about over coming them but that you shouldn't have to spend nearly as long testing (if not longer) in loads of browsers as you do developing it. It's not fun but it is necessary.
One thing that helps is writing a CSS style sheet that wipes the browser default styles and then allows you to start from a common base. But people shouldn't have to do that and add one more file to request. Imo, browsers shouldn't apply any styling. It should be up the dev to do his job right.
I think he's talking about JavaScript missing critical language features. You know, things like proper namespaces, exceptions, static typing, a sensible object model (or even something like the approaches to prototype-based OO that Self and Io take), and so on.
If you actually know how to program in JavaScript, rather than assuming you should be able to write Java or C++ or whatever your favorite language is, then the language actually has suitable idioms/mechanisms for all these things that you mention, except static typing, which might be a legitimate preference strike if you're the kind of person who actually does full-on static analysis/correctness proofs, rather than the typical static typing whiner who grips to compilation and type hierarchies as a kind of magic feather.
Tweet, tweet.
While not entirely proper, namespaces can pretty much be emulated trivially with objects. So I don't really see the issue here, unless you're one of those people who think that the programming language has to include everything for you to be able to use it.
ECHMAscript has had exceptions since 1999 with the release of version 3. Javascript quite possibly had them even before that. What's the issue here?
If static typing is one of your requirements, then you're correct, Javascript doesn't fit your needs.
What's wrong with how Javascript does prototyped-based OO?
Javascript is actually a pretty interesting language once you learn how to use it correctly. There are just a lot of ways to use it incorrectly (which is how it's used 70-90% of the time.) Anyways, feel free to actually look these features that Javascript has had for at least the last 10 years yourself if you don't believe me (or want to further try to justify your statements.)
*Whoosh*
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
but that would be a limitation of the environment Javascript is running in, rather than the language itself, wouldn't you say?
Sure, "JavaScript is Lisp with C syntax". But in practice, "the environment Javascript is running in" is the HTML DOM. So how do I deploy a better environment to all my users?
MySQL ... PHP ... JavaScript
Good work hero! Now that you've defeated the stage 1-3 bosses, you're up against the final boss: HTML itself. I hope you've bought a lot of potions!
Having evolved over the years to imagine everything as "content" and "presentation" there just isn't any space left in the beast for "application". Hidden inputs (state) are neither presentation nor content, yet you must place hidden inputs within a block within a form or your page is invalid.
Browsers aren't helping... before IE's button tag worked properly (<button value="5">Buy Me!</button> used to return "Buy Me!" instead of "5" until IE8) it was next to impossible to produce a standards compliant shopping cart page showing a table of products without embedding a copy of the entire form into every cell that had a widget. Is it any wonder that developers turned to using GET links to perform destructive commands, and javascript heavy "postback" bullshit to get things done? (Yes, I am aware that you could have one form elsewhere in the code, and buttons in each row with javascript to update a hidden input in that form and submit it and leave people without javascript to wonder why things weren't working. Or you could have a jumbled listing of products that looked like complete shit because you were thumping your chest over not using tables to display tabular data. At least inline-block and min-width has made it so that you can build a div/CSS table that looks right when the browser is big enough even if it turns to shit when something wraps.)
The sad thing is that despite all this, it's still easier to make a nice looking flowable form in HTML than in the majority of GUI APIs out there. I can't count the number of times I've had to hit ESC to get out of a dialog in my netbook because the dialog won't fit on the screen and can't be resized.
Exactly. What we need is a rich-GUI markup language standard that handles typical and common desktop-like and CRUD idioms and behavior naturally. That way we are not reinventing the wheel or cobbling together different parts and tools from all over the web.
The next "Mosaic" of GUI browsers is out there waiting to be invented. The next Marc Andreessen waiting out there for an opportunity, here is the place to make your stand.
Table-ized A.I.
Good post. Eloquently spells out all the gripes I had with the parent's post. It's just too bad you're a Ruby developer. heh
Bullish Machine Tzar
It's pretty difficult to refute something that's just a bunch of opinions without any supporting examples or evidence. All you can really do is reply "that's not true" to each one. I've done quite a bit of web development over the years and, mostly, i think they're not really true. However, i believe it's the poster's genuine opinions, rather than a troll.
You have a choice - either do a good job with the tools available (which is possible and there are lots of examples around the web), or do a poor job while you whinge and moan about what's stopping you from doing a good job.
As they old saying goes, bad craftsmen have a tendency to blame their tools.
intuitiveness is in the eye of the beholder.
I think you're looking at it the wrong way. It's not remarkable that some (actually very few) things don't work across different environments - what is remarkable is that so much of it does work across browsers. And, as in everything in life, there's always a way to do what you want to do - so long as you're smart enough to find it.
Yeah, but they do, so there's no point getting frustrated with it, cos it ain't going to change. The fix is as simple as adding a few lines to the top of your stylesheet - there's no need for having another file to request.
I don't agree that it's really hard. If i were to judge from the vast sea of complaints about it, rather than my own experience, i would think it was hard.
But i suspect that most people who find web development hard are approaching it in the wrong way. If they stopped being so preoccupied with how hard it is and focussed on finding ways to make it work as smoothly as possible, they might find it's not so hard at all.
When it is hard is when you have to fix up someone else's sloppy work.
That's not true. There are a tiny handful of things that require some sort of workaround for IE6. But, apart from that, if you structure your html properly it will work in all browsers. Javascript is remarkably standard across browsers (again with a tiny handful of exceptions).
It's the DOM implementation that varies from browser to browser - but even that's not a massive obstacle in most cases, so long as you know what you're doing.
Ha ha! You clearly weren't programming 30 years ago! I was - in assembly language - and i can assure you that even the crappiest web app is way way ahead of what was happening 30 years ago!
> How about procedural audio? Say I want to write a speech synthesizer in JavaScript
That's not a property of the language. It's property of the platform the language has access to (the browser). Javascript is no more constrained than any other language that lives in the browser sandbox in that regard.
In fact, you can synthesise speech in Javascript on some platforms/browsers quite simply because those platforms do provide TTS apis to the browser.
Javascript does have language issues - mainly around namespacing and modularity and a paucity of robust types. But with a good library in hand it's actually much more pleasant than some of the other parts of the web stack.
Difficulty does not mean that there is a problem, but it does indicate that there is one. What does indicate a problem is when doing event-driven GUI programming (you know, the style of programming that was invented, oh, 30 years ago) requires hacks (i.e., AJAX) to function. Did I mention that web programming is singly-threaded? Ah, I forgot, if cooperative multitasking was good enough for Windows 95 and System 7, it sure is good enough for the web! No worries, though, we'll have awesome 1980's features like generics in Javascript Real Soon Now.
The web as a platform sucks. I've done web programming for more than a decade. Our current mess is a perfect example of design-by-committee. Most Internet technologies succeed because the barriers to using them are low, NOT because they are technically superior.
Alright, that was an exaggeration. But seriously... useable windowed applications, RPC, etc. yeah maybe they had some issues here and there but they were around in the early '90s and that was 15-20 years ago, and there were some quite useable apps.
10 bucks an hour for freelance work. That is minimum wage.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
It sounds like you're just saying that we should pay more for consultants like you
And what is wrong with that?
But the point is, if you want open continued development, you are always going to have different platforms. Unless you want to freeze all browsers to HTML4 and somehow enforce them doing everything exactly the same, then what you want is impossible.
How are you going to force MS to update its javascript version?
And as for making Javascript type safe, sorry but the nature of many languages is to use this loose typing as a feature. Learn to work with it or move on to a different language.
Basically you are saying: If only all cars were exactly the same and controlled exactly the same, traffic would be a lot safer. Yes it would. Good luck getting it to happen though.
Meanwhile I work in the real world and don't believe in impossible dreams. Ever since computers have been invented someone wanted to create a magic programming solution that would make it as easy as a Star Trek Computers. I don't see it happening, but I will buy one from you when you build one. Meanwhile, I will collect a high fee to work with what we got, all so I can afford your magic system when you build it. That is fair isn't it?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Please show me how you program in XML, HTML, JSON. CSS is getting some extremely basic selectors but still I would hardly call it a programming language. Your defintion is for languages as in English. Programming languages are different. If you make this claim around real programmers, prepare to be ridiculed.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Well, the direct alternative to Cappuccino is Cocoa. Cocoa is implemented in Objective-C, a dynamically typed language. All of the large Mac and iPhone apps using Cocoa seem to manage just fine.
Objective-C supports explicit type declarations. e.g. You can declare an integer and the compiler will enforce the type. If you want to use "object" types you can of course, but many statically typed languages have "object" types you can make use of if you really need them.
Dynamic typing and user interfaces seem to go hand in hand. Even if you are not developing your application for the browser, there is a pretty good chance that you would be using a dynamically typed language anyway.
Most windows GUI apps are written in statically typed languages like, C++, C#, Java etc.
Static typing may be useful for heavy lifting code that responds to events from the interface, but even with browser development you are not limited to just Javascript for those kinds of tasks.
I would say Static typing is useful if you want some confidence your variables are not going to change type by mistake half way through your code. For me that is virtually all of the time.
Integers are not Objective-C objects. You have to manipulate them at the C level, which is statically typed. If you use a first-class Objective-C object, like NSNumber, the compiler most certainly does not enforce the type.
As I mentioned, one of the most popular toolkits for writing Windows GUIs is Qt, which uses dynamically typed C++. If you choose a statically typed language to build your GUI it is not impossible to do, but you are probably using the wrong tool for the job.
My team develops killer, maintainable, money-making web apps using nothing but html, javascript, php, mysql, and occasionally java for signed applets all running on a 100% free lamp stack. Frameworks are for pussies. .Net, J2EE, Spring, ORMs, etc add very little value to the web and ultimately the end user. The only exception to this would be Rails. Rails and the whole RESTful concept is just cool beans. Everything else is more marketing hype and technical religion than substance.
@zuperduperman: Please read my reply to this comment.
I think he's talking about JavaScript missing critical language features. You know, things like proper namespaces, exceptions, static typing,
Wait, static typing is a "critical language feature"? What the hell are you smoking?
Now, Javascript is weakly-typed, which many people see as an issue.
have you read the Moderation Guidelines Addendum?
Right, because that's a vital feature for all effective large-scale application development.
Look to Native Client
Which doesn't help when users are using something other than a PC. The released version of Native Client is for x86, not ARM-based devices, and makers of devices using an ARM CPU are unlikely to allow Native Client to be installed on devices that they manufacture because it would circumvent their app store business models.
> unless you are crazy like RMS and feel the need to write absolutely everything from the ground up
BS unless there was already a free-as-in-freedom software toolchain before GNU.
For all the idiots saying 'HTTP != HTML' ... HTTP is useless without HTML. If you don't even know that...
But the converse is not true.
Which features are missing, exactly?
How about procedural audio? Say I want to write a speech synthesizer in JavaScript. How do I send the samples to the speaker?
I'll get right on to it once I've finished writing my operation system in COBOL and device drivers in LISP
It appears you've never worked on a platform with only a single available language. The web application environment is such a platform.
Javascript has taken hints from lots of other languages. In many ways it provides a C-style syntax, yet it's == operator is not an equality operator in the way that == is an equality operator in C (or, really, C++).
It's a poorly designed mishmash of technologies with lousy tool support. Sure there are lot of cross-platform libraries around if you can afford the code bloat.
And, sure, you could say that well it's a great language that suffers from a poor standard library and poor implementations. But if no decent standard library exists, at what point do you stop making excuses? If no decent implementations exist, at what point do you stop speaking in hypotheticals?
As someone who's done enough javascript wrangling to last a lifetime, lemmie point out that the cross-platform stuff is great for your simple sites. But for anything slightly complex, you're still going to have to deal with browser differences (beyond their inability to render HTML the same way). Plenty of people have made plenty of applications with VB, but that doesn't make VB decent.
The revolution will be mocked
I know exactly what the difference between the two are. I also know that native machine code for one system can be interpreted on another. That is what non-JIT emulators do. Emulators like VICE and Java. I also know that using the technique of "Just In Time" compilation, chunks of native code for one system can be recompiled to the host platforms native code for dramatic speed ups. This is done in some Jave emulators, as well as many other emulators such as UAE.
Right from suns site a description of the java virtual machine looks exactly like the description of a physical processor. Why? Because the JVM is an emulator of a real machine that may or may not have ever actually been built.
I understand the definition just fine. You are just trying to change the definition to something that boils down to "cross platform is whatever I decide is cross platform". You define one emulator (JVM) as cross platfrom, while other emulators (VICE) you define as not. You define some interpreted instruction sets (Python) as cross platform, while other interpreted instruction sets (6502) are not cross platform even when code written in it can be run across multiple platforms.
If I write a VM like the Python VM, but I dropped the context of white space, and use commands that look like one or two bytes for each command, would that be cross platform or not?
just create the sound of scrreeeeechhing brakes for that idea.