Re: [elm-discuss] Isomorphic web apps with Elm?
On Monday, January 9, 2017 at 2:32:43 PM UTC, Noah Hall wrote: > > It's easier to say: > > code shared between client and the server > > than > > isomorphic > > and have everyone understand you. Isomorphic means a lot of different > things to different people. Say what you mean, and more people will be > able to take part and understand :) > I do think the term 'isomorphic' may not be so well received, now that it is past the hype stage. One blog I read said that it means your best developers will be tied up trying to do something overly clever and difficult with javascript, instead of adding value to your business. -- 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] Isomorphic web apps with Elm?
It's easier to say: code shared between client and the server than isomorphic and have everyone understand you. Isomorphic means a lot of different things to different people. Say what you mean, and more people will be able to take part and understand :) On Mon, Jan 9, 2017 at 3:24 PM, 'Rupert Smith' via Elm Discuss wrote: > On Monday, January 9, 2017 at 1:55:08 PM UTC, Joel McCracken wrote: >>> >>> It was very, very nice. It allows for seemless APIs that simplified >>> the code sharing a whole bunch. >> >> >> Oh? My impression was that you thought this wasn't worth it, based upon >> comments here >> https://github.com/noredink/take-home#should-i-use-this-in-production and >> IIRC what I've read elsewhere. >> >> Incidentally, I also hate the term isomorphic for shared client-server >> code. > > > From the wikipedia page for isomorphism: > > "The interest of isomorphisms lies in the fact that two isomorphic objects > cannot be distinguished by using only the properties used to define > morphisms; thus isomorphic objects may be considered the same as long as one > considers only these properties and their consequences." > > Which sounds like a reasonable way to describe when the rendered page is > exactly the same, whether it is rendered client side or server side. As I > understand it though, it often means that some elements of the server side > rendering may be ommitted or only mocked up. Particularly interactive > elements that just won't work with a full server round trip, but will work > asm interactice UI components on the client side. > > Also, I think describing what I am trying to do with my editing mode as > 'progressive enhancement' isn't quite right either. I think the concept > behind progressive enhancement is that you start with you baseline client; > perhpas you even have to support some old version of IE, or users who will > not have javascript enabled in their browser. You code for that in the main, > but add capabilities that better browsers/environments can take advantage > of, if they are available. > > Not sure why you don't like isomorphism, has the word been poisened by too > may javascript libraries? > > -- > 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. -- 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] Isomorphic web apps with Elm?
On Monday, January 9, 2017 at 1:55:08 PM UTC, Joel McCracken wrote: > > It was very, very nice. It allows for seemless APIs that simplified >> the code sharing a whole bunch. >> > > Oh? My impression was that you thought this wasn't worth it, based upon > comments here > https://github.com/noredink/take-home#should-i-use-this-in-production and > IIRC what I've read elsewhere. > > Incidentally, I also hate the term isomorphic for shared client-server > code. > >From the wikipedia page for isomorphism: "The interest of isomorphisms lies in the fact that two isomorphic objects cannot be distinguished by using only the properties used to define morphisms; thus isomorphic objects may be considered the same as long as one considers only these properties and their consequences." Which sounds like a reasonable way to describe when the rendered page is exactly the same, whether it is rendered client side or server side. As I understand it though, it often means that some elements of the server side rendering may be ommitted or only mocked up. Particularly interactive elements that just won't work with a full server round trip, but will work asm interactice UI components on the client side. Also, I think describing what I am trying to do with my editing mode as 'progressive enhancement' isn't quite right either. I think the concept behind progressive enhancement is that you start with you baseline client; perhpas you even have to support some old version of IE, or users who will not have javascript enabled in their browser. You code for that in the main, but add capabilities that better browsers/environments can take advantage of, if they are available. Not sure why you don't like isomorphism, has the word been poisened by too may javascript libraries? -- 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] Isomorphic web apps with Elm?
It's important to separate the two ideas: being able to share code between client and the server was awesome and very nice - but writing Elm to work around node's model was not nice/reliable. On Mon, Jan 9, 2017 at 2:55 PM, Joel McCracken wrote: >> It was very, very nice. It allows for seemless APIs that simplified >> the code sharing a whole bunch. > > > Oh? My impression was that you thought this wasn't worth it, based upon > comments here > https://github.com/noredink/take-home#should-i-use-this-in-production and > IIRC what I've read elsewhere. > > Incidentally, I also hate the term isomorphic for shared client-server code. > > -- > 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. -- 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] Isomorphic web apps with Elm?
> > It was very, very nice. It allows for seemless APIs that simplified > the code sharing a whole bunch. > Oh? My impression was that you thought this wasn't worth it, based upon comments here https://github.com/noredink/take-home#should-i-use-this-in-production and IIRC what I've read elsewhere. Incidentally, I also hate the term isomorphic for shared client-server code. -- 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] Isomorphic web apps with Elm?
Let's not use Javascript names for things here here: you mean shared code between client and the server. Like everything else in the area, I have already done this in the take-home: https://github.com/noredink/take-home#support-summary It was very, very nice. It allows for seemless APIs that simplified the code sharing a whole bunch. On Mon, Jan 9, 2017 at 12:24 PM, 'Rupert Smith' via Elm Discuss wrote: > Just wondering if there is anyone out there interested in isomorphic > applications with Elm? or has tried experimenting with isomorphic Elm? > > Now that I have the same view code running on server and client side, it > occurs to me that I am potentially getting into isomorphic web development. > If I understand it right, and isomorphic app is one which is written in > javascript in order to run the same code client or server side. Some or all > of the page rendering is done server side, then whatever has been rendered > plus the application state is handed over to the client, and the client > displays it or completes or enhances the rendering. The idea is to be able > to get the best of both worlds without having to write the code twice; once > in javascript for the client and once in some other language for the server. > > In my case, I am using server side rendering just for (relatively) static > content, so there is practically no application state. I am pretty much > there with this simple application model as far as being isomorphic goes. > > I believe there is something called the 'isomorphic hand-off' which refers > to the transfer of state from server to client, once the server rendering > has completed. I think this needs to go something like this: > > Run Elm on Server to produce HTML + a little bit of javascript to request > everything needed to complete on the client. > Show HTML on the client as quickly as possible (that is, don't download the > Elm code just yet). > Trigger the loading of the javascript needed to complete the client side > rendering (the same Elm program as was run on the server). > Start up the Elm program and request the state from the server. > Continue rendering from where the server side left off. > > I'm really not sure what exactly the difference is between isomorphic and > progressive enhancement. What I am actually trying to do is to add an > editing mode on the client side - so client and server side renderings will > be very different and more capabilities will be available in client editing > mode. For this reason, I don't think isomorphic is really what I am after, > but I can't help wondering if Elm provides a very neat starting point for > doing it. > > I think Elm might be very well suited to isomorphic, so long as you keep the > model clean and don't put any functions in it. If it is easy to > encode/decode the model, then it becomes almost trivial to write the > isomorphic hand-off? > > -- > 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. -- 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] Isomorphic web apps with Elm?
Just wondering if there is anyone out there interested in isomorphic applications with Elm? or has tried experimenting with isomorphic Elm? Now that I have the same view code running on server and client side, it occurs to me that I am potentially getting into isomorphic web development. If I understand it right, and isomorphic app is one which is written in javascript in order to run the same code client or server side. Some or all of the page rendering is done server side, then whatever has been rendered plus the application state is handed over to the client, and the client displays it or completes or enhances the rendering. The idea is to be able to get the best of both worlds without having to write the code twice; once in javascript for the client and once in some other language for the server. In my case, I am using server side rendering just for (relatively) static content, so there is practically no application state. I am pretty much there with this simple application model as far as being isomorphic goes. I believe there is something called the 'isomorphic hand-off' which refers to the transfer of state from server to client, once the server rendering has completed. I think this needs to go something like this: Run Elm on Server to produce HTML + a little bit of javascript to request everything needed to complete on the client. Show HTML on the client as quickly as possible (that is, don't download the Elm code just yet). Trigger the loading of the javascript needed to complete the client side rendering (the same Elm program as was run on the server). Start up the Elm program and request the state from the server. Continue rendering from where the server side left off. I'm really not sure what exactly the difference is between isomorphic and progressive enhancement. What I am actually trying to do is to add an editing mode on the client side - so client and server side renderings will be very different and more capabilities will be available in client editing mode. For this reason, I don't think isomorphic is really what I am after, but I can't help wondering if Elm provides a very neat starting point for doing it. I think Elm might be very well suited to isomorphic, so long as you keep the model clean and don't put any functions in it. If it is easy to encode/decode the model, then it becomes almost trivial to write the isomorphic hand-off? -- 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.
