Nice! I was planning on doing something similar for my own blog/personal site. Is the source available anywhere so I can examine some of your techniques? I do not see it on you github. If you desire to keep it closed, that's cool. I thank you for all you have shared.
Re: cors, I was planning on having an nginx proxy for the whole thing anyway, with each component in its own docker container. Barring that, I would imagine having pollen be usable as a "library"/plugin application for the racket web server would be another way to go. This would be akin to the notions that I know Django and Rails both have (or had in the past, I have stopped paying attention to each community). Working with Pollen is still a hobby project for me, and I have other things to do before I can *really* spend time on it, but I was extremely excited when I saw it. I have long be longing for an extensible markup language system -- and giving me a good reason to finally dig into Racket is even better. (re: cors and "library apps" and docker, I apologize if some of this has been discussed on here before; I do not pay close attention to this mailing list) On Sat, Jan 13, 2018 at 1:05 AM, Matthew Butterick <m...@mbtype.com> wrote: > https://mbtype.com > > Whereas Practical Typography and Beautiful Racket were almost entirely > static web pages, this is the first project where I used Pollen with > scripts running on a Racket web server (many good ideas came from Jesse > Alama's book Server: Racket [1]) > > The pages aren't generated dynamically, but they have elements (e.g., > translated text) that are updated on demand from the server. > > It worked fine. It wasn't much different from an ordinary Pollen project. > > The biggest problem — which I never solved in a satisfying way — was how > to make a single testing environment. With a static Pollen site, you can > run the project server and that accurately simulates just about everything. > > But in this case, the project server is limited, because it can't make > requests to the live Racket web server (due to the restriction against > "cross-origin resource sharing" [2] which is a browser security policy, and > has nothing to do with Pollen). There are apparently ways to defeat CORS. > They all made me dizzy. I just learned to live with it. (Open to better > ideas.) > > The experience did not persuade me that Pollen ought to have more of a > server-side scripting component. As it stands, a Pollen front end can > cooperate with any server back end. I don't see any special virtue in tying > them together, like a matching washer and dryer. > > Moreover, a lot of the coordination in-browser happens via JavaScript, and > there's no way to supplant JS. (Even though I'm a decades-long JavaScript > hater [3], I have to concede that ES6 is actually not bad at all. Though > largely because it's imported so many Rackety/Lispy features.) > > > > [1] http://serverracket.com/ > > [2] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS > > [3] https://youtu.be/20GGVNBykaw?t=130 > > -- > You received this message because you are subscribed to the Google Groups > "Pollen" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pollenpub+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 "Pollen" group. To unsubscribe from this group and stop receiving emails from it, send an email to pollenpub+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
