ccapndave

I use a sort of kanban board so I have a column of the backlog of things to do, a column of tasks agents are actively working on and a column of things that need review. The agents put summaries of what they did in each task and I can write my own comments there too. It’s not perfect, but it definitely helps me with context switching because I can open a task, quickly scan it to see what is going on and then open an agent with the task as its context to continue working on it.

Enjoying this so far! One initial comment is that I'm not sure the JS examples should all be embedded in an HTML page; why not code them to be run in node which means you can scrap the `script` tags and use `console.log` which is shorter removes the need for including line breaks.

Reason is still an alternative syntax to OCaml for native development, although I have no idea how many people actually use it for that.

Basically Bucklescript have forked their own (very similar) syntax from ReasonML and branded the whole syntax + Bucklescript + compiler package as ReScript. I suppose the goal is to eliminate the confusion of having so many moving parts and unify them all under a single ReScript brand.

ReScript is specifically ReasonML with Bucklescript, which is for transpiling down to Javascript. They also made a few minor syntax changes that make it look a bit more like Typescript.

I used ReasonML and Bucklescript for a self-contained part of a massive Typescript project to try it out and it was a joy. Here's hoping more people find out about it and it gets some more widespread adoption.

Other people's comments explain the details well, but I wanted to say that I have a large (real-world) project where the bulk of the app and all the business logic is in Elm, and all the more fiddly UI bits are in Typescript. The two languages communicate with each other over typesafe Elm ports and it all works fairly wonderfully.

I disagree - I think that firstly Evan wants to implement the right abstraction (which he doesn't think is traditional Haskell type classes), and secondly its simply not a priority.

Despite the abrasive tone of this article, it is true that Elm misses a convenient level of abstraction (whether that be type classes, module functors or whatever).

I spent the first few weeks of my first Elm project fighting against the language, trying to emulate type classes, build abstractions, do things like I would in other languages and generally having a bad time. Eventually, and with slightly bad grace, I conceded to the current limitations of the language and did things the Elm way, accepting that sometimes things are bit boilerplatey and cumbersome.

Now my second large Elm project is currently in its first round of QA, and the difference to similar projects in Angular or React is striking. There are no (and I mean ZERO) runtime errors that have popped up during testing. When QA find a bug, its instantly clear exactly where in the codebase the problem is, and usually simple to fix. So far most serious issues have ended up ultimately being consequences of a poor choice of design/modelling that, when fixed, has ended up in a higher quality overall codebase.

Yes, things could be better, and I'm sure they eventually will be. We would all like the kind of abstractions you talk about in your article, but in my real-life experience it turns out that you don't need them to write powerful and high quality code.

And hey, when these kinds of abstractions do arrive I'll just refactor my code, and know that the compiler will tell me when its done. Imagine doing that in Javascript.

If you don't mind using remote developers, then your location doesn't have to matter. It's true that it might be a bit harder to find a developer (although Elm is getting more popular day by day), but the other side of the coin is that your application is likely to have less bugs and need less maintenance. My experience is that Elm takes a bit longer to write than JS/TS, but once written it tends to work correctly the first time.

Its true that you can't currently write a service worker in Elm. However, in practice for any decent size app you are going to end up with a mix of Elm and Javascript with communication happening through ports. Therefore you can write the service worker in JS and then talk to it from Elm.

Of course it would be nicer to be able to write everything in Elm, but I find having the majority of your app in Elm with a bit of JS is significantly nicer than having the whole app in JS.

You can make it nicer still by using Typescript instead of Javascript, and defining interfaces for the data going through the ports, giving you type safety across the whole stack.

I'm using this approach right now in a mobile Elm/Typescript app with great success.

You take that back! I've been using it professionally for about 6 months.

This is certainly annoying at the moment (although there are workable hacky solutions). However it's a well known issue and there is movement at https://github.com/elm-lang/html/issues/19 so hopefully it will be addressed in the near future.

I suppose if anything it is the customer subscribes. But actually, in practice, it doesn't really feel quite like this because in FP you just have a bunch of functions and there isn't the concept of things 'owning' other things like you have in more OO based language. What actually happens is that you add a (sort of) listener to the subscription that fires a message in a particular update function, which manipulates some part of the model.

It took me about a day and half to upgrade a good sized project, and most of that time was spent sorting out native code. If you don't use native code and are using StartApp then its a fairly trivial/methodical upgrade process.

Another approach is to use extensible records, which give you structural typing similarly to Typescript. This means that you can pass the exact same state record/object around to different components, but a particular component might only specify that the state needs to have a `user` property, whereas another might only specify that the state needs to have a `friends` property.

I've never used ClojureScript so I can't speak for that, but the ports are now a lot easier in 0.17 as an outgoing port is simply a function that you can call, instead of messing about with Signals. Effectively, you send stuff to Javascript by calling the port function with a Javascript compatible value, and then you subscribe to messages on the way back in, which end up triggering a message on the update function of whatever component sent it out in the first place.

TL;DR its pretty easy once you've done it a few times

Its a little wordy, but now that I'm used to it, it takes no time to write decoders/encoders. There is also a tool to automatically generate them from JSON input at http://noredink.github.io/json-to-elm/

I moved from React/Redux/Typescript to Elm a few months ago, and I'm now on my second serious project with it, making mobile application with Cordova. I've found it an absolute pleasure to use, and I especially like that you can be pragmatic about it; if there is something that is annoying to do in Elm then you can simply drop into Javascript/Typescript using ports.

Coming from languages like Actionscript/Javascript/Typescript/PHP I have found the whole Elm experience quite mindblowing; if it compiles, then it just seems to work. I hardly ever find myself poring over bits of code trying to debug a subtle error, and if I do the problem is going to be in the Javascript/Typescript bit.

Basically, I'm sold :)

SEEKING FREELANCER(s) - remote only

Davex Global is looking to expand its roster of remote freelancers. Right now we are looking for super-duper HTML/jQuery/CSS/Bootstrap frontend devs and PHP/CodeIgnitor/MySQL backend devs.

If this sounds like you register at http://www.davexglobal.com/registration/

bpm (http://www.getbpm.org/) works with Amber and compiles multiple Javascript, SCSS and Coffeescript into a single JS and CSS file. It also has a mode where it does it in realtime for development use.