How to convince your boss to start using Elm in the company

[Mats Stijlaart]

Hi folks,

As a developer I am convinced that I want to build my front-end software with Elm, but I need some arguments to convince my boss. 

In my company a piece of front-end has to be rebuild and extended with a new front-end technology (currently Java JSP). I have already convinced my colleagues by rebuilding a single page in Elm. They are really enthusiastic, but I still have to convince my boss that it is the 'right' choice. In 2013 a part of the platform was rewritten in Angular 1.X. Angular 1.X will soon to be legacy technology when it is replaced with 2.0. My boss' concern is that within three years we will go through the same choice for a new technology, and he has to face the customer telling them that we have/want to rebuild the existing fronted to eliminate legacy code.

So, I have to convince my boss that from a business perspective it is a wise choice to put his money on Elm. One of the main questions to be answered is: is Elm going to be around tomorrow?

Does anybody have some good arguments/strong opinions why we should or should not adopt Elm as front-end language from a business perspective? Or what arguments did you use to convince your boss? 

Thanks,

Mats

[Peter Damoc]

Evan works at NoRedInk which has a huge stake in Elm being around and being awesome.
I would bet that Elm will be around tomorrow. 

Regarding convincing your boss, the main use case scenario for an Elm app is something that is highly complex and that needs to go. Elm is designed for code evolution into something of increasing complexity. 
The way Elm approached this is with a sound architecture that isolates the complexity within tightly controlled borders and leaves the main bulk of the code being simple functions and data structures. 


That being said, there is a price to be paid. 

Elm is still very young. 

The language evolves and some pieces of code can become obsolete faster. 
Documentation is scarce and with the move to 0.17 a lot of the old 3rd party tutorials have become unusable. 

You might also have some trouble finding extra developers if you want to expand.

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

There is NO FATE, we are the creators.
blog: http://damoc.ro/

[Charlie Koster]

I think it's worth pointing out that even though Elm will be here tomorrow, Elm is still evolving. Take as an example the latest release. If you had sold your boss on Elm 0.16 six months ago and then 0.17 comes out with very large changes, what are you going to recommend? Do you recommend that you stick with 0.16 long term? Or do you rip the band-aid, ask for more schedule and money, and convert your Elm 0.16 app to Elm 0.17?

When talking about making a decision from a business perspective we are talking about personnel resources, schedule, and money. Are you able to justify the less-than-1.0 nature of Elm from a business perspective? Are you able to point at the benefits of Elm as outweighing any future risks?

I'm not trying to sway you one way or another. But speaking from my personal work situation I have considered this question and as the on-site Elm expert I don't consider Elm to be Production ready for the specific work that my company does yet. But that doesn't mean it's not ready for the type of work your company does.

[Zachary Kessin]

Thankfully I work for myself, so I only had to convince myself.

I found the upgrades from 0.15 -> 0.16 -> 0.17 were a pain, but less of a pain then the bugs that I would have had to track down with something like angular or ExtJS

This opinion is probably worth what you paid for it :)

Zach

ᐧ

--

You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Zach Kessin

Your CRM Link

Twitter: @zkessin

Skype: zachkessin

[Max Goldstein]

There's an article by Paul Graham, pre-Y-combinator, that may be relevant: http://www.paulgraham.com/avg.html

In my own paraphrasing, the average startup fails. So if you're a startup, you should be seeking out technical risks that you think will pay off. If I was in a startup, especially one lacking in front-end programmers, I think Elm is a strong choice. But the more mature your company is, the more Elm's immaturity should bother you.

That being said, I think that one of Elm's big advantages is that it's small. You can teach a few JS/Ruby/Python devs the stateless parts of the language in an hour, and TEA in another, pair for a few days, and you'll know enough to be dangerous. There's no separate templating language, no routing DSL, and no magic filename munging. Contrast trying to port an Angular 1.x + CoffeScript app to React+JSX+Redux+ES6....

[Rex van der Spuy]

I found the upgrades from 0.15 -> 0.16 -> 0.17 were a pain, but less of a pain then the bugs that I would have had to track down with something like angular or ExtJS

This!!

Elm will save you countless endless hours (days? months?) of nail biting debugging in comparison to using any JS frameworks.

And, you're guaranteed that your spaceship won't blow up 3 months after launch - JS is apps of any complexity are just time bombs waiting to explode.

The devils bargain is that you have to commit to swallowing breaking API changes in the language every 4 to 6 months - for who knows how long.

But, it's worth it!

Implementing those API upgrades to your codebase is far less work than the debugging you would have to do in JS.

In my experience, font end commercial software is pretty much disposable - it rarely has a lifespan of more than 5 years.

The technology it's based on becomes obsolete (um, Flash!), UX fashions change (hourly!), or it just dies from neglect. 

So I would just jump into whatever looks best at the moment and go for it!

...And, the more I've learnt about JavaScript over the past few years, the more I've come to believe that it's actually irresponsible to it use for software development.

 

[Gage Peterson]

Really, although Elm is young and changing its also simple and strong. Here's the argument:

- do you want runtime errors?
- do you want to use something simple or complex? (In a Rich Hickey sense) there strives to be one way to do things. This saves valuable decision time that JavaScript developers are going to have to deal with for the rest of their careers.
- do you want something that is ultra easy to train people on?
- time traveling debugging (eventually)
- no unexpected API changes on library updates?
- far easier to test?
- etc...

Then you want elm.

I think the first point alone is worth it. You could even try measuring how many errors you have in your current JavaScript code base as a good metric.