On Mon, Sep 19, 2016 at 5:28 PM, Noah Hall <enali...@gmail.com> wrote:

> elm-css is a complicated project. It's mostly complicated because of
> _how big css is_. Reimplementing your own is not a reasonable idea for
> getting things done :) A much better idea would've been to do one of:
> 1) fork, add the missing keywords, commit upstream
> 2) fork and add the missing keywords to your local copy
> 3) just use http://package.elm-lang.org/packages/rtfeldman/elm-css/5.
> 0.0/Css#property
> to achieve this without wasting any time messing around.


I do agree that elm-css is complicated.
The dynamic type implementation that was done in order to accommodate the
variety of CSS values got me puzzled and I still don't think I fully
understand it. :)

In hindsight I should have done what you proposed, fork and try to commit
upstream but by the time I got to the point where I realized that, I was
too deep in the whole that I dug for myself. :)
Let this be a lesson for the rest. :)


> Elm hasn't considered this a goal since elm-html has existed. The
> graphics library allowed you to forego CSS. Nobody uses the graphics
> library in production (though many in academia (did)do, that's what I
> did)
>

I know, I know... but I kept hoping for an elm-html based equivalent.


> > - I would not recommend webdev beginners to take the approach I took. It
> is
> > better for now to stay the tried and proven path and just use Elm to
> > implement smaller components in another web framework.
>
> There isn't any reasoning here other than you tried to re-invent the
> wheel a few too many times. I would also recommend to those trying to
> solve a production problem to do the same ;). I would agree though,
> that if you are intended to rely on the existing JS/CSS libraries out
> there, you are probably better off investing time in making Elm part
> of your site, not making Elm your whole site. You will spend too much
> time like this otherwise
>
>
The reliance on existing JS/CSS components is actually the main reason I
said this might not be the best route for beginners.
Of course, if one does not need such complex widgets, Elm is fine.
The main thing here from my experience is that if one starts without
thinking that they need the JS components and then they discover that they
do, these JS components are not trivial to embed in Elm generated UI.



> > - The tooling around producing a deliverable elm webapp are simply not
> ready
> > yet.
>
> You haven't provided an example of any tooling that "isn't ready yet".
> You said you used gulp and there were no issues there. What were these
> problems?


There are tools available but when I said that they are not ready I meant
that they are not fully integrated and are not conducive to a fluid
experience.
There is no official documentation on how to do this properly because this
topic has not been fully explored.
There are personal approaches documented in various blogs integrating the
tools that the person is most familiar with.

In the end, people coming to Elm with the issue of deployment are left with
either a solution that they are familiar from some other context or with
picking some random blog.
This is what I ended up doing. Finding a gulp file that could compile elm
code and messing with it until it kinda did what I wanted.



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

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to