Re: [elm-discuss] Web components vs. Native

[Maxwell Gurewitz]

What room are you in in the elmlang slack peter?  Web components elements 
have lifecycle hooks, including hooks which will be fired when the 
component is attached/rendered.

https://www.webcomponents.org/community/articles/introduction-to-custom-elements

They can produce any number of effects in these hooks: throw exceptions, 
trigger alerts, utilize random numbers, make http requests etc.  To 
re-iterate, these effects can cause web components to break the replay 
functionality of elm-debugger, as the web components are repeatedly 
re-rendered.

On Thursday, March 23, 2017 at 4:15:20 AM UTC-7, Peter Damoc wrote:
>
> On Thu, Mar 23, 2017 at 9:33 AM, Maxwell Gurewitz  > wrote:
>
>>
>> > You will be able to use a web component ONLY in the view will be as 
>> pure as it is right now. 
>>
>> Unless I'm misunderstanding you, I'm pretty sure this isn't true.
>>
>
> Wonderful! Maybe you can help me with an exploration. 
> I'm aiming to create a proof of concept where a web-component could be 
> used in such a way that it behaves like a "mutation as service". (I'm 
> hoping to not be able to do it) 
> Please contact me on Slack if you are interested. 
>  
>  
>
>> Any violation of purity that is available to native code is also 
>> available to web components, given that web components can execute 
>> arbitrary js when they render.  That's why we have silly non-presentational 
>> web components like polymer's ajax component 
>> https://github.com/polymerelements/iron-ajax.  
>>
>>
> As per the above, I would love to see a proof of concept that shows this. 
> In JS you have an imperative way of programming and you can do certain 
> things that are just impossible in the Elm world. 
>  
>
>> > Again, I don't think that the use of web components is encouraged. 
>>
>> Why do you feel that way?  My impression is that writing native code is 
>> discouraged (thus the lack of documentation, and Evan's elm-dev posts on 
>> native code etc.) while the use of web components is encouraged (thus 
>> Richard's section on web components in Elm in Action).  
>>
>  
> I have spoken with Richard and this is a very sensible topic as there are 
> potential nasty consequences that might not be obvious from the start. 
> Web components do have their role to play and I'm assuming that Richard 
> might touch on his book on this BUT the topic has not been fully fleshed 
> out. 
>
>
>
> -- 
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Web components vs. Native

[Peter Damoc]

On Thu, Mar 23, 2017 at 9:33 AM, Maxwell Gurewitz 
wrote:

>
> > You will be able to use a web component ONLY in the view will be as pure
> as it is right now.
>
> Unless I'm misunderstanding you, I'm pretty sure this isn't true.
>

Wonderful! Maybe you can help me with an exploration.
I'm aiming to create a proof of concept where a web-component could be used
in such a way that it behaves like a "mutation as service". (I'm hoping to
not be able to do it)
Please contact me on Slack if you are interested.



> Any violation of purity that is available to native code is also available
> to web components, given that web components can execute arbitrary js when
> they render.  That's why we have silly non-presentational web components
> like polymer's ajax component https://github.com/polymerelements/iron-ajax.
>
>
>
As per the above, I would love to see a proof of concept that shows this.
In JS you have an imperative way of programming and you can do certain
things that are just impossible in the Elm world.


> > Again, I don't think that the use of web components is encouraged.
>
> Why do you feel that way?  My impression is that writing native code is
> discouraged (thus the lack of documentation, and Evan's elm-dev posts on
> native code etc.) while the use of web components is encouraged (thus
> Richard's section on web components in Elm in Action).
>

I have spoken with Richard and this is a very sensible topic as there are
potential nasty consequences that might not be obvious from the start.
Web components do have their role to play and I'm assuming that Richard
might touch on his book on this BUT the topic has not been fully fleshed
out.



-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Web components vs. Native

[Maxwell Gurewitz]

Hey Peter,

> You will be able to use a web component ONLY in the view will be as pure 
as it is right now. 

Unless I'm misunderstanding you, I'm pretty sure this isn't true.

Any violation of purity that is available to native code is also available 
to web components, given that web components can execute arbitrary js when 
they render.  That's why we have silly non-presentational web components 
like polymer's ajax component https://github.com/polymerelements/iron-ajax. 
 

> Again, I don't think that the use of web components is encouraged. 

Why do you feel that way?  My impression is that writing native code is 
discouraged (thus the lack of documentation, and Evan's elm-dev posts on 
native code etc.) while the use of web components is encouraged (thus 
Richard's section on web components in Elm in Action).  




On Wednesday, March 22, 2017 at 10:35:18 PM UTC-7, Peter Damoc wrote:
>
> To my understanding there is no promotion of the web components as a 
> standard way of interacting with JS. 
> They are mentioned as a way of encapsulating complex JS that might fail. 
> In other words, one could use some complex widget (like google-maps) and 
> get some functionality into their elm app *fully aware* of the risks 
> involved. 
>
> 1. Type safety:
>
> There is none with web components BUT, you do get a nice border control 
> and black-box encapsulation from the perspective of Elm. 
> It very similar to using ports only that from my perspective, the 
> interaction is nicer. 
>
> 2) Purity guarantees
>
> You will be able to use a web component ONLY in the view will be as pure 
> as it is right now. 
> You will not be able to interrogate the web component, you will have to 
> subscribe to its events just like you subscribe to onClick on a button. 
> This is very different from Native that you can use all over the place.
>  
> 3) Versioning guarantees 
>
> web components are not part of the Elm ecosystem and so, they are not and 
> will never be covered by elm-package. Maybe after we get the ability to 
> describe web-components in pure Elm, you will be able to find 
> web-components in elm-package. 
>
> So if the main motivation for discouraging the use of native is to promote 
>> safety, why encourage the use of web components?
>
>
> Again, I don't think that the use of web components is encouraged. 
> They are only an escape hatch that is available to Elm programmers. 
>
> These being said, I do believe that the mechanism of web-components has a 
> lot to offer to Elm. 
>
> I have played with some prototypes and the experience of writing 
> web-components in Elm is quite lovely. 
> In an ideal world, we don't use  in Elm but rather 
>  becomes an Elm implemented web-component. 
> The web-component standard could be the official way to embed and interact 
> with Elm apps. 
>
>
>
>
>   
>
> On Thu, Mar 23, 2017 at 1:57 AM, Maxwell Gurewitz  > wrote:
>
>> Hi all.  I'm creating this thread to discuss the relative merits of web 
>> components and native code.
>>
>> It's my perception that web components are being promoted within the elm 
>> community as a standard means of javascript interop, while writing native 
>> code is discouraged.  In particular, Richard Feldman has recently added a 
>> section on web components to his book Elm in Action (great book btw, you 
>> should totally buy it!), and I'd love to get his feedback.
>>
>> I don't understand this preference for web components over native code.  
>> As far as I can tell web components and native code lack all of the same 
>> safety guarantees.
>>
>> 1) Type safety:
>>
>> Both native code, and js inside of custom web components have the 
>> potential to raise exceptions, or produce invalid results due to a lack of 
>> type safety.
>>
>> 2) Non-determinacy:
>>
>> Both native code and js inside of custom web components have the 
>> potential to introduce non-determinacy.  You can imagine that the google 
>> maps web component might receive a 500 status response from google during 
>> an outage, or the author of the component might simply include a 
>> Math.random.  This will violate the guarantees made by the elm-debugger 
>> which disables port code from running for exactly this reason, which could 
>> prevent you from being able to reliable replay UI interactions.
>>
>> 3) Versioning guarantees:
>>
>> Neither native code nor web components can be published in elm-package, 
>> and they both include javascript, so neither can benefit from elm's semver 
>> enforcement.
>>
>> Now I understand that web components may be more ergonomic than 
>> equivalent native code in certain situations e.g. in the google maps case, 
>> but they don't seem any more or less safe than native code.  Furthermore, 
>> they impose the cost of an additional build system (bower) and polyfills.
>>
>> So if the main motivation for discouraging the use of native is to 
>> promote safety, why encourage the use of web components?
>>
>> Thanks.
>>
>> -- 
>> 

Re: [elm-discuss] Web components vs. Native

[Peter Damoc]

To my understanding there is no promotion of the web components as a
standard way of interacting with JS.
They are mentioned as a way of encapsulating complex JS that might fail.
In other words, one could use some complex widget (like google-maps) and
get some functionality into their elm app *fully aware* of the risks
involved.

1. Type safety:

There is none with web components BUT, you do get a nice border control and
black-box encapsulation from the perspective of Elm.
It very similar to using ports only that from my perspective, the
interaction is nicer.

2) Purity guarantees

You will be able to use a web component ONLY in the view will be as pure as
it is right now.
You will not be able to interrogate the web component, you will have to
subscribe to its events just like you subscribe to onClick on a button.
This is very different from Native that you can use all over the place.

3) Versioning guarantees

web components are not part of the Elm ecosystem and so, they are not and
will never be covered by elm-package. Maybe after we get the ability to
describe web-components in pure Elm, you will be able to find
web-components in elm-package.

So if the main motivation for discouraging the use of native is to promote
> safety, why encourage the use of web components?


Again, I don't think that the use of web components is encouraged.
They are only an escape hatch that is available to Elm programmers.

These being said, I do believe that the mechanism of web-components has a
lot to offer to Elm.

I have played with some prototypes and the experience of writing
web-components in Elm is quite lovely.
In an ideal world, we don't use  in Elm but rather 
becomes an Elm implemented web-component.
The web-component standard could be the official way to embed and interact
with Elm apps.






On Thu, Mar 23, 2017 at 1:57 AM, Maxwell Gurewitz 
wrote:

> Hi all.  I'm creating this thread to discuss the relative merits of web
> components and native code.
>
> It's my perception that web components are being promoted within the elm
> community as a standard means of javascript interop, while writing native
> code is discouraged.  In particular, Richard Feldman has recently added a
> section on web components to his book Elm in Action (great book btw, you
> should totally buy it!), and I'd love to get his feedback.
>
> I don't understand this preference for web components over native code.
> As far as I can tell web components and native code lack all of the same
> safety guarantees.
>
> 1) Type safety:
>
> Both native code, and js inside of custom web components have the
> potential to raise exceptions, or produce invalid results due to a lack of
> type safety.
>
> 2) Non-determinacy:
>
> Both native code and js inside of custom web components have the potential
> to introduce non-determinacy.  You can imagine that the google maps web
> component might receive a 500 status response from google during an outage,
> or the author of the component might simply include a Math.random.  This
> will violate the guarantees made by the elm-debugger which disables port
> code from running for exactly this reason, which could prevent you from
> being able to reliable replay UI interactions.
>
> 3) Versioning guarantees:
>
> Neither native code nor web components can be published in elm-package,
> and they both include javascript, so neither can benefit from elm's semver
> enforcement.
>
> Now I understand that web components may be more ergonomic than equivalent
> native code in certain situations e.g. in the google maps case, but they
> don't seem any more or less safe than native code.  Furthermore, they
> impose the cost of an additional build system (bower) and polyfills.
>
> So if the main motivation for discouraging the use of native is to promote
> safety, why encourage the use of web components?
>
> Thanks.
>
> --
> 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.
>



-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Web components vs. Native

[Maxwell Gurewitz]

Hi all.  I'm creating this thread to discuss the relative merits of web 
components and native code.

It's my perception that web components are being promoted within the elm 
community as a standard means of javascript interop, while writing native 
code is discouraged.  In particular, Richard Feldman has recently added a 
section on web components to his book Elm in Action (great book btw, you 
should totally buy it!), and I'd love to get his feedback.

I don't understand this preference for web components over native code.  As 
far as I can tell web components and native code lack all of the same 
safety guarantees.

1) Type safety:

Both native code, and js inside of custom web components have the potential 
to raise exceptions, or produce invalid results due to a lack of type 
safety.

2) Non-determinacy:

Both native code and js inside of custom web components have the potential 
to introduce non-determinacy.  You can imagine that the google maps web 
component might receive a 500 status response from google during an outage, 
or the author of the component might simply include a Math.random.  This 
will violate the guarantees made by the elm-debugger which disables port 
code from running for exactly this reason, which could prevent you from 
being able to reliable replay UI interactions.

3) Versioning guarantees:

Neither native code nor web components can be published in elm-package, and 
they both include javascript, so neither can benefit from elm's semver 
enforcement.

Now I understand that web components may be more ergonomic than equivalent 
native code in certain situations e.g. in the google maps case, but they 
don't seem any more or less safe than native code.  Furthermore, they 
impose the cost of an additional build system (bower) and polyfills.

So if the main motivation for discouraging the use of native is to promote 
safety, why encourage the use of web components?

Thanks.

-- 
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.