It's possible to achieve a similar effect in the browser. The <script> element doesn't have any Content-Type restrictions; it won't reject something outright solely on the basis you serve it something other than application/javascript. So if you managed to point it at an HTML file that's also valid JS (and you can manage to do that, since the set of all possible HTML inputs and the set of all possible JS programs isn't disjoint)... You can use components and libraries in your app that are pages/programs unto themselves, and in particular ones that are self-describing.
Imagine having in front of you a webpage that doesn't work the way you want. You use View Source in your browser, find the URL of some component written in JS that probably contains the offending logic, navigate to that URL, and the source code for that library unfolds on your screen and is free to do whatever it wants to best present itself to you for your understanding. This could include doing syntax highlighting for you (rather than the default black-on-white text that most browsers use when showing you a JS file), putting helper widgets on the screen (e.g. object/configuration inspectors), other on-screen editor components e.g. for any DSLs used in the file, base64-encoded data, etc.
Or imagine a file that knows that it was compiled from TypeScript and knows where the TypeScript source that it was compiled from lives. When you open the URL for the compiled form in your browser, when it loads it dynamically fetches the original .ts sources from elsewhere on the server and then puts that on the screen—maybe even going so far as to put it inside an editor that forms a TypeScript playground.
Imagine having in front of you a webpage that doesn't work the way you want. You use View Source in your browser, find the URL of some component written in JS that probably contains the offending logic, navigate to that URL, and the source code for that library unfolds on your screen and is free to do whatever it wants to best present itself to you for your understanding. This could include doing syntax highlighting for you (rather than the default black-on-white text that most browsers use when showing you a JS file), putting helper widgets on the screen (e.g. object/configuration inspectors), other on-screen editor components e.g. for any DSLs used in the file, base64-encoded data, etc.
Or imagine a file that knows that it was compiled from TypeScript and knows where the TypeScript source that it was compiled from lives. When you open the URL for the compiled form in your browser, when it loads it dynamically fetches the original .ts sources from elsewhere on the server and then puts that on the screen—maybe even going so far as to put it inside an editor that forms a TypeScript playground.