Re: [w3c/webcomponents] Make JavaScript Files a Valid Entry Point to a Web Page (#807)

> Is this a fair restatement of your goal?:
> 
> """
> A developer can deploy a client-side web application without having to write, check in, or maintain an HTML file.
> """
Yes! You've purified the essence into one sentence and I really like the solution you've provided.

In light of this elegance, promoting a client-side solution is more difficult. My gut tells me that the utility of a client-side solution (to this goal) extends beyond what my imagination immediately brings to mind. However, here's what immediately comes to mind when I compare your server-side solution with my client-side [pseudo code](https://github.com/w3c/webcomponents/issues/807#issuecomment-487782522):

Portability - With the client-side solution, the file is platform independent, the same file will produce the same page by merely being placed onto any web server; if you move the file from node.js to IIS to nginx to apache, the file produces the same page without the need to perform any url-rewrite code on the underling technology. All that is needed is contained by a single file (independence, encapsulation, portability). As an extreme example, you could even attach this same file to an email, and the recipient could receive a fully functional web application by simply opening it in their browser. That type of portability can be achieved with [html](https://stackoverflow.com/a/29095811/217867), but it wouldn't meet my goal that you refined so well.

I really love Tagged Template literals, I think they are the key to solving the HTML-DOM impedance mismatch that complicates web development today. Long-run, I see myself putting more html into template literals and Tagged Template literals than into static html files. Because of this, my gut tells me there is way more utility in serving javascript files directly (without html wrappers) than I can currently imagine. This is why I started this thread in the unusually abstract way I did. I was hoping that some else might be able to see something more concretely persuasive than my own speculation. Perhaps there is just nothing to see.

The server-side solution you provided is going to save me mountains of tedious html work. It is amazing how much unnecessary work you can eliminate by tackling a problem at its most fundamental level. Likewise, I think that "not being able to directly navigated to a client-side javascript file that produces its own html wrapper programmatically" is a fundamental lacking. And one day, someone is going to come up with reasons persuasive enough to bring this concept into fruition.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/807#issuecomment-489797205