I agree Wouter, a lot has gone into optimising CSS animation in browsers, rebuilding those wheels in a compile-to-JS language seems somewhat redundant.
Again I think it depends on your background. If you are experienced with working in CSS, retooling and reskilling (CSS and JS can often be the concern of different people in a team) to do it all a different way when all you really want to do is improve the JS layer could seem like a drawback rather than a plus. On the other hand, if you don't have a particularly large legacy of CSS work, handling everything in one language probably makes more sense. On Wed, Jun 8, 2016 at 7:07 AM, Wouter In t Velt <wouter.intv...@gmail.com> wrote: > Really interesting discussion and viewpoints. As newcomer and hobbyist in > the elm arena, some may think this naive, but I find the principle to > separate concerns very appealing. > Meaning (simply put) the DOM (html) is for the component structure, CSS is > for layout, and JavaScript is for interaction. > IMHO, the fuzziness we have to deal with is because each of the 3 building > blocks is lacking features that we need. > Which is why so many web apps/ sites end up with messy DOM trees with > loads of unwanted div layers, and messy Jquery as a band-aid for styling > deficiencies. > > In learning elm (coming from react), I really like the functional and pure > aspects of it. > But I really wish I would be able to keep styling and transitions for > state changes separate, preferably with styling in CSS stylesheets. > > Especially for transitions. > > I try to have my elm code render only twice, and let CSS would take care > of transition. Seperates concerns, and keeps code clean. Is the right class > applied in state 1? And in state 2? Then elm is fine. Layout and transition > wrong? Must be CSS. > Adding a subscription in elm to every single of 500 animation frames + > extending model to not only save state but also all > in-between-two-discrete-states information, feels like an unwanted > complication and mixture of concerns. > > I see benefits of DOM + styling + interaction mix in components (reminds > me of Polymer). > And I dislike the cascading aspect (and other shortcomings) of pure CSS, > and it is hard to switch back and forth between elm and CSS mindset. > Not sure of I can keep transitions from blending, and the will definitely > investigate elm CSS solutions mentioned. > > But for now, I still believe code will be cleaner and more maintainable as > it grows, if one persists to separate the styling on the one hand from the > content and interaction in the other. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Elm Discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elm-discuss/AC6cqdeKDOs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > elm-discuss+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
