Discussion:
[elm-discuss] Elm feasibility for large, complex desktop browser application with dependencies on many newer web APIs
Gareth Ari Aye
2017-10-10 19:06:00 UTC
Permalink
Hi Elm Discuss!

My name is Ari and I'm a graduate student in ML at Columbia University.
Last year I created https://latexbase.com to make it easier for students
like me to experiment with LaTeX. As far as applications that run in the
browser go, LaTeX Base is quite complex (and 95% of the complexity lives
client-side). For example, it uses

* emscripten to cross-compile a native LaTeX-to-pdf typesetter to asm.js
* web workers to decouple LaTeX compilation from the main ui thread
* service workers to power offline editing
* ace editor for source editing
* pdfjs for pdf rendering
* react and redux for managing components and application state
* browser APIs such as TypedArray and TextDecoder for handling binary data
for file uploads, downloads, cloud sync, etc
* localForage to persist some application data client-side

LaTeX Base now has a much larger userbase than I anticipated and I'm
looking to improve user experience by reducing the number of crashes and js
bugs users run into out in the wild. Elm seems like a great choice, but I'm
concerned about the js interop story since LaTeX Base has so many hard
dependencies on newer platform APIs and large js libraries (like ace,
pdfjs, and localForage).

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?

Normally I would just start coding and see where I get but came across
Evan's talk from Elm conf last year that suggested elm-discuss as a
starting point :). Would appreciate hearing any suggestions or tips you all
have to share.

Best,
Ari
@lambdabaa <https://twitter.com/lambdabaa>
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Roman Frołow
2017-10-10 21:53:39 UTC
Permalink
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Gareth Ari Aye
2017-10-16 04:54:34 UTC
Permalink
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!
Hi.
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rex van der Spuy
2017-10-11 16:27:24 UTC
Permalink
Post by Gareth Ari Aye
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Gareth Ari Aye
2017-10-16 05:08:08 UTC
Permalink
Post by Rex van der Spuy
My experience has been that the complexity of managing all those moving
parts could be greater than the benefits of using Elm.
Post by Rex van der Spuy
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.
Post by Rex van der Spuy
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.
Post by Rex van der Spuy
(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?
Post by Rex van der Spuy
Does anyone have experiences to share around using Elm in the context of a
Post by Gareth Ari Aye
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
'Rupert Smith' via Elm Discuss
2017-10-11 21:33:00 UTC
Permalink
Post by Gareth Ari Aye
* 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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Gareth Ari Aye
2017-10-16 05:15:38 UTC
Permalink
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.
Post by 'Rupert Smith' via Elm Discuss
Post by Gareth Ari Aye
* 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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...