take-home is the world's first open-source project with all parts of the stack written in only Elm. The server-side code is Elm. The stylesheets are Elm. The client-side code is Elm.There's even a branch which shows how the build tools could be in Elm. We went all out to write as much as we could in Elm!
How to run
- Clone the repo
There's a lot in this project to take in. These are the important parts to look at!
In a brief summary, this program has support for the following in Elm
- Server-side programs
- A web server
- Database support in Elm
- Build tools
- Env/JSON config support
- Type-safe CSS
- Server-side rendered client-side HTML
- Shared models between client and server side code
- Server-side templating for data injection
- Moment.js wrapper both client and server side
- Knox server side
- Uuid server side
- Nedb server side
- StartApp on the server
While this project provides a good start place for anyone wishing to use full-stack Elm, it does not provide a "do everything" framework like Rails or Django just yet. There is work to make it more like a framework with scripting, but at this time it's not there yet.
How does it work?
The server itself follows the Elm architecture. It uses a modified startapp implementation. This means you have the following core functions
update : Action -> Model -> (Model, Effects Action) routeIncoming : Connection -> Model -> (Model, Effects Action)
Notice how there's no longer a view. The update function is responsible for updating the model, while the router is responsible for writing replies to the client.
Create a sensible way of having global footers and headers
At the moment, it's hard to link things in like stylesheets in each view without having a monolithic view function that rendered conditionally. It would be much more ideal to support a way of linking CSS in a header that was somehow included everywhere
There's no way of storing session data right now.
Should I use this in production?
No! This project was an experiment and a proof of concept. A lot of the ideas in this project are really cool. But being cool doesn't make for a production-ready system. Let's talk about a day in the life of a server-side Elm programmer.
- Write some business logic in Elm
- Realise that you need some library support that doesn't exist in Elm
- Spend the rest of the day fighting Node
As an Elm programmer, I like to write Elm! As a server-side Elm programmer, I hate writing yet another integration library that wraps around a Node library that uses mutable objects and callbacks in a weird way. There are a lot of battles that you have to face everyday writing libraries that work with Node. Sometimes there just isn't a way to make Node libraries play nicely with Elm. This does not make for a stable runtime, nor a stable platform.
The tl;dr here is that Node is not the ideal platform for server-side Elm. An alternate platform to base itself on would be great, but is unlikely to happen "soon". Please take away some of the ideas here and think about them! But if you value your sanity, your stability and your users, don't use this proof of concept for anything more than interest!
rtfeldman provided CSS support through elm-css
If you think this is awesome, why not apply to come join us make things?