Google Engineer: We Need More Web Programming Languages

itwbennett (1594911) writes Web applications may one day surpass desktop applications in function and usability — if developers have more programming languages to choose from, according to a Google engineer. 'The Web is always available, except when it is not,' said Gilad Bracha, software engineer at Google and one of the authors of Google Dart, speaking to an audience of programmers Wednesday at the QCon developer conference in New York. 'It isn't always available in a way that you can always rely on it. You may have a network that is slow or flaky or someone may want to charge you.' Therefore any Web programming language, and its associated ecosystem, must have some way of storing a program for offline use, Bracha said. The Web programming language of the future must also make it easier for the programmer to build and test applications.

Re:No, we don't

[PRMan]

Yep, and even if you use the correct tool for the job people rewrite it anyway. I used XSLT to turn XML into a different XML. It was 20 lines and worked great. I came back later and somebody had replaced it with 2500 lines of C#.

Re:No, we don't

[dgatwood]

A Google engineer that designed a web language no one wants to use much less need, gives a talk about how the web needs more languages.

Part of me wants to think the guy is just nuts but this is starting to seem like a trend from Google.

They try to create a many options/products as possible to weaken established standards and then take them over with half-assed efforts that never work out.

Even ignoring whether you trust Google to stand behind anything they throw out there, we really don't need more languages for web programming. JavaScript might have a few things that make it quirky, but it isn't a particularly difficult language to learn, and there's no compelling reason to use anything else.

The part of web app development that sucks isn't the language. It's the API. The HTML/XML DOM is a horrible way to design a UI, and browsers implement lots of things in different and inconsistent ways. For example, I once built a website that uses the HTML editing API, and found myself repeatedly adding piles of browser-specific workarounds. The worst was Internet Explorer, and it was such a nightmare that I basically gave up trying to make it fully work. But both Firefox and WebKit had serious bugs, most of which have still not been fixed (though a few of them have at least been fixed in Google's fork).

And that's the tip of the iceberg. While doing design work for an EPUB book, I found such fascinating bugs as:

• Safari/WebKit uses incorrect font metrics for web fonts, resulting in positioning being off by a couple of pixels (fixed in Google's Chrome Canary fork)
• Firefox/Gecko has a fascinating bug (989686) in which relatively positioned elements move around nondeterministically between reloads.

Almost every time I try to do anything significant with any browser (or with eBook readers based on browser engines), I end up filing five or six bugs against the browser, and although nearly all of them do get confirmed, within a small margin of error, none of them ever get fixed. All the while, these browsers keep getting new features, most of which are not fully implemented, most of which are just as fragile and buggy as the previous features that I filed bugs about, and we're trying to build apps on top of that mess. It's like developing for an early beta of an operating system, only the OS never gets out of beta.

That's what's wrong with writing apps on the web. The d**n browsers suck. They all range from horrible to utterly catastrophic. And that's me putting a positive spin on things. So before Google wastes a lot more time creating new languages that don't fix any real problem, thus adding yet another major browser feature that will only halfway work just like all the others, they and other web browser manufacturers need to take the time to fix the steaming dung heaps that they call browsers so that every single &^$@#(&^@ web programming project doesn't require me to spend 75% of my time working around browser bugs.