Should not need to use a local server to try Brick

[sole]

An unfortunate side effect of using platform.js is that now you need to use a local server to try these examples when you check them out locally or else you get ALL THE ERRORS. For example:

syntax error brick.html:1
mismatched tag. Expected: </link>. brick-flipbox.html:7
mismatched tag. Expected: </link>. brick-tabbar.html:7
mismatched tag. Expected: </link>. brick-deck.html:7
mismatched tag. Expected: </link>. brick-layout.html:7

This is not mentioned anywhere in the README/docs--or at least not anywhere visible enough that I can recall.

[potch]

This is a side effect of the HTMLImports polyfill. Will see if we can alleviate it, or document easy eays to serve files locally. Note that anyone using webfont will already have to have a local server, and this is something we should be pitching for all webdevs. File:/// is full of bugs.

[fwenzel]

Fwiw, it's why recroom ships (will ship) with recroom serve. Every dev needs it. Unless of course they are making a packaged app.

[sole]

I thought we learnt a lesson.

Needing a local server makes it so much more inflexible and annoying to try things out. Specially on the first 'casual' step when you don't want to invest too much effort on the product. Lose users on that step and you're losing a massive amount of users.

[potch]

@sole what is your recommendation? Any app that uses XHR might have bugs from using file:/// urls, webfonts won't work, and it seems the HTMLImports polyfill doesn't like file:///

[sole]

My concern is that "new" Brick is worse compared to "old" Brick because old Brick could work out of the box with just including a CSS and a JS file. This new Brick doesn't. I guess in other contexts this could be called a regression :-P

Also: the fact that we are doing XHR is totally obscure to the innocent developer that wants to try Web Components By Mozilla. In other libraries you can kind of get the feeling of "oh I'm going to need a local server" when you get to the "loading external resources" point. But here? They are just including a <link> tag. How are they going to even guess?

At the very least there should be a clear mention of how to fire this up ("open a local server because reasons"). But if we can get those .js and .css compressed files I asked for in bug #193 working, we should be fine because there won't be a need to load files on the fly.

[fwenzel]

Sole has a point. There should be a quick-and-easy way to start. Can code Brick with HTML imports for our convenience, but digest it into a more easily usable version for the general public?

[nicola]

+1 with @sole

But a little server should not scare too many people, between recroom, gulp and my dear little server for dummies..

$ python -m SimpleHTTPServer

[mcepl]

+1 for being willing to survive with a local server (to be more buzzword compliant I would use

python3 -m http.server

;)).

My main problem with the old Brick was not the need for a webserver, but need to build, and a pretty rigid (and weird) predetermined directory structure to which one had to write.