4 ms·

Some people (myself included) prefer a more radical approach: Rather than fixing the inteface JavaScript presents ot the programmer, we replace JavaScript (or,

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/ http://elm-lang.org/

hoverbear 13y ago
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.
- catnaroek 13y ago
  Elm compiles to HTML, CSS and JavaScript.
  - moe 13y ago
    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.
chris_mahan 13y ago
ooooohhh where have you been all my programming life... edit: explanation: I really dig it!
- catnaroek 13y ago
  I am not sure how to interpret this comment. :-| edit: Heh! Go thank Elm's author, not me. :-P
prodigal_erik 13y ago
Does Elm have a progressive enhancement story at all? http://elm-lang.org/ 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.
- catnaroek 13y ago
  This kind of stuff is better handled on the server side by analyzing the user agent string, do you not agree?
  - mistercow 13y ago
    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.
    - nostrademons 13y ago
      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.
krapp 13y ago
But html, css and javascript serve different purposes. Why would you want to force them all into one syntax?
- catnaroek 13y ago
  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.
wavesounds 13y ago
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.
- gizmo686 13y ago
  What does Linux have to do with this?
  - wavesounds 13y ago
    Figured node.js would become node.elm too right?
- catnaroek 13y ago
  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.

hoverbear 13y ago

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.

catnaroek 13y ago
Elm compiles to HTML, CSS and JavaScript.
- moe 13y ago
  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.

chris_mahan 13y ago

ooooohhh where have you been all my programming life... edit: explanation: I really dig it!

catnaroek 13y ago
I am not sure how to interpret this comment. :-| edit: Heh! Go thank Elm's author, not me. :-P

prodigal_erik 13y ago

Does Elm have a progressive enhancement story at all? http://elm-lang.org/ 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.

catnaroek 13y ago
This kind of stuff is better handled on the server side by analyzing the user agent string, do you not agree?
- mistercow 13y ago
  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.
  - nostrademons 13y ago
    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.

krapp 13y ago

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

catnaroek 13y ago
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.

wavesounds 13y ago

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.

gizmo686 13y ago
What does Linux have to do with this?
- wavesounds 13y ago
  Figured node.js would become node.elm too right?
catnaroek 13y ago
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.