@alandipert: yesterday you mentioned your demo hoplon contacts project. It looks nice, thanks! Is there one that would also show off the server-side? Is Castra used for that? An example of that would be cool to have.

I'm trying to set up a project where I use boot-http with a ring handler. I set resource-paths to #{"resources"}, ring's middleware resources to "public" (so that the ring server will serve static resources from resources/public), create a resources/public/js/main.cljs.edn so that my main.js will end up there. When I start the server if I go to localhost:3000/js/main.js it is indeed there which is cool, but the index page can't find goog's base.js. The created main.js points to main.out/goog/base.js while it should be pointing to js/main.out/goog/base.js. Is this something I can set up or is the compiler not configured correctly?

ah, there's a separate boot channel here on slack, sorry

@onetom: yesterday pushed alpha6 with FOUC fixes

@micha: im testing that for an hour now with different version number combinations. i read the discussion on #C053K90BR too.

im seeing all sorts of weird behaviour, eg all pages are compiled into 1

example of how i'm using it

and as the page loads the title (on the chrome tab) is iterating thru all the page titles and settles with the last one

whoa

what version of boot-cljs?

tailrecursion/boot-hoplon 0.1.2

but i reverted to exicon/boot-hoplon 0.1.2-SNAPSHOT because prerendering was broken again otherwise

i've checked you kept our make-parents but yet it didnt work with hoplon alpha6

hm maybe i botched the merge?

i got a similar error as before:

Prerendering HTML files...
• newsletters/index.html
             clojure.lang.ExceptionInfo: java.io.FileNotFoundException: /Users/onetom/.boot/cache/tmp/Users/onetom/exicon/homepage/8a8/-e9icqa/newsletters/index.html (No such file or directory)

if you remove prerender task is everything ok?

hm let me test this

yes, without the prerender it seems fine

ok i may need to push a new version

the merge might have been done incorrectly

sorry about that

we need tests

'[[exicon/boot-hoplon "0.1.2-SNAPSHOT"]
    [tailrecursion/hoplon "6.0.0-alpha6"]
    [adzerk/boot-cljs "1.7.48-SNAPSHOT"]

well, clearly tests are necessary

we need a test harness for boot tasks

btw, i looked into what are the latest version of some indirect deps and i was wondering if there is any reason for holding back on these upgrades:

[tailrecursion/javelin "3.8.0"]
    [cljsjs/jquery "2.1.4-0"]

ok i verified, the merge was botched

javelin can be updated for sure

the api hasn't changed in over a year

if jquery works for you we can update

there were some issues aroung attr/prop i think

but keeping up to date with jquery is important especially for mobile

for desktop not so much

what is really used from jquery, btw?

only the low-level DOM manipulation stuff

you'd think that goog closure would be able to do that but i found it to be only partial implementation

it didn't compare to jquery in terms of efficiency and reliability

that's exactly what my thinking was

i ran into problems with setAttribute, which is a total no-go

like setting data-* attributes was unreliable

because goog had a hardcoded list of attrs that i guess they use at google

and it did weird things with any attr it didn't have hardcoded in

things like that

i figured that jquery is the most solid low-level dom library there is

so it makes sense to use it

have u seen this: https://www.youtube.com/watch?v=GMWAHzXQnNM

no

the guy mentions some document.querySelector or what

is this the "it's a library" vs "it's a framework" debate?

havent checked it yet but that sounded like what $(<string>) does

we use $(<string>) in only one or two places in the entire thing

what jquery does provide though is really solid stuff like set attribute on element

where you need hacks around various browser bugs

we can replace it though, i'm not married to jquery

it's just a time management thing

jquery just works

http://caniuse.com/#search=querySelector

i spent a lot of time working around goog closure bugs and whatnot

i was not aware of this built in function

yeah it's a thing, and jquery uses it

jquery has a highly evolved thing that uses whatever is best

and it has caching and whatnot

in a modern fully compliant browser jquery is simply a thin layer on top of querySelector and all those things

okay. it's just dnolen was advertising learning the "awesome closure lib" and using goog.object.get instead of aget and stuff like that, that's why i was wondering...

it might have improved

but i found it lacking compared to jquery

for dom stuff anyway

my rationale is that the most time consuming bugs are the browser compatibility ones

using jquery pretty much eliminates those

i got you, no need to further elaborate. just push the fixed boot-hoplon so i can test alpha6 😉

lol ok

he's talking about web components

should i also upgrade cljs to -2 or -3 from -SNAPSHOT?

hoplon is the dream of web components but in a way that actually works

you should try latest cljs

ah, yeah, that video was nothing very convincing

if there are bugs we need to fix them

alan and i are pretty convinced that any js solution will be lacking

js doesn't even have a sane equality semantic

so any framework you build on it will be coconuts

ok i'm going to update all this stuff

yeah, that guy was showing of templating, but immediately made me remember coconut lisp too

but then again, it was new to me that the <template> is default in browsers

it's not really

only in some versions of chrome

as i understand it google pissed everyone off by moving forward with their own thing

so he is practically lying then?

and everyone else is refusing to implement it

when is the talk from?

well the guy works for google...

as i understand it ie declares they will never support it

and ff also

yeah he mentions what FF said and he said it's easy to polyfill it so it's not a big issue...

the whole talk was a bit fishy

yeah i looked into it a while ago

thinking to have hoplon elements be those

even at the end a guy kinda nailed him badly...

but the polyfill only does the easy part

with polyfills it's way less powerful than hoplon already is

and the import href business is insane

dependency management is a critical piece of the puzzle

you need a really solid thing for dependencies

which maven is ideal for

yeah, he was keep saying "just stiching the parts together"...

yeah how does that work with transitive deps

made me think he doesn't seem to know wtf is he talking about

i think a lot of these guys don't work on big applications

they work on demos or something

what worries me is this new ES6 is getting accepted and the webcomponents has started to gain traction

at the same time it's all half arsed solutions really. like coffeescript goes well beyond what ES6 provides, what's the point of trying to close the gap between the 2 just a liiiill bit? 😕

yeah the es6 stuff is laughable

they're arguing for years about the syntax of let and fat arrows

in lisp you write a macro in less than 5 minutes and move on with getting work done

and the one thing we really could use, weak references, are not a thing

you can't build really complex things without weak references

i mean you can, but your abstractions suffer

0.1.3 deployed

i found another bug btw in the prerender task yesterday, it was caching prerendered html based on the mtime of the input html file

can u recommend anything i can read up on weak references so i can understand what r u talking about?

which was incorrect because the stuff we're prerendering has nothing to do with the initial html

it's all generated by js

so i removed the caching

ah we are also seeing a strange caching when i use panderio/boot-http

the browser is using fuzzy caching TTL

it should now prerender every time

because there is no explicite cache-control header

in chrome you can have it disable caches while dev tools window is open

that's what i do

if only last modified time is specified, that's not enough

i haven't had a cached page issue in a long time

okay, maybe we will do that too

there must be a ring handler for etag maybe?

there is also a secret thing that alan showed me the other day

when you have dev tools open you can right click on the reload button and select "Empty Cache and Hard Reload"

but i think if you have caching disabled when dev tools is open it's just a no-op

i think even the etag was not enough

to make you feel better

are you sure it wasn't the bug in the perrender task?

it wasn't actually prerendering unless the initial html file changed

which would completely ruin prerendering for hoplon

we had to add this to our nginx config to make sure content gets updated quickly in the visitors' browsers:

expires 1m;
		add_header Cache-Control "public";

because the initial html file never changes

ah ok, this is for production, not dev?

actually as u r asking it now, i think we experienced that phenomena too sometimes

but what i was talking about is prod, yes

we need to fix this in hoplon, use some kind of cache busting url scheme for the js file

eg we released a newer pricing page and we really wanted to old one go away asap...

maybe the url is the content hash?

we need to compute the url before we know the contents of the js probably

the time has come, my hoplon friends, to talk of many things; of nginx and cdns, of cabbages and kings

we're planning to deploy our frontend to s3 website hosting

talks to backend cojure application via CORS

S3 is on our horizon too

the CORS thing works well for about 2 months now with castra 3 and transit

are you using the wrap-castra-session middleware or straight CORS?

i had so many annoying issues with cookies and CORS that i just said 🍪

and made a thing using localstorage instead

alandipert: do you have ideas wrt deploy to s3 + cdn?

like is index.html on the cdn?

if not then we need to rewrite all urls to fetch from cdn instead of relative uris

@alandipert: ^^

(ns appboard.api
  (:require
    [ring.middleware.cors :refer [wrap-cors]]
...
(def ring-handler
  (-> (not-found "Not found")
      (wrap-castra
        'appboard.api
        'leaderboards.api
        'app-builder.api
        'distribution.api)
      (wrap-utf-8)
      (wrap-session
        (node-mongo-session (config :db) "sessions" "appboard.v1"))
      (wrap-cors (re-pattern (str "^" (config :frontend-url) "/?$"))
                 (re-pattern (str "^" (config :homepage-url) "/?$")))))

oh awesome, and cookies are working correctly of course?

that's great

where wrap-cors come from

[jumblerg/ring.middleware.cors "1.0.1"]

the browser doesn't give any helpful insight into why it doesn't send cookies with CORS, it just silently doesn't when it doesn't want to

yeah that's a good CORS middleware

we are setting the cookie on *.http://exiconglobal.com so {www,app,api,appboard}.http://exiconglobal.com can all access it

ah i see

my backend is on a completely different domain

we also want to be able to support whitelabeling, so we don't know what domain the frontend will be on

the backend is multi-tenant of course

meaning u would need to accept * as the CORS origin?

no, we'd have a whitelist

for the user's security

we don't want random domains on the internet to be able to trick people into logging into our backend from their page

but shouldnt that whitelist be exposed to every client then?

no, the CORS middleware handles that very elegantly

it generates the CORS headers dynamically

for each request

only containing the info necessary to set that specific request up

the whitelist would be for the middleware to use to deetrmine whether to generate accep-origin headers for that request or not

shouldnt the Access-Control-Allow-Origin: header contain the list of all possible frontends?

no, only the origin the client sent

if it's in the whitelist

the client doesn't need any of the other domains

so those regexes i set in the example above are not sent back, just the requesting domain IF that domain matched any of those regexes?

indeed, if you set it to #".*" in the middleware it doesn't send *

it sends the origin the client sent, but for any client

yes, what you said

interesting. i think i should read the code. it makes a lot of sense of course.

accept * will correctly block cookies from being sent

so we don't send that

i see

the client won't send credentials to accept-origin:*

and it shouldn't because that would be a nasty trick to pull on the user

i think CORS is not well understood

so * is meant for publicly readable apis?

it's meant for APIs that are safe to use on other people's behalf without their knowledge

like the github public api, for example

like to get info about public repos

all GET requests

no credentials

the api key used is associated with the domain of the sender for acocunting purposes, not for authentication

rate limiting, etc

CORS is a mechanism by which the browser prevents "confused deputy" attacks

the confused deputy is the situation where the user has authroized the browser to perform certain actions on their behalf

like sending cookies with each request for example

you "deputize" the browser such that once you log into a site the browser can cache some token and automatically send it on subsequent requests

however, suppose you log into a site in one tab

and in another tab you navigate to a different site that wants to make AJAX requests to the first site

you've delegated the cached credentials management to the browser

the browser now needs to know whether it should send credentials or allow site 2 to make the AJAX request to site 1

the way it does this is by adding an additional CORS preflight step to site 2's request

where it asks site 1 whether site 2 is within the same authroization realm, basically

like will site 1 accept credentials from people on site 2

so CORS stuff is not for backend security or authroization

it's metadata the browser needs to determine whether credentials associated with one domain are related to another domain

so the browser can decide what the security implications are of allowing or not allowing access from site 2 to resources on site 1

so whats the misunderstanding?

because what u described so far is known to me at least

a lot of times it's seen as a way to prevent unauthorized access to the backend

which it totally is not

a hacked client can circumvent CORS easily

yup, im clear on that i think, but thanks for the explanation irregardless. my colleagues might found your explanation more enlightening that what they read about cors so far

also the preflight thing

im trying alpha6 w boot-hoplon 0.1.3 and boot-cljs 1.7.48-2

like why the need for the OPTIONS request

mostly misunderstood

it does that "load all pages" thing again///

which optimizations setting are you using?

also can you look in the html file and see if there are multiple js script tags?

:simple

can you try with :none please?

i think there is an issue with optimizations

does it happen without prerendering too?

oh also, some of the experimental features added to alpha6 might be useful for static site generators

the (static ...) macro specifically

i will try in all combinations, it just takes 5mins to run a :simple opt + prerendering

i read your commit message and i will check your gist too soon, im just having dinner atm

haha no rush

enjoy your dinner

i was also wondering in our specific case i would be probably a lot better off if i would just generate 1 page with sections which depend on the URL, but not on the #hashfragment but on the /path/part...

i know u r against this HTML5 history api, but for such a limited case it might work, no?

to simulate independent pages for SEO purposes

sure

i reverted to [adzerk/boot-cljs "1.7.48-SNAPSHOT"] and it's not fckd now

interesting

are you building multiple things concurrently?

multiple pages i mean

well, do i have an option?

i dont know how to turn off parallel builds

im still talking about our public homepage which defines ~15 hoplon pages

no i was just curious

but i slowly feel like if i would break our repo into 15 repos for every page we would have less issues

how do you mean?

we can add the --ids functionality to hoplon pretty easily

all of them could be on different hoplon, cljs, etc versions and could be deployed "independently"

the only problem is that the header and the footer are shared

boot hoplon --ids products/index cljs ...

that would compile just products/index.html et al

the other tasks support this as well

sounds something which could significantly speed things up for us in development

it would be added to the hoplon task

is there a way to set task options from the command line?

how do you mean?

we already have a pipeline setup which has hoplon in the middle

how can i just alter the options for hoplon?

from the command line i mean

you mean like this?

derp disregard where it says "http://hoplon.io"

i must have copy pasted that a long time ago

this is the dev task for my current project at adzerk

yes

just without being explicite and coaxing the options out

hm, that's the only way i know of

this way you get useful --help and whatnot

for all tasks

which is important on my project because we have people testing who aren't familair with the project

so with this --ids option can i specify multiple pages? since we usually want to build the main page and navigate from there to the other page we are working on

yep

great, in that case we would use it for sure

(comp ... (hoplon :ids #{"index" "products/index" ...}))

beautiful!

so how important is it to you to be able to have pages at paths like products/42/index.html etc

the 42 in there specifically

i'd like to do away with the tailrecursion.hoplon.app-pages._products_42_index_DOT_html namespace names

but that only works if your pages are valid namespace symbols

meaning you can't have a namespace named products.42.index

we dont have such needs at the moment

if we would have we would just prefix the number with something

perhaps we can escape those yeah

it's not like we are trying to emulate a RESTful API w static files

yeah that's my thinking as well

and the SPA entry points are few

but i can imagine that another important use-case would be building blogs a'la jekyll

where the article indexes are typically under /2015/08/11 pathes...

in thai even in speech the colors are prefixed with the word "color" so i dont see why u shouldnt prefix it here 😉

/post-2015-08-11

imean they dont say "red" they say "color red"

does the word for "red" have other meaning without the prefix?

mostly not

man, i recently did a little reading about the Finnish language

really fascinating

there are so many ways to say things in that language

apparently even google searches are somewhat complicated by the different forms for each word

@onetom: why do you use :simple optimizations during development?

i dont use simple during dev. i used it for prod (because :advanced was buggy with some of the hoplon versions)

ah i see

where is this fascination of yours w natural languages comes from? i was dating linguist girls for years...

man i need to do that

lol

[adzerk/boot-cljs "1.7.48-2"] works with :optimizations :none but the *re*compilation time is abysmal; it's 54seconds, while it's "only" 16seconds with 1.7.48-SNAPSHOT

you're saying it's actually slower in parallel?

why, the difference between -2 and -SNAPSHOT is parallelism? -SNAPSHOT also saturated all of my cores.

maybe too much parallelism

the difference is separating each build into its own pod

im on a 2.6GHz i5 MacBook Pro with 4 cores but "only" 8GB ram.

yeah i don't get it

@onetom: i think the multiple pages issue is now fixed in cljs