[ClojureScript] Re: Isomorphic ClojureScript
On Tuesday, May 19, 2015 at 7:17:10 PM UTC+2, marc fawzi wrote: Is anyone out there working on a pattern of framework for isomorphic ClojureScript? My sense so far is that most are happy running Clojure on back end and ClojureScript on front end. But Matt's recent post made me think of Isomorphic apps. For example, you can have the 1st page render server side so it's pre-rendered for faster load, and then have the rest of the app (all other pages) run in the client. Meteor just got $20M to build the isomorphic js framework to rule them all. Any interest in this within the ClojureScript community? This is incorrect, Meteor got 20 million to build a full stack and real time framework. That is what the investors are eyeing. The fact that it is Javascript on the front end is important, but not the backend -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
[ClojureScript] OnsenUI (or Ionic) with ClojureScript/Reagent
Hi there! I've started building a hybrid mobile app using Cordova, ClojureScript and React via Reagent. Most parts work perfectly. To make my mobile UI speedy and nice to look at, I've tried using OnsenUI (http://onsen.io). OnsenUI uses web components, just as Ionic does. So I have to call (.compile js/ons dom-elm) on :component-did-mount to make it look right. This also works fine. What I can't get my head around is how to smoothly attach ClojureScript based events to elements such as the Onsen buttons ons-button/. The onclick event seems to work only with AngularJS events, and I've never spent a minute on Angular so.. Any input, or should I go for KendoUI until a better ClojureScript/React/Reagent backed alternative arises? Or can someone point me to a really simple/lightweight HTML5/CSS/JS framework that I can use today? Flat UI and speed are my first priorities, then patterns/GUI elements like what Onsen offers are second. Thanks in advance! Best, Henrik -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
Yes, if I wasn't clear, when I say server side rendering I do mean server side rendering of SPA (Om, Reagent) applications. If we're just talking about old-school server-rendered sites I would agree Clojure would be the way to go. The interesting thing about using ClojureScript is that you can toggle between a SPA and a completely server-rendered site very easily. All you have to do is not include the scripts in your response and you have exactly that. But with the same code-base. Very cool concept imo. On Tue, May 19, 2015, at 05:23 PM, Marc Fawzi wrote: I think we (as an industry) ended up with SPAs because we embraced HTTP APIs and if you have an HTTP API then you have two logical outcomes: 1. Render pages server side with some performant data layer, sidestepping the HTTP API and it's associated overhead but incurring the cost of server side rendering --- this means that you don't get to consume your own API which is not an issue if you have full test coverage but it could be an issue in that you won't experience the pain that your API customers experience and won't have the same feedback to help you evolve and improve your API, i.e no internal customers 2. Render pages client side and use the HTTP API, which definitely has an associated overhead but you compensate for that by shifting the rendering job to the client What doesn't make too much sense to me is rendering server side while going thru an HTTP API .You incur the cost of both the server-side rendering and the HTTP API. Having said that, in this scenario, if you only server-side-render the initial page then it still makes sense. The above conclusion is debate-able of course, but I'm not sure what I'm missing here. On Tue, May 19, 2015 at 2:06 PM, Matthew Phillips matt...@matthewphillips.info wrote: __ I think running ClojureScript server-side in Node is the future. Server-side rendering has an advantage not just in SEO but in user-experience as well. I don't know if that's ever something Clojure-JVM is going to be able to do. On Tue, May 19, 2015, at 02:42 PM, Daniel Kersten wrote: I looked at DomKM's server-side Om some months back, but that's about it. I'm not really interested in running a ClojureScript server (Clojure is much better suited for that), but performing 1st page render is something I'm interested in (perhaps through an approach similar to DomKM's - ie running cljs in nashorn or similar). I don't have a big need for it right now though, so I'm not likely to put any effort into it myself any time soon. I am interested in seeing what others accomplish, though. On Tue, 19 May 2015 at 18:17 Marc Fawzi marc.fa...@gmail.com wrote: Is anyone out there working on a pattern of framework for isomorphic ClojureScript? My sense so far is that most are happy running Clojure on back end and ClojureScript on front end. But Matt's recent post made me think of Isomorphic apps. For example, you can have the 1st page render server side so it's pre-rendered for faster load, and then have the rest of the app (all other pages) run in the client. Meteor just got $20M to build the isomorphic js framework to rule them all. Any interest in this within the ClojureScript community? Sent from my iPhone -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com[1]. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to
Re: [ClojureScript] Using a state machine to design/program UI ?
For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have a *relatively* small set of states that can be transitioned between based in user input. You can even apply state minimization techniques to reduce the total number of states. But in a web app you are continuously grabbing
Re: [ClojureScript] Using a state machine to design/program UI ?
You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward FSM implementation since you normally download the data at game load time and from there on you have a
Re: [ClojureScript] Using a state machine to design/program UI ?
Thanks, Khalid. Jamie On May 20, 2015, at 9:58 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi
Re: [ClojureScript] reagent-nodejs feedback request
Matt, I forgot to mention, if SEO is the priority and you enjoy building SPAs in Reagent, Google has had a way (for many years now) to crawl client-side JS generated pages where you use #! in your urls (or use the fragment meta tag) to tell google that to ask the server for the server-rendered content of that page (assuming it's not passworded/no session) s you don't actually serve pre-rendered pages to users, just to the bot, which would result in less load on your server. Just another idea (may not be as terrible as the first attempt!) :) Reference: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started On Tue, May 19, 2015 at 3:28 PM, Marc Fawzi marc.fa...@gmail.com wrote: yup that was a terrible idea from the era before isomorphism was discovered ... I'm just getting into the whole isomorphic thing... the issues you stated should all be solvable or if not then reduced to a set of core obstacles so we can understand the actual limitations of this approach On Tue, May 19, 2015 at 3:05 PM, Matt Ho matt...@gmail.com wrote: Like I said in the other post, I'm not really keen on using something besides reagent to render pages. Having two ways to render a page seems like misery waiting to happen. Also, having only the home page renderable doesn't give me the SEO benefits I want. I need the detail pages to be crawl-able as well, not just the home page. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere I love this idea in principle but seeing how confusing reader conditionals can be to a beginner I would personally stick with the Om/Reagent isomorphic path (nashorn or node) On Wed, May 20, 2015 at 6:56 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Javascript developer speaking. The problem with isomorphic apps the Node.js way (not the Meteor way) is that you want to run the SAME code both sides, and client-side concerns aren't server-side concerns. Given it's the same language, and some thing are side-agnostic, indeed a great amount of code is shareable like templates (and event handling with React.js), which make the 1st render fast. But other concerns can't really be written the same way on both sides. Current solutions : - Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere - Use JS/Node.js, and use a build tool like Browserify/Webpack that allow you to replace 1-to-1 some files for server-side and client-side. So you need to write your own common interfaces, not easily done. - Use Meteor, and have simple if(isClient/isServer) in your code to split the concerns and let Meteor deal with rest. The thing is that Meteor is not really compatible with the rest of Node.js/npm ecosystem, and they make lot of choices for you about the stack. Something lacking with CLJX/CLJC AFAIK is that you can't target *both* Node.js and the browser from the same Clojure code base. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Using a state machine to design/program UI ?
Yup, well captured. On Wed, May 20, 2015 at 6:58 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: You would want it if you want to inspect/debug/transmit/replay the whole the state of your application. Having nothing encapsulated and everything in a global state permits this. Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 3:51 PM, Jamie Orchard-Hays jamie...@gmail.com wrote: For local state, I mean state that has to do only with the component itself, nothing to do with the data itself. For example, if I have a component that can switch between editing/reading states, I can't imagine why I would want this information stored outside of the component itself. Jamie On May 19, 2015, at 11:58 AM, Daniel Kersten dkers...@gmail.com wrote: I don't think it implies local state, necessarily, although it may benefit from it. I think alternatives can be modular too. For example, re-frame's approach of a central place to store data is like a Blackboard system, which may even help modularity, not hinder it, because modules don't need to know anything about each other - only that the data they read and write is in the central place and may be (transparent to the modules) be accessed/updated by multiple modules transparently (and hopefully gets validated eg through a schema or constraint system to prevent one module from writing data that breaks another module). On the other hand, local state implies encapsulation and encourages strict interfaces to access it, which can also help modularity. In my personal experience this has (more often than not) led to tightly coupled modules instead, however. I personally prefer the re-frame single-place-for-data approach because in my opinion its benefits outweigh its disadvantages, but perhaps I've just been doing local state wrong :) (actually pretty likely!) PS: It'll probably be some time before I get a chance to read Horrocks' book. If anybody knows of any similar content available on the web for me to read in the meantime, I'd love to hear of it! On Tue, 19 May 2015 at 14:34 Jamie Orchard-Hays jamie...@gmail.com wrote: I agree. The word that came to mind while reading your comments, Daniel, was modularity. Does modularity imply local state? Pondering... Jamie On May 18, 2015, at 1:26 PM, Khalid Jebbari khalid.jebb...@gmail.com wrote: I like how you break up the state machines, it has sense in web app. Page 1 has 2 widgets, page 2 has a form. Each widget/form can have a FSM associated with it, the higher level FSM knowing just the higher level state of all widget displayed. Mmmh... Interesting. Le 18 mai 2015 à 19:13, Daniel Kersten dkers...@gmail.com a écrit : From my understanding of it: Use higher level states and decouple them somewhat from the data. For example, games do have lots of dynamically changing data. In a modern shooter you might have dozens of characters with positions, orientation, velocity, health information, weapons, ammunition, etc all of which can be constantly changing. And that's just taking the characters into account. I wouldn't go and build a state machine that enumerates all of the possible transitions from a twelve characters with done distribution of attributes in this location moving in that direction state. I'd break it down so that each character has a high level state like seeking powerup or running. Probably not a great example although it does illustrate that you might have a hierarchy of state machines. In the game example, the highest level might be something like in play or paused and the lowest might be an each characters firing weapon. In client side web app, you could say that each configuration of data is a state (the re-frame readme mentions that you could think of the app-db like this), but I think that's too fine grained to be useful. Instead I'd define higher level states (possibly in a hierarchy). I'd ask myself, regardless of the data available, what are the logical states that a user could be in and for each one, what are the actions that they can perform (and what state does each action transition them to). This could be as simple as pages and links, but with a rich single page application it's more likely finer grained than that. Maybe what dialogs or widgets are accessible. Again, you could then layer these into a hierarchy of state machines. One advantage of this is you always know what a user can do at any given time because you can look at what state they're in. I think of FSM states as orthogonal to the data, not as the data itself. The states dictate what data is accessible and what can be done to it; the data doesn't dictate what state the application is in. I suppose terminology gets confusing, but this is the approach I'm toying with. I'll see how that goes :) But yeah, needs more thinking. On Mon, 18 May 2015 16:55 Marc Fawzi marc.fa...@gmail.com wrote: Games are ideal candidate for straight-forward
Re: [ClojureScript] Isomorphic ClojureScript
Didn't read like a rant, but rather as some well thought-out points. :) On May 19, 2015, at 6:00 PM, Matt Ho matt...@gmail.com wrote: Let me give a slightly different take on it. My sense is we got to SPAs because the industry wanted more responsive and more dynamic web sites. That said, I would break down sites into one of two types; those that need/want SEO and those that don't. For non-SEO sites (anything password protected), the initial page render is nice, but not absolutely required. Some very high traffic sites, like Facebook and Gmail, continue to do mostly client side rendering. Administrative sites like the AWS console also nicely fit into this category. For the SEO sites, server side rendering is a business need. I'm trying to think of a case where a major site that tried client-side rendering only didn't eventually come back to server side rendering (at least for the first page). Some notable examples would be Twitter and Airbnb. They tried, client-side only, but ended up rendering the first page server side. Ok, last point and I'll stop ranting ;) As for the additional HTTP request, my sense is that it's not the number of requests, but the overall latency (or time to first Tweet as Twitter would put it) that's important. Most modern sites (Google, LinkedIn, Facebook, Netflix, etc) use many services to handle a single request. What's important is that these low-latency requests don't significantly impact and may even reduce overall latency. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
On Wed, May 20, 2015 at 9:56 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Something lacking with CLJX/CLJC AFAIK is that you can't target *both* Node.js and the browser from the same Clojure code base. Not entirely true. The the cljs.core/*target* dynamic var will be bound to the string of the target, currently default and nodejs are the only possible values. You can write ifs/switches on the value of this dynamic var. cljs.core/*target* is actually a Google Closure Compiler define so in advanced mode any code in a target block that doesn't match will get eliminated. David -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
@David, I didn't know this feature. Good to know ! @Marc : it's a matter of trade-offs. Node.js and the JVM are very different platforms. If developer convenience is very important, isomorphic the node.js way with Nashorn or Node could be a good thing. Depends on the developers :) Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 4:01 PM, Marc Fawzi marc.fa...@gmail.com wrote: Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere I love this idea in principle but seeing how confusing reader conditionals can be to a beginner I would personally stick with the Om/Reagent isomorphic path (nashorn or node) On Wed, May 20, 2015 at 6:56 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Javascript developer speaking. The problem with isomorphic apps the Node.js way (not the Meteor way) is that you want to run the SAME code both sides, and client-side concerns aren't server-side concerns. Given it's the same language, and some thing are side-agnostic, indeed a great amount of code is shareable like templates (and event handling with React.js), which make the 1st render fast. But other concerns can't really be written the same way on both sides. Current solutions : - Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere - Use JS/Node.js, and use a build tool like Browserify/Webpack that allow you to replace 1-to-1 some files for server-side and client-side. So you need to write your own common interfaces, not easily done. - Use Meteor, and have simple if(isClient/isServer) in your code to split the concerns and let Meteor deal with rest. The thing is that Meteor is not really compatible with the rest of Node.js/npm ecosystem, and they make lot of choices for you about the stack. Something lacking with CLJX/CLJC AFAIK is that you can't target *both* Node.js and the browser from the same Clojure code base. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/T6no_srtBzc/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
@khalid true re: trade offs... also, good to diversify thinking in just one tech all day can be a path to ideological stuckness ... :) On Wed, May 20, 2015 at 7:11 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: @David, I didn't know this feature. Good to know ! @Marc : it's a matter of trade-offs. Node.js and the JVM are very different platforms. If developer convenience is very important, isomorphic the node.js way with Nashorn or Node could be a good thing. Depends on the developers :) Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 4:01 PM, Marc Fawzi marc.fa...@gmail.com wrote: Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere I love this idea in principle but seeing how confusing reader conditionals can be to a beginner I would personally stick with the Om/Reagent isomorphic path (nashorn or node) On Wed, May 20, 2015 at 6:56 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Javascript developer speaking. The problem with isomorphic apps the Node.js way (not the Meteor way) is that you want to run the SAME code both sides, and client-side concerns aren't server-side concerns. Given it's the same language, and some thing are side-agnostic, indeed a great amount of code is shareable like templates (and event handling with React.js), which make the 1st render fast. But other concerns can't really be written the same way on both sides. Current solutions : - Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere - Use JS/Node.js, and use a build tool like Browserify/Webpack that allow you to replace 1-to-1 some files for server-side and client-side. So you need to write your own common interfaces, not easily done. - Use Meteor, and have simple if(isClient/isServer) in your code to split the concerns and let Meteor deal with rest. The thing is that Meteor is not really compatible with the rest of Node.js/npm ecosystem, and they make lot of choices for you about the stack. Something lacking with CLJX/CLJC AFAIK is that you can't target *both* Node.js and the browser from the same Clojure code base. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/T6no_srtBzc/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
That's right ! Ideology leads nowhere. And we'll all have to write javascript (for browsers) one way or the other anyway :) Le 20 mai 2015 à 16:25, Marc Fawzi marc.fa...@gmail.com a écrit : @khalid true re: trade offs... also, good to diversify thinking in just one tech all day can be a path to ideological stuckness ... :) On Wed, May 20, 2015 at 7:11 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: @David, I didn't know this feature. Good to know ! @Marc : it's a matter of trade-offs. Node.js and the JVM are very different platforms. If developer convenience is very important, isomorphic the node.js way with Nashorn or Node could be a good thing. Depends on the developers :) Khalid aka DjebbZ @Dj3bbZ On Wed, May 20, 2015 at 4:01 PM, Marc Fawzi marc.fa...@gmail.com wrote: Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere I love this idea in principle but seeing how confusing reader conditionals can be to a beginner I would personally stick with the Om/Reagent isomorphic path (nashorn or node) On Wed, May 20, 2015 at 6:56 AM, Khalid Jebbari khalid.jebb...@gmail.com wrote: Javascript developer speaking. The problem with isomorphic apps the Node.js way (not the Meteor way) is that you want to run the SAME code both sides, and client-side concerns aren't server-side concerns. Given it's the same language, and some thing are side-agnostic, indeed a great amount of code is shareable like templates (and event handling with React.js), which make the 1st render fast. But other concerns can't really be written the same way on both sides. Current solutions : - Use CLJX/CLJC to split what goes to the JVM and what goes to the browser from the same source. Nice, and you get Clojure everywhere - Use JS/Node.js, and use a build tool like Browserify/Webpack that allow you to replace 1-to-1 some files for server-side and client-side. So you need to write your own common interfaces, not easily done. - Use Meteor, and have simple if(isClient/isServer) in your code to split the concerns and let Meteor deal with rest. The thing is that Meteor is not really compatible with the rest of Node.js/npm ecosystem, and they make lot of choices for you about the stack. Something lacking with CLJX/CLJC AFAIK is that you can't target *both* Node.js and the browser from the same Clojure code base. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/T6no_srtBzc/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to a topic in the Google Groups ClojureScript group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/T6no_srtBzc/unsubscribe. To unsubscribe from this group and all its topics, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at
Re: [ClojureScript] Isomorphic ClojureScript
Sounds great. Definitely looking forward to blog post when you get to it! On Wed, 20 May 2015 17:59 Dustin Getz dustin.g...@gmail.com wrote: Is anyone out there working on a pattern of framework for isomorphic ClojureScript? Yes, I am, it's basically a shell Clojure/Pedestal app that calls into a specific ClojureScript interface where the entire application is defined as a single page app, it prefetches the initial ajax payloads, supports URL redirects and can heal incorrect URLs to the canonical URL, works with head content, supports 404s etc. It's very very fast! Sooner or later I will write a blog post. It's not a lot of code though it did take some amount of thought. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
Is anyone out there working on a pattern of framework for isomorphic ClojureScript? Yes, I am, it's basically a shell Clojure/Pedestal app that calls into a specific ClojureScript interface where the entire application is defined as a single page app, it prefetches the initial ajax payloads, supports URL redirects and can heal incorrect URLs to the canonical URL, works with head content, supports 404s etc. It's very very fast! Sooner or later I will write a blog post. It's not a lot of code though it did take some amount of thought. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] reagent-nodejs feedback request
So if SEO is the overriding priority then u could have a proxy in front that looks for the _escaped_fragment thing in the get request and route all those to a bot-dedicated nodejs/express app that serves pre-rendered page content. This is based on the Google scheme. Sent from my iPhone On May 20, 2015, at 6:57 AM, Marc Fawzi marc.fa...@gmail.com wrote: Matt, I forgot to mention, if SEO is the priority and you enjoy building SPAs in Reagent, Google has had a way (for many years now) to crawl client-side JS generated pages where you use #! in your urls (or use the fragment meta tag) to tell google that to ask the server for the server-rendered content of that page (assuming it's not passworded/no session) s you don't actually serve pre-rendered pages to users, just to the bot, which would result in less load on your server. Just another idea (may not be as terrible as the first attempt!) :) Reference: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started On Tue, May 19, 2015 at 3:28 PM, Marc Fawzi marc.fa...@gmail.com wrote: yup that was a terrible idea from the era before isomorphism was discovered ... I'm just getting into the whole isomorphic thing... the issues you stated should all be solvable or if not then reduced to a set of core obstacles so we can understand the actual limitations of this approach On Tue, May 19, 2015 at 3:05 PM, Matt Ho matt...@gmail.com wrote: Like I said in the other post, I'm not really keen on using something besides reagent to render pages. Having two ways to render a page seems like misery waiting to happen. Also, having only the home page renderable doesn't give me the SEO benefits I want. I need the detail pages to be crawl-able as well, not just the home page. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] reagent-nodejs feedback request
For me SEO isn't the priority, user experience is. SSR eliminates the flash of no-content you traditionally get from SPAs. On Wed, May 20, 2015, at 11:55 AM, Marc Fawzi wrote: So if SEO is the overriding priority then u could have a proxy in front that looks for the _escaped_fragment thing in the get request and route all those to a bot-dedicated nodejs/express app that serves pre-rendered page content. This is based on the Google scheme. Sent from my iPhone On May 20, 2015, at 6:57 AM, Marc Fawzi marc.fa...@gmail.com wrote: Matt, I forgot to mention, if SEO is the priority and you enjoy building SPAs in Reagent, Google has had a way (for many years now) to crawl client-side JS generated pages where you use #! in your urls (or use the fragment meta tag) to tell google that to ask the server for the server-rendered content of that page (assuming it's not passworded/no session) s you don't actually serve pre-rendered pages to users, just to the bot, which would result in less load on your server. Just another idea (may not be as terrible as the first attempt!) :) Reference: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started On Tue, May 19, 2015 at 3:28 PM, Marc Fawzi marc.fa...@gmail.com wrote: yup that was a terrible idea from the era before isomorphism was discovered ... I'm just getting into the whole isomorphic thing... the issues you stated should all be solvable or if not then reduced to a set of core obstacles so we can understand the actual limitations of this approach On Tue, May 19, 2015 at 3:05 PM, Matt Ho matt...@gmail.com wrote: Like I said in the other post, I'm not really keen on using something besides reagent to render pages. Having two ways to render a page seems like misery waiting to happen. Also, having only the home page renderable doesn't give me the SEO benefits I want. I need the detail pages to be crawl-able as well, not just the home page. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com[1]. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. Links: 1. mailto:clojurescript%2bunsubscr...@googlegroups.com -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
Hey Dustin, That's awesome. I had used some of your stuff before so familiar with the quality of your work! What's the github url? :) On Wed, May 20, 2015 at 9:59 AM, Dustin Getz dustin.g...@gmail.com wrote: Is anyone out there working on a pattern of framework for isomorphic ClojureScript? Yes, I am, it's basically a shell Clojure/Pedestal app that calls into a specific ClojureScript interface where the entire application is defined as a single page app, it prefetches the initial ajax payloads, supports URL redirects and can heal incorrect URLs to the canonical URL, works with head content, supports 404s etc. It's very very fast! Sooner or later I will write a blog post. It's not a lot of code though it did take some amount of thought. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
Ok, please do! Thank you. On Wed, May 20, 2015 at 11:44 AM, Dustin Getz dustin.g...@gmail.com wrote: Marc, Unfortunately I wrote this for a client so it's not open source yet. I'll post here when I get around to it. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] Isomorphic ClojureScript
Marc, Unfortunately I wrote this for a client so it's not open source yet. I'll post here when I get around to it. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
Re: [ClojureScript] reagent-nodejs feedback request
So Matt's idea of what he'd like to do has finally sunk in. Isomorphism (or maybe we should call it automorphism?) together with Google's bot ability to explicitly request server-rendered pages from SPA URLs (during crawling) means that you can serve pre-rendered pages to the bot from one isomorphic app while users get client-rendered pages The same exception we make for Google bot can be made for the first page as well. On Wed, May 20, 2015 at 10:17 AM, Matthew Phillips matt...@matthewphillips.info wrote: For me SEO isn't the priority, user experience is. SSR eliminates the flash of no-content you traditionally get from SPAs. On Wed, May 20, 2015, at 11:55 AM, Marc Fawzi wrote: So if SEO is the overriding priority then u could have a proxy in front that looks for the _escaped_fragment thing in the get request and route all those to a bot-dedicated nodejs/express app that serves pre-rendered page content. This is based on the Google scheme. Sent from my iPhone On May 20, 2015, at 6:57 AM, Marc Fawzi marc.fa...@gmail.com wrote: Matt, I forgot to mention, if SEO is the priority and you enjoy building SPAs in Reagent, Google has had a way (for many years now) to crawl client-side JS generated pages where you use #! in your urls (or use the fragment meta tag) to tell google that to ask the server for the server-rendered content of that page (assuming it's not passworded/no session) s you don't actually serve pre-rendered pages to users, just to the bot, which would result in less load on your server. Just another idea (may not be as terrible as the first attempt!) :) Reference: https://developers.google.com/webmasters/ajax-crawling/docs/getting-started On Tue, May 19, 2015 at 3:28 PM, Marc Fawzi marc.fa...@gmail.com wrote: yup that was a terrible idea from the era before isomorphism was discovered ... I'm just getting into the whole isomorphic thing... the issues you stated should all be solvable or if not then reduced to a set of core obstacles so we can understand the actual limitations of this approach On Tue, May 19, 2015 at 3:05 PM, Matt Ho matt...@gmail.com wrote: Like I said in the other post, I'm not really keen on using something besides reagent to render pages. Having two ways to render a page seems like misery waiting to happen. Also, having only the home page renderable doesn't give me the SEO benefits I want. I need the detail pages to be crawl-able as well, not just the home page. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
