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 <[email protected]> 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 > [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
