[elm-discuss] Re: Elm feasibility for large, complex desktop browser application with dependencies on many newer web APIs
> My experience has been that the complexity of managing all those moving parts could be greater than the benefits of using Elm. > It it were my project, I would probably just leave things as is and squash as many bugs as you can until things stabilize a bit. > But if you are considering a total re-write - maybe try it with Elm? Yeah that sounds like a totally reasonable strategy. I would say that the largest number of bugs have stemmed from inconsistent platform API behavior across browsers. I really like the idea with Elm of building robustness to things like random, buggy IE behaviors. The codebase has definitely outgrown its original architecture so I'm definitely interested in a full rewrite -- I just want to make sure that the frontend language we choose will scale to address many of the issues the previous iteration ran into out in the wild. > (By the way, I have used pdfjs in an Elm project through ports and it worked just fine.) That's awesome! Is that open source? On Wednesday, October 11, 2017 at 9:27:24 AM UTC-7, Rex van der Spuy wrote: > > > Does anyone have experiences to share around using Elm in the context of a >> great number of complex platform and js dependencies? How involved would it >> be to abstract these non-elm dependencies behind ports? Is there a tool >> analogous to caniuse.com that would let me easily figure out which >> platform APIs have already been packaged up nicely for elm usage? >> > > My experience has been that the complexity of managing all those moving > parts could be greater than the benefits of using Elm. > It it were my project, I would probably just leave things as is and squash > as many bugs as you can until things stabilize a bit. > But if you are considering a total re-write - maybe try it with Elm? > > (By the way, I have used pdfjs in an Elm project through ports and it > worked just fine.) > -- 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.
[elm-discuss] Re: Elm feasibility for large, complex desktop browser application with dependencies on many newer web APIs
Yeah I think that could be a great middle ground (keeping around all of the previous js plumbing that wires up the big libraries and newer platform APIs and then exposing js methods to interact with these bits through the elm ports). My main hesitation there is that the core react & redux components and state management haven't been big sources of bugs out in the wild. Much more often there's a wrapper around a browser API or big js library that doesn't handle all of the less common & error modes. I think I have to think more deeply about how much robustness to weird platform behavior (for instance in older browsers) having the application core live in Elm would buy us. On Wednesday, October 11, 2017 at 2:33:00 PM UTC-7, Rupert Smith wrote: > > On Tuesday, October 10, 2017 at 8:55:44 PM UTC+1, Gareth Ari Aye wrote: >> >> * react and redux for managing components and application state >> > > This is the part that is most like Elm, so you might consider porting that > to Elm first? > -- 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.
[elm-discuss] Re: Elm feasibility for large, complex desktop browser application with dependencies on many newer web APIs
Awesome! I'll play around with elm-ace a bit. At first glance it's not 100% clear to me why autocomplete would be challenging for interop but will update here as I learn more. Thanks! On Tuesday, October 10, 2017 at 2:53:40 PM UTC-7, Roman Frołow wrote: > > Hi. > > Regarding ace-editor/text editor: > > 1. If you want to have autocomplete like this > https://github.com/DenisKolodin/elm-ace/issues/5#issuecomment-302318469 > > use polymer version > https://github.com/LostInBrittany/ace-widget/blob/master/demo/index.html. > > 2. Intergration with CodeMirror from ellie-app > https://github.com/lukewestby/ellie/tree/master/client/src/Ellie/CodeMirror > . > > 3. Rich text editor built using Content Editable https://www.rexpad.com/ > but not open sourced > https://www.reddit.com/r/elm/comments/72cm1r/what_are_you_working_on_this_week_week_of_20170925/dnj3hbk/ > > Be aware of some drawbacks, though > https://www.reddit.com/r/elm/comments/6scicd/what_are_elm_pitfalls/ > > Cheers, > Roman > -- 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.
[elm-discuss] Re: Elm feasibility for large, complex desktop browser application with dependencies on many newer web APIs
On Tuesday, October 10, 2017 at 8:55:44 PM UTC+1, Gareth Ari Aye wrote: > > * react and redux for managing components and application state > This is the part that is most like Elm, so you might consider porting that to Elm first? -- 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.
[elm-discuss] Re: Elm feasibility for large, complex desktop browser application with dependencies on many newer web APIs
> Does anyone have experiences to share around using Elm in the context of a > great number of complex platform and js dependencies? How involved would it > be to abstract these non-elm dependencies behind ports? Is there a tool > analogous to caniuse.com that would let me easily figure out which > platform APIs have already been packaged up nicely for elm usage? > My experience has been that the complexity of managing all those moving parts could be greater than the benefits of using Elm. It it were my project, I would probably just leave things as is and squash as many bugs as you can until things stabilize a bit. But if you are considering a total re-write - maybe try it with Elm? (By the way, I have used pdfjs in an Elm project through ports and it worked just fine.) -- 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.
[elm-discuss] Re: Elm feasibility for large, complex desktop browser application with dependencies on many newer web APIs
Hi. Regarding ace-editor/text editor: 1. If you want to have autocomplete like this https://github.com/DenisKolodin/elm-ace/issues/5#issuecomment-302318469 use polymer version https://github.com/LostInBrittany/ace-widget/blob/master/demo/index.html. 2. Intergration with CodeMirror from ellie-app https://github.com/lukewestby/ellie/tree/master/client/src/Ellie/CodeMirror. 3. Rich text editor built using Content Editable https://www.rexpad.com/ but not open sourced https://www.reddit.com/r/elm/comments/72cm1r/what_are_you_working_on_this_week_week_of_20170925/dnj3hbk/ Be aware of some drawbacks, though https://www.reddit.com/r/elm/comments/6scicd/what_are_elm_pitfalls/ Cheers, Roman -- 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.
