4 ms·

Skimming through the article, I don't get the value proposition. Is there a way to summarize it, please? Edit: importmaps is also in this entry, I found it str

Skimming through the article, I don't get the value proposition. Is there a way to summarize it, please? Edit: importmaps is also in this entry, I found it straighter to the point: https://news.ycombinator.com/item?id=34829039 https://news.ycombinator.com/item?id=34829039

mythz 4y ago
"An approach for building simpler JavaScript Multi Page Apps without an npm build system" Effectively we can use modern browsers native support of JavaScript Modules and Import Maps to create modular JavaScript Apps without a bundler. DHH has a good post of the benefits of this approach in "Modern web apps without JavaScript bundling or transpiling" [1] Which HEY has been running off for more than a year [2]. [1] https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755 https://world.hey.com/dhh/modern-web-apps-without-javascript... [2] https://world.hey.com/dhh/hey-is-running-its-javascript-off-import-maps-2abcf203 https://world.hey.com/dhh/hey-is-running-its-javascript-off-...
- galaxyLogic 4y ago
  Do import maps combine all scripts into a single download? I thought that was the main benefit of "bundling" multiple modules together.
  - mythz 4y ago
    No it's purpose is basically to define an alias for a JavaScript module so your source code can import by package name whilst the physical location of where it should import modules from is defined in an external importmap where it can be changed/maintained without needing to update source code that uses it. Docs for importmap is at [1]. Using JavaScript Modules means the browser can traverse the matrix of dependencies needed to efficiently download & execute just the modules it needs. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...
    - kohlerm 4y ago
      Therefore import maps do not solve all problems, bundling "compiler" solve. Even with HTTP/2 there is "some" overhead when loading lots of small files. There is also no tree-shaking e.g only loading functions which are really used.
      - WorldMaker 4y ago
        > There is also no tree-shaking e.g only loading functions which are really used. In most browser implementations ESM modules produce "proxy" objects that weak reference un-JITed code until used and will (eventually) garbage-collect portions of the module that aren't ever imported/used by other modules. This can be seen as a sort of "natural" tree-shaking at runtime.
      - mythz 4y ago
        They have different trade-offs sure, where bundling typically creates large opaque blobs of JS used by the entire SPA resulting in large initial download & parsing/execution time which is why it's preferable to only download & execute code needed which is easy to achieve with cohesive modules. The opposite of large JS bundles is a framework like Qwik [1] which achieves perfect PageSpeed scores by downloading the least JS possible, both initially and then at runtime by only downloading the JS needed per interaction, resulting in very small downloads over a lot more requests. [1] https://qwik.builder.io https://qwik.builder.io
      - Joeri 4y ago
        If the browser is smart enough to discover all the files it needs to request over the http/2 connection upfront there’s no real difference between downloading one big file and 100 little ones. Where you get into trouble is resources pulling in others with a dynamic import mechanism, which can start a slow cascade. There are various solutions, like preload tags, import maps, http/3 (which reduces stalling), and prebundled libraries or groups of libraries. As for lack of tree-shaking, that’s not an issue for smaller web applications. The libraries will be prebuilt and so are slim already, and you have perfect control over what is added which means there’s less that needs discarding. Also, most web applications struggle with image footprint, not js or css footprint. I think a medium to large SPA web app shouldn’t try this approach, but smaller web apps or ones that have a light client footprint may benefit from the simplicity of a no build frontend.

mythz 4y ago

"An approach for building simpler JavaScript Multi Page Apps without an npm build system" Effectively we can use modern browsers native support of JavaScript Modules and Import Maps to create modular JavaScript Apps without a bundler. DHH has a good post of the benefits of this approach in "Modern web apps without JavaScript bundling or transpiling" [1] Which HEY has been running off for more than a year [2]. [1] https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755 https://world.hey.com/dhh/modern-web-apps-without-javascript... [2] https://world.hey.com/dhh/hey-is-running-its-javascript-off-import-maps-2abcf203 https://world.hey.com/dhh/hey-is-running-its-javascript-off-...

galaxyLogic 4y ago
Do import maps combine all scripts into a single download? I thought that was the main benefit of "bundling" multiple modules together.
- mythz 4y ago
  No it's purpose is basically to define an alias for a JavaScript module so your source code can import by package name whilst the physical location of where it should import modules from is defined in an external importmap where it can be changed/maintained without needing to update source code that uses it. Docs for importmap is at [1]. Using JavaScript Modules means the browser can traverse the matrix of dependencies needed to efficiently download & execute just the modules it needs. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...
  - kohlerm 4y ago
    Therefore import maps do not solve all problems, bundling "compiler" solve. Even with HTTP/2 there is "some" overhead when loading lots of small files. There is also no tree-shaking e.g only loading functions which are really used.
    - WorldMaker 4y ago
      > There is also no tree-shaking e.g only loading functions which are really used. In most browser implementations ESM modules produce "proxy" objects that weak reference un-JITed code until used and will (eventually) garbage-collect portions of the module that aren't ever imported/used by other modules. This can be seen as a sort of "natural" tree-shaking at runtime.
    - mythz 4y ago
      They have different trade-offs sure, where bundling typically creates large opaque blobs of JS used by the entire SPA resulting in large initial download & parsing/execution time which is why it's preferable to only download & execute code needed which is easy to achieve with cohesive modules. The opposite of large JS bundles is a framework like Qwik [1] which achieves perfect PageSpeed scores by downloading the least JS possible, both initially and then at runtime by only downloading the JS needed per interaction, resulting in very small downloads over a lot more requests. [1] https://qwik.builder.io https://qwik.builder.io
    - Joeri 4y ago
      If the browser is smart enough to discover all the files it needs to request over the http/2 connection upfront there’s no real difference between downloading one big file and 100 little ones. Where you get into trouble is resources pulling in others with a dynamic import mechanism, which can start a slow cascade. There are various solutions, like preload tags, import maps, http/3 (which reduces stalling), and prebundled libraries or groups of libraries. As for lack of tree-shaking, that’s not an issue for smaller web applications. The libraries will be prebuilt and so are slim already, and you have perfect control over what is added which means there’s less that needs discarding. Also, most web applications struggle with image footprint, not js or css footprint. I think a medium to large SPA web app shouldn’t try this approach, but smaller web apps or ones that have a light client footprint may benefit from the simplicity of a no build frontend.