Clarify "Elm-UI uses stuff that are not allowed in the official repository"

[ivanov]

Since Elm-UI uses stuff that are not allowed in the official repository you cannot installed it via the default method

When I came across that phrase on the front page of the docs, it sounded pretty serious and ominous and I became nervous and had a bunch of questions: Is it for legal or licensing reasons? philosophical? technical? Some combination of those?

It seems #24 has more context about this, so perhaps just link that phrase to #24 as a start.

[gdotdesign]

Thanks for bringing this up! 👍

You are probably right, although #24 is pretty outdated. The only reason it's not listed is because it contains Native modules. I'll try to rephrase it to be more welcoming.

[silaspedrosa]

This is a very important matter for the sake of the library. In my case, I thought a lot about this before starting to use elm-ui. Personally, I see it as a drawback when I'm considering different possibilities for an UI framework.

I'm sure Elm UI must have a lot of good reason for using native modules, but is there a chance of separating these things? I mean we could have a "clean" Elm UI living in the official repositories and an "extensions" package for the cool stuff in the non-official repositories.

From my point of view, Elm is taking up speed and consolidating among web developers, but it's still in the beginning of the journey. Any drawback can draw away developers and slow down the growth of this project.

What do you think about this, @gdotdesign ?

[gdotdesign]

I'm going to explain here what each native module / effect manager / external package (which is not allowed officially) does, why Elm-UI is using it to give you a better idea:

Native Modules:

• Native.Styles - it's just 60 lines of code that injects / removes CSS rules when needed, can be replaced by injecting all the rules into the document by hand
• Native.DateTime - provides methods for manipulating JS dates - probably could be replaced, but there is no equivalent to create function in any of the possible packages
• Native.Env - not needed it's just a helper
• Native.Number - used by Ext.Color - probably could be replaced
• Native.FileManager - used by Ui.FileInput to load and read files, provides a way to do file uploads and wraps download.js - can't be replaced at this point
• Native.Uid - this one is a bigger issue, this module is used to generate unique id for components, can be replaced by an Elm random generator but it would make it cumbersome to initialize components because the seed would needed to be passed around the place

External Native Packages:

• elm-dom - this is again a blocker, it is needed for the drop-down (getBoundingClientRect) and to set value of inputs without using the value attribute (which is buggy at the moment)
• elm-spec - it is used for testing the components in an integration way (Elm-UI has a really good coverage)

Effect managers (pure Elm):

• Ui.Helpers.PeriodicUpdate - Allows to subscribe to a "tick" (every 5 secords). Used by Ui.Time to update itself
• Ui.Helpers.Scrolls - Allows to subscribe to the global scroll event. Used by drop-downs to hide themself after a scroll.
• Ui.Helpers.Emitter - Allows simple pub / sub using string channels, used by most components to broadcast changes (onChange subscriptions)

So as you can see removing them would leave a couple of mostly static components which could be published on package.elm-lang.org but using them would be more difficult and I think there is no point in doing so.

It's not a coincidence that there are no good looking / beautiful / UX heavy Elm applications out there. The fundamental APIs are missing and probably they will be done at some point in the next few years if ever.

Writing this made me realize that I could do a blog post about this, which I'll probably do, it would help make Elm-UI more accessible.

I hope this comment clarify things.

[silaspedrosa]

So good explanation! Thanks a lot!
I totally agree on the blog post, please do it!

Yeah, I see your point, now it's pretty obvious how these native modules support the whole architecture of Elm-UI. I wonder how elm-bootstrap and elm-mdl survive without these native modules. I haven't used them yet, I'm planning on testing them soon.

Anyway, I'll leave my opinion that the fact elm ui is not in the official repository will draw away lots of people. Unfortunately, separating it in two projects as I suggested is not trivial at all. As I don't have the time to try to work on this for now, I'll just hope elm ui keeps improving and this fact doesn't harm us and doesn't frighten new people.

Thanks once again, @gdotdesign ! Magnificent job is being done here!

[gdotdesign]

Thanks for the kind words! 😉

Just to reflect on this:

I wonder how elm-bootstrap and elm-mdl survive without these native modules.

1. both of them have CSS that they can use so that's something they don't have to deal with
2. most of the components they have are static or have little business logic, for example a drop-down positioning: for them it's static, opens down all the time even if it hidden, in Elm-UI it's dynamic it opens in where there are enough space
3. they use workarounds for some of the missing APIs, for example http://package.elm-lang.org/packages/debois/elm-dom/1.2.3 which are cumbersome to use