FullStack NoSQL on SQL

There are several full-stack frameworks for python like: Django, Web2Py, and CherryPy. This PDF from the Web2Py docs has a pretty good overview of these frameworks, see web2py_vs_others.pdf. What you will notice with these frameworks is they each have their own fucked up way of embedding code and logic into HTML templates. These huge frameworks try to hide the details of the object relational mapping and database, but in doing so force you to use their HTML template language. Andy Shora has some interesting insights on full-stack dev, check out http://andyshora.com/full-stack-developers.html

Writing a full-stack system in Rusthon is pretty simple, this demo is just 300 lines and includes: backend, database, and frontend. See source code here. The HTML is raw and can be easily integrated with modern solutions like Angular.js. By not having some huge framework in your way, you can directly code the server to send data in the way you want, with whatever ad-hoc protocol you choose. In this demo all data is moved around over a websocket, and both clients are kept in sync with the server and database in realtime.

The Python library Dataset is used to hide all the SQL, and provides a NoSQL like solution in combination with property getter/setters on the client side, you never have to worry about directly writing SQL code.

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.

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

• wiki:JavaScript-Debugger
• example source code

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.