Hacker News Reader

Comment by catnaroek | Hacker News Reader

Some people (myself included) prefer a more radical approach: Rather than fixing the inteface JavaScript presents ot the programmer, we replace JavaScript (or, actually, all three of HTML, CSS and JavaScript) with a different language that is actually designed not to be crap. For example: http://elm-lang.org/

View on HN

Once you get Microsoft, Apple, Google, Mozilla and Linux to all agree to and implement your new language please let us know so we can have you go fix congress.

What does Linux have to do with this?

Figured node.js would become node.elm too right?

It is not really my language, I am just a user. And Elm is already implemented using a compiler that translates Elm source code to HTML, CSS and JavaScript.

Does Elm have a progressive enhancement story at all? http://elm-lang.org/ is blank, and at a glance it entombs all content in javascript string literals, making linking and repurposing and any kind of semantic work just about impossible. The attitude that my content has only one useful rendering and I am fully responsible for it, and the client should only be able to execute that precisely, is destroying the web.

This kind of stuff is better handled on the server side by analyzing the user agent string, do you not agree?

I can't speak for prodigal_erik, but I strongly disagree. User agent strings are, to put it mildly, a clusterfuck.

First off, they identify browsers, not features. If a user disables JS, you can't detect that.

Worse, you would need know every UA string out there. This is, of course, impossible when a new browser shows up. And even if it weren't, it's not an elegant way to handle the situation of different browsers having different features. You're either going to have to do a separate code path for every version of every browser you support, or you're going to have to create a dictionary on your server to tell you what features are supported for each UA string, and then essentially do progressive enhancement on the server side. At that point, you're going through an awful lot of effort to do the work on the server instead of the client, with no clear net gain.

But the problem of new browsers is worse still. When existing browser vendors release a new version, they don't want all of the new features they added to be ignored by sites that rely on the UA string. And when someone makes a new browser, they don't want it to have everything disabled on every site it renders. So they go to elaborate lengths to load down the string with as much crazy as possible to trick sites into misidentifying them as existing modern browsers.

The big reason to do server-side browser detection is latency. Each feature you support takes code, and if you ship the code to the client-side, that code takes bytes and slows down the page load. If you do your browser detection on the server side, you can avoid shipping code to the client that won't work on it anyway.

It's usually a poor business trade-off to slow down the several hundred million Chrome, Firefox, and IE users for the sake of a few thousand users on a new browser. Numerous studies (first publicized by Google but replicated several times since) show a direct link between latency and conversions: the slower your webpage is, the fewer people buy from it.

The vast majority of the code you'll be "shipping to the client that won't work on it anyway" will be to old browsers. In almost all cases with modern browsers, the amount of code we're talking about is small enough that it will almost certainly not have a perceptible impact on latency. So you aren't slowing down those hundred million users. You're slowing down the rapidly shrinking minority users with ancient browsers.

If you're not doing server-side browser detection, how do you avoid shipping the code to support old browsers to new browsers?

Pre-IE9, most browser-specific hacks weren't of the form "Old browser X doesn't support new feature Y". They were of the form "IE does things differently." That required shipping a version for IE, and shipping a version for everyone else. If you gate these with feature detection on the client, you need to ship the IE code and the conditionals to gate it to the client.

Post-IE9, most browser-specific hacks are of the form "Emerging web standard X would be very handy but isn't supported in browser Y, so I'm going to emulate it with Javascript." That involves shipping JS to old browsers, not to new browsers.

You could use UA strings to serve the shims and workarounds, I suppose, but you could also use client-side feature detection to do the same thing more reliably. If certain features are missing, you load in the extra code. If not, you don't, and page load time is unaffected, except for the tiny amount of code required to do the feature detection. In either case, what you're doing is more graceful degradation than progressive enhancement.

But the idea of progressive enhancement is not just about supporting everybody's browser so that you will get more conversions in the short term. It's about the long term. Targeting the majority and saying "screw the fringe demographics" is what led to Microsoft having control over web technology years ago, and it's important to our livelihood to prevent that from happening again.

Then we all get stuck supporting both until its universally adopted (you know how some people still use XP?)

It is a noble desire though.

Elm compiles to HTML, CSS and JavaScript.

I'd love a modern GWT. One that's not rooted in java. Elm doesn't look like it wants to be that, though.

It seems to be aimed at games and graphics. There is not a single complex form, multi page flow or interactive layout in the examples.

But html, css and javascript serve different purposes. Why would you want to force them all into one syntax?

Markdown is an embedded language for content inside Elm, so it is strictly speaking not a single syntax. And Elm provides a better way to specify dynamically evolving content that eliminates the need for a separate language for specifying static styles.