Dawnis something that I've been working on as an answer to the question that I believe a lot of developers (amateur and professional) find themselves asking, even if they never quite formulate it this way: "Why is it so much easier to hack together a CLI script than a web application?"
I think that part of the answer is that our development tools were born in the *nix shell environment, and that they simply haven't evolved very much to accomodate web-style UI/UX and deployment practices. In order to begin writing and testing a shellscript, all I need to do is type
vimand I'm off and coding. "Deploying" the script usually as simple as
By contrast, consider the simplest possible scenario for deploying a web application, one that requires no back-end for storing state, managing users, and so on. Something braindead easy, like a tip calculator. Most experienced nix hands wouldn't even write a script for this, but simply use
dc, or even
Dawnshould live completely in the browser. The development environment should be the same as the deployment environment, just like a CLI app.
Worse, if we want someone other than ourselves or grandma to use the app, we'll need to spend some time making it look nice. This means using some kind of pre-written theme or CSS framework, lots of fiddly CSS changes, or both. Without this, our web application looks like a joke to a user-base that is used to their web applications seeing the same attention to design detail as Soviet propaganda posters and glossy architecture magazines. People don't want their web experience to look like a university course website from 1998.
Dawnapplications should look respectable by default, without needing additional frameworks.
The other problem with the arms race of design and faddish, complex, layouts is that we're constantly reinventing the basic vocabulary users have to interact with web pages and applications. The worst example of this is the wave of monstrous sites that will actually scroll left for desktop users when they spin their scroll wheel down. Instead of contantly changing the semantics of our web applications based on design fads, or in a misguided attempt to make them more "intuitive", we should instead realize that the best UI is one that is eminently familiar to the user, and that the only way users can /become/ familiar, and therefore adept, at using an interface, is if we /leave it alone/ and give them a chance to learn it.
Dawnapplications should have a consistent UI paradigm that is stable and cannot be changed by ordinary applications.
x foo bar bazin Joy is the same as
baz(bar(foo(x)))in traditional notation). I admit that this RPN-style notation may not be the most developer-friendly, but it does simplify the execution model (depending on the point of view, there is either no state, or the stack is the only state). There are also ways I can explore of providing a more traditional
ALGOL-ish syntax while maintaining some of these benefits.
Dawnis very much a work in progress and not especially useful for any real-world purpose yet. In particular, there is no way to "save" programs besides copy and pasting them into the console command line, but it is already fun to play with, which you can do here. An overview of the extant operators is below.
'plus', 'times', 'minus', and 'divide'
Just what it says on the tin. All of the operators work on the top two elements on the stack.
Also pretty self-explanatory;
swaptucks the top element underneath the one directly below it, which then ends up in the top position.
Brings the third value from the top to the top, such that
[a, b, c]becomes
[b, c, a].
Removes the top value from the stack, and clears the stack completely, respectively.
This is the heart of Dawn's nascent UI model. This treats the top element on the stack as a string and creates a box with this name. The "name" of a box is both the identifier used to refer to it in later Dawn code, as well as the box "marquee" displayed in the UI, meaning that you only need to be able to see the box in order to write code to manipulate it.
Dawn boxes are receptacles for output, currently just text, but eventually images, etc. They are automatically reflowed based on screen size, and behave intuitively and consistently. By making the output model easy to reason about, we reduce the mental overhead necessary to deal with it, letting the user deal with solving their actual problems.
These operators write (erase and replace) and append text to the specified boxes. The stack is assumed to have the name of the box on top, with the text to append directly underneath it.
Simple control operators that operate similar to
ifdowill look at the top of the stack, and if it is "truthy", it will execute the list underneat it as if
dohad been called.
loopdowill simply execute a list the number of times specified by the number on the top of the stack.