Monday, August 10, 2015

Elm Frontend


Today I implemented a front-end for Elm, a language that touts itself as "the best of functional programming in your browser". Integration is simple, you just include Elm code in its own fenced code block inside your markdown file, see this example hello_elm.md. This works the same way as the other JS transpiler frontends, Rusthon calls the other transpiler in a subprocess, and inserting its output into the final html. Checkout the other frontends in Rusthon for: CoffeeScript and Rapydscript.

Elm first impressions

My first try with Elm was a big disappointment. Things look bad starting with the install page, there it lists packages for "OSX", "Windows" and "Anywhere". First off I dont give a fuck if you have packages for OSX and Windows, support the NPM "Anywhere" package and make it work well. Next problem, the NPM package, at the bottom of the page it says, "Also, set the ELM_HOME environment variable to /usr/local/lib/node_modules/elm/share or the corresponding directory created on your machine." What the fuck is your problem Kevin MÃ¥rtensson? Do you really think i am going to play around with my environment variables just try out a transpiler.

Next problem, i run elm-make on my test and it asks me if i want to download some extra bullshit, it then drops this bullshit into the current directory i am running the command in! What the fuck, cache that in ~/.elm or something, do not just start junking up my file system.

first test code fails

import Text
myfunc a =
  Text.plainText a

I was pretty sure that was going to work, i took it pretty much right from chapter1 of the Elm guide here. Searching around i found that Text.plainText is deprecated, and this pisses me off. The problem with Elm and some other transpiled languages (like Dart) is they try to define a standard library of modules and functions, often this grows into some huge mess, which then gets refactored and parts deprecated. A language that transpiles to JavaScript does not need to reinvent all these things, there are plenty of JS libraries out there already. So why did Elm go down the wrong path? Probably because it has such shitty JS interop using ports, and so needs its own fat standard library because it is such a pain for the user to simply call a JavaScript function.

Wednesday, August 5, 2015

JavaScript backend: Debugger


This first reason why people give up when trying to learn JavaScript and HTML, they load up their test page in Google Chrome, and then see this fucking bullshit. It can be a blank white page, or your page half drawn with missing elements...

This second reason why people give up on JavaScript and HTML, they have to press Ctrl+Alt+J to open the god forsaken Google Chrome Developer Tools window. They see some error message in red and then have to click to the far right of it to jump to that point in the code.

Then the user sees the interface above and runs outside to puke. The line that caused the error is highlighted in yellow, for a split second, and then fades out so fast your eye can easily miss it. What the fuck?

Maybe then they give the FireFox debugger and try and see something even more hideous. Then they decide it is time to give up on JavaScript and HTML forever.


A Real JavaScript Debugger

This is the new debugger that is built into the JavaScript backend of Rusthon. When you transpile your project without using the --release command line option, it will insert runtime code to catch any uncaught errors, it parses the trace-back, and generates an HTML interface, with human readable error messages, and editable code that updates without recompile or reload.

note: if you do not include Ace.js in your HTML, then the debugger falls back to using a regular HTML TextArea, which looks like this.