TodoMVC in Elm is 21kb (minified & gzip) ;)

On Tue, Jul 12, 2016 at 9:29 AM, Yosuke Torii <[email protected]> wrote:

> Sorry, please let me adjust my previous comment.
>
> I said React+Elm is too large, but now I found it's NOT so large as I
> thought.
> (Of course not as small as lightweight libraries yet)
>
> I just saw the number at TodoMVC.
>
> elm.js: 69.7 KB gziped
> (including all user code)
>
> react-with-addons.js: 174 KB gziped
>
> jquery.js: 83.9 KB gziped
>
> I'm surprised the fact Elm is even smaller than jQuery.
> It means React+Elm is smaller than React+jQuery.
> Considering it's temporary to use them together, this number is not too
> bad, I think.
>
>
> 2016-07-11 3:37 GMT+09:00 Richard Feldman <[email protected]>:
>
>> It's all good. :)
>>
>> This stuff is complicated!
>>
>> On Sun, Jul 10, 2016, 11:19 AM Peter Damoc <[email protected]> wrote:
>>
>>> Richard,
>>>
>>> Thank you for taking the time to write this considerate answer.
>>>
>>> I apologize for the post I wrote yesterday.
>>> I was in a very very dark place after a night plagued by insomnia at the
>>> end of an extremely stressful week where I could not get anything done.
>>>
>>> Fear is the path to the dark side... and I think I let fear take over.
>>>
>>> Anyway, it is fascinating to see that such a seemingly simple topic has
>>> the brightest minds in the world still looking for an answer.
>>>
>>> I did not knew that the situation is this complicated.
>>>
>>>
>>>
>>>
>>> On Sun, Jul 10, 2016 at 8:54 PM, Richard Feldman <
>>> [email protected]> wrote:
>>>
>>>>
>>>>
>>>>> Regarding the user form, you said that what I asked is trivial in Elm.
>>>>> Do you have some kind of sample code that you can share or, if you
>>>>> would be so kind, could you post some sample repository that does that?
>>>>>
>>>> I would *LOVE* to be proven wrong about that. I would love to see some
>>>>> simple Elm code that outputs a form that looks like it came from 2016 and
>>>>> go "oops, my bad, sorry for wasting everyone's time".
>>>>>
>>>>
>>>> Sure - I even wrote a blog post
>>>> <http://tech.noredink.com/post/129641182738/building-a-live-validated-signup-form-in-elm>
>>>>  about
>>>> it. :)
>>>>
>>>> That post includes examples in the form of SignupForm.elm
>>>> <https://gist.github.com/rtfeldman/ba60ad491cc6b58fe2cc4ca78f5a4580>
>>>>  and the styles that go with it
>>>> <https://gist.github.com/rtfeldman/4ec263490ba9a1618b59#file-example-html-L7-L16>.
>>>>  I
>>>> didn't bother inline the styles into Elm, but obviously that's a copy/paste
>>>> and find/replace job.
>>>>
>>>> All of Graphics.Input was dropped
>>>>
>>>>
>>>> Ah, I did not know that! My mistake. You're right, Janis.
>>>>
>>>> Regarding elm-mdl. I am well aware of the release of 6.0.0. I was not
>>>>> arguing that people are not still fighting.
>>>>> What I said was that "*they were explicitly or implicitly dismissed"*
>>>>> .
>>>>>
>>>> If you want me to be more explicit, I was thinking about the
>>>>> discussions around boilerplate that prompted elm-parts, the difficulties
>>>>> around geometry that prompted debois/elm-dom.
>>>>>
>>>>
>>>> Facebook released React with a built-in, dead-easy way to do reusable
>>>> stateful components: each component has its own local mutable state.
>>>>
>>>> However, they at Facebook weren't satisfied with how this UX scaled, so
>>>> they also released Flux as a more scalable way to manage state.
>>>>
>>>> Many people weren't happy with Flux, though, so they started looking
>>>> elsewhere, for example to ClojureScript, leading to Omniscient.js
>>>> <https://github.com/omniscientjs/omniscient> based on David Nolen's
>>>> cursor-based state management model for Om
>>>> <https://github.com/omcljs/om>.
>>>>
>>>> David Nolen himself ended up moving away from that with Om Next
>>>> <https://github.com/omcljs/om/wiki/Quick-Start-(om.next)>, which
>>>> abandoned cursors in favor of a custom state management system based on
>>>> Relay, Falcor, and Datomic. Obviously not everyone agrees with him;
>>>> Omniscient.js is still under active development. Its last commit is 2 days
>>>> ago.
>>>>
>>>> Others looked to Elm, like Dan Abramov, who created Redux
>>>> <https://github.com/reactjs/redux>. It's very popular in the React
>>>> world, although since Facebook hired Dan, he's been working on ways to make
>>>> React not need it anymore. That seems likely to result in the release of a
>>>> new way to do things <https://xkcd.com/927/>, whenever whatever it is
>>>> gets released.
>>>>
>>>> Others thought Redux was too heavyweight and trying to do too much at
>>>> once, which has led to Choo
>>>> <https://github.com/yoshuawuyts/choo#concepts>, a self-described
>>>> <https://github.com/yoshuawuyts/choo#hey-doesnt-this-look-a-lot-like-elm>
>>>> adaptation of Elm 0.17's architecture in JS.
>>>>
>>>> I've spent hours discussing these things with Jafar Husain at Netflix,
>>>> who thinks Observables are the answer. See for example rx-react
>>>> <https://github.com/fdecampredon/rx-react> or Andre Staltz's popular
>>>> Cycle.js <http://cycle.js.org/>.
>>>>
>>>> This is to say nothing of how Angular manages state. Or Ember. Or
>>>> Aurelia. Or Vue.
>>>>
>>>> My point is this:
>>>>
>>>> *Every single community that's involved in making browser-based UIs is
>>>> flooded with conflicting viewpoints on how reusable stateful components
>>>> should be done.*
>>>>
>>>> There is not some glaringly obvious answer that will make everyone
>>>> happy. It does not exist.
>>>>
>>>> History strongly suggests that in this area,* making one group of
>>>> people happy makes others unhappy.*
>>>>
>>>> I was on a Skype call several months ago where Søren and Evan had an
>>>> extended discussion about his experiences developing elm-mdl. The fact that
>>>> Evan did not end up doing things the way you think he should is not a
>>>> reflection of Evan being dismissive of Søren's experience, it's that 
>>>> *reusable
>>>> stateful components are a minefield of tradeoffs*.
>>>>
>>>> Personally I think when one finds oneself in a minefield, it is wise to
>>>> tread carefully. :)
>>>>
>>>>> --
>>>>
>>> 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.
>>>>
>>>
>>> --
>>> There is NO FATE, we are the creators.
>>> blog: http://damoc.ro/
>>>
>>> --
>>> 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/gVY5DmZOR9s/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 a topic in the
>> Google Groups "Elm Discuss" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/elm-discuss/gVY5DmZOR9s/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.
>



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

Reply via email to