# Getting rid of ports modules
**URL:** https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829
**Category:** Request Feedback
**Created:** [March 11, 2018, 8:03am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829 "2018-03-11T08:03:33Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 11, 2018, 8:03am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/1 "2018-03-11T08:03:33Z")
We don’t really need ports modules.
Communication to and from JS can be handled by an `output : Value -> Cmd msg` function and a new program type with a field like `input : Decoder msg`.
On the JS side, instead of `app.ports.portName` there can simply be `app.subscribe` and `app.send`.
Getting rid of ports modules would simplify the syntax and would get rid issues like [this one](https://github.com/elm-lang/elm-compiler/issues/1450).
What do you think about this idea?
---
### Author:  [@simonh1000](https://discourse.elm-lang.org/u/simonh1000)
#### Post date: [March 11, 2018, 9:14am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/2 "2018-03-11T09:14:29Z")
I can’t judge for certain what the compiler could cope with, but some sort of specific indication that you are branching into js seems helpful in general.
What interests me in this area is when it will be possible to distribute code using ports via packages.elm-lang. Given the mantra of ‘use ports, use ports,…’ we need to make it possible to use them in a re-usable way
---
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 11, 2018, 9:19am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/3 "2018-03-11T09:19:13Z")
> [@simonh1000](#):
>
> What interests me in this area is when it will be possible to distribute code using ports via packages.elm-lang.
If we get rid of ports, we also get rid of the restriction on using ports with the [packages.elm-lang.org](http://packages.elm-lang.org) 🙂 (there will no longer be ports modules that would prevent the package from being published)
---
### Author:  [@opvasger](https://discourse.elm-lang.org/u/opvasger)
#### Post date: [March 11, 2018, 11:53am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/4 "2018-03-11T11:53:01Z")
Seems quite a bit simpler, and for me, this is pretty much how I’m already doing it. Didn’t Murphy do an Elm-conf talk advicing the same pattern?
---
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 11, 2018, 11:55am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/5 "2018-03-11T11:55:54Z")
> [@opvasger](#):
>
> Seems quite a bit simpler, and for me, this is pretty much how I’m already doing it. Didn’t Murphy do an Elm-conf talk advicing the same pattern?
Yes, it is very much aligned with what Murphy presented at elm-conf.
---
### Author:  [@runarfu](https://discourse.elm-lang.org/u/runarfu)
#### Post date: [March 12, 2018, 8:30am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/7 "2018-03-12T08:30:49Z")
In the future Elm might target something other than JavaScript (like WebAssembly), and if all published Elm packages are written purely in Elm, this gets a lot easier. I also think it’s a good thing that all the packages I use are written purely in Elm, as that gives a lot of nice compile time guarantees. I can see your motivation, but I believe this issue will decrease as the number of published Elm packages increases.
---
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 12, 2018, 8:35am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/8 "2018-03-12T08:35:47Z")
> [@runarfu](#):
>
> I can see your motivation, but I believe this issue will decrease as the number of published Elm packages increases.
What is “this issue” that you mention here?
I’m confused on how getting rid of ports modules is affected by the number of Elm packages.
---
### Author:  [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [March 12, 2018, 9:50am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/9 "2018-03-12T09:50:07Z")
> [@pdamoc](#):
>
> If we get rid of ports, we also get rid of the restriction on using ports with the [packages.elm-lang.org](http://packages.elm-lang.org) 🙂 (there will no longer be ports modules that would prevent the package from being published)
The trouble is, I would download you package and find that it did not work because I need to also install its port driver. If the port driver were also downloaded automatically, it is the same thing as a free for all on native code, and then the Elm platform will grow in an uncontrolled way and the user experience may suffer.
---
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 12, 2018, 10:30am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/10 "2018-03-12T10:30:45Z")
> [@rupert](#):
>
> The trouble is, I would download you package and find that it did not work because I need to also install its port driver.
The proposed idea here is not tied to the `elm-ports-driver`. It is simply a proposal that would simplify the language and eliminate a class of issues. It is also aligned with the way some people already do the ports code.
Sure, it would simplify the `elm-ports-driver` project too (on both sides) but that’s an added benefit.
> [@rupert](#):
>
> If the port driver were also downloaded automatically, it is the same thing as a free for all on native code, and then the Elm platform will grow in an uncontrolled way and the user experience may suffer.
I’m not arguing here for automatic downloads of JS code. A project like `elm-ports-driver` that could automate some of the things the currently are done with ports cannot be compared with Native because it is outside of the Elm code. You cannot use such a project to break the guarantees of Elm. Also, changes in the Kernel code do not affect in any way a project like this. Even moving the entire Kernel to something like WebAssembly would still not affect a project like this because it is entirely decoupled from Elm compiled code by the ports.
---
### Author:  [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [March 12, 2018, 10:33am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/11 "2018-03-12T10:33:58Z")
> [@pdamoc](#):
>
> The proposed idea here is not tied to the elm-ports-driver. It is simply a proposal that would simplify the language and eliminate a class of issues. It is also aligned with the way some people already do the ports code.
Ok, I did not necessarily mean your `elm-ports-drive project`; I would still have to install the .js code for the port myself, and that would mean that the package is broken out-of-the-box.
---
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 12, 2018, 10:43am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/12 "2018-03-12T10:43:22Z")
> [@rupert](#):
>
> Ok, I did not necessarily mean your elm-ports-drive project; I would still have to install the .js code for the port myself, and that would mean that the package is broken out-of-the-box.
I don’t see that as _broken out-of-the-box_. Just because something requires you to have an extra step it does not mean that is _broken out-of-the-box_. `elm-mdl` behaves like this instructing its users to install the needed MDL css file in the output. I don’t think `elm-mdl` is _broken out-of-the-box_.
---
### Author:  [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [March 12, 2018, 2:30pm UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/13 "2018-03-12T14:30:41Z")
I also think that not allowing ports to be published encourages new solutions to be developed purely in Elm, versus just wrapping some .js library. If I am not mistaken, I think Richard said that in 0.19 there is only going to be 1 wrapped .js library left, and that will be evancz/elm-markdown. (Presumably because the documentation sites depend on it.)
I suppose our points of view are kind of academic anyway, as Even seems to have made his preferred direction of travel clear. I’m ok to sail with the good ship Elm.
---
### Author:  [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [March 12, 2018, 2:31pm UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/14 "2018-03-12T14:31:26Z")
> [@pdamoc](#):
>
> elm-mdl behaves like this instructing its users to install the needed MDL css file in the output. I don’t think elm-mdl is broken out-of-the-box.
Better if all the MDL css was done purely in Elm?
---
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 12, 2018, 3:31pm UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/15 "2018-03-12T15:31:57Z")
> [@rupert](#):
>
> I suppose our points of view are kind of academic anyway, as Even seems to have made his preferred direction of travel clear. I’m ok to sail with the good ship Elm.
I’m confused. Your comment makes it sound like I’m proposing something contrary to what Elm currently has.
As far as I see it, what I propose is equivalent of what we have now but with less special syntax and less issues.
---
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 12, 2018, 3:34pm UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/16 "2018-03-12T15:34:39Z")
> [@rupert](#):
>
> Better if all the MDL css was done purely in Elm?
Sure thing but I still don’t see it as broken.
---
### Author:  [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [March 12, 2018, 3:51pm UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/17 "2018-03-12T15:51:25Z")
> [@pdamoc](#):
>
> I’m confused. Your comment makes it sound like I’m proposing something contrary to what Elm currently has.
In which case I may be mis-understanding you.
Is your thinking along these lines: If there is just one `input` function and one `output`, there is no need to define any more ports than these. All we need is a Program type with `input` and `output` in it, and since these never change they might as well be allowed to be published.
Most likely instances of this Program type would not be published to the packages site anyway, as we do not have a way to compose Programs?
---
### Author:  [@loganmac](https://discourse.elm-lang.org/u/loganmac)
#### Post date: [March 12, 2018, 4:09pm UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/18 "2018-03-12T16:09:43Z")
I think that’s exactly where this should go. Make `input` and `output` ports as a part of `Html.Program` types, and then it’s a part of the application, and not libraries that would be published. It makes total sense since ports are an application (and not a library) concern.
---
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 12, 2018, 4:24pm UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/19 "2018-03-12T16:24:03Z")
> [@rupert](#):
>
> All we need is a Program type with input and output in it, and since these never change they might as well be allowed to be published.
Yes, I’m arguing for providing a way to define Programs that have these facilities included. As I said, the special ports syntax can be dropped by replacing it with a `output: Value -> Cmd` function and a special program that can take a decoder. Alternatively, the input can be `input : (Value -> msg) -> Sub msg` but I would prefer the decoder variant because the subscription variant enforces the use of a `NoOp` msg.
Allowing ports on [package.elm-lang.org](http://package.elm-lang.org) is a recipe for troubles similar to the one described in [this issue](https://github.com/elm-lang/elm-compiler/issues/1450).
I don’t see how getting rid of ports would create problems that are impossible with the current policy. I would however be interested in learning about such problems.
> [@rupert](#):
>
> Most likely instances of this Program type would not be published to the packages site anyway, as we do not have a way to compose Programs?
I do not see why someone would want to publish an instance of a program like this. It would be useless from inside Elm. In any case, I think `0.19` will make a difference between `application` and `package` and I’m perfectly fine with banning `Program` altho I don’t see the point.
---
### Author:  [@ram9cc](https://discourse.elm-lang.org/u/ram9cc)
#### Post date: [March 16, 2018, 3:44am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/20 "2018-03-16T03:44:48Z")
I actually feel like elm-mdl is broken out of the box. I would have liked to know before hand - I like having ports for being pragmatic in production code - however I really don’t want other people’s javascript as a dependency - that’s why would use elm - it is not JavaScript.
---
### Author:  [@pdamoc](https://discourse.elm-lang.org/u/pdamoc)
#### Post date: [March 16, 2018, 6:46am UTC](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829/21 "2018-03-16T06:46:36Z")
> [@ram9cc](#):
>
> I like having ports for being pragmatic in production code - however I really don’t want other people’s javascript as a dependency - that’s why would use elm - it is not JavaScript.
My experience with JavaScript is quite limited. I actually want other people’s JavaScript when this cannot be avoided. I would prefer to code in Elm but if Elm cannot do something and I need to use the ports, I would prefer to have on the other side something that a person with much more JavaScript experience than me wrote.
[Next page](https://discourse.elm-lang.org/t/getting-rid-of-ports-modules/829.md?page=2)