You can check -> https://generator.jspm.io for generating these import-maps w.r.t to CDN's
Modern SPAs without bundlers, CDNs, or Node.js
51–60 of 170 posts
Re: Modern SPAs without bundlers, CDNs, or Node.js
#52Earlier quoted context omitted.
> If you take time out every now and then to completely refactor your code base it can actually be surprisingly effective. So much this! Current project I'm on, I own the entire front end for a major modernisation (AKA rewrite) of a legacy application and we are working in 4 week "sprints". I'm giving myself two days every month just to refactor the code I wrote that month. How you plan to structure a project never w…
> How you plan to structure a project never works out, you always find better ways as you go and as the objective and priorities change (they always do). I always joke I write everything three times. The first time to get a feel for the space, the second time because I think I now understand it and then again when I finally really understand it. Most of the times these three look absolutely nothing like each other.
I think that even extends over longer time periods to projects as a whole and an evolving team. Sticking to my current project which has a nearly 20 year legacy and looks nothing like what it was when it started:
V1: Perl CGI, HTML forms, very little js
V2: Perl CGI, JQuery, Ajax (done badly with js code generated by Perl code)
V3: Perl backend rest API (will be "public"). TypeScript+Vue front end.
Each time a transition has happened as the application features have outgrown the architecture, and more has bean learnt about how people use the product and therefore what it needs to do.
In this case it has now grown the the point that Node and build tools are required.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#53On the same topic, I wrote some articles a while ago. Here is my own approach for making a VanillaJS SPA without using any bundlers or frameworks https://rishav-sharan.com/#/making-a-spa-in-vanilla-js Note that this blog right now converts markdown posts into html at runtime, which is definitely not an efficient way of doing things. But considering that I have just a handful of people landing there, I really haven't…
Just wanted to say I enjoyed reading this. Thanks for sharing.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#54If you use normal includes instead of imports, and put an object (or better a closure) on the top as a namespace, your SPA will work with any browsers, and you don't force your users to throw out their phones and laptops every 2-5 years.
You could also just use a polyfill (es-module-shims) to add support for older browsers.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#55I'm a fan of this actually. Thanks for introducing me to importmap type!
Re: Modern SPAs without bundlers, CDNs, or Node.js
#56Import maps strike me as a huge win for making prototypes, or things where you control what exactly you're importing (eg from a private registry instead of NPM), but throwing out the bundler and more importantly the tree-shaking and minification steps of bundling, will result in a massive about of unused code being delivered to the user. You'll be relying on maintainers putting minified, unbloated assets in their packages and ... well ... NPM is gonna NPM.
Re: Modern SPAs without bundlers, CDNs, or Node.js
#57If you use normal includes instead of imports, and put an object (or better a closure) on the top as a namespace, your SPA will work with any browsers, and you don't force your users to throw out their phones and laptops every 2-5 years.
You could also just use a polyfill (es-module-shims) to add support for older browsers.
[deleted]
Re: Modern SPAs without bundlers, CDNs, or Node.js
#58Earlier quoted context omitted.
> How you plan to structure a project never works out, you always find better ways as you go and as the objective and priorities change (they always do). I always joke I write everything three times. The first time to get a feel for the space, the second time because I think I now understand it and then again when I finally really understand it. Most of the times these three look absolutely nothing like each other.
I think that even extends over longer time periods to projects as a whole and an evolving team. Sticking to my current project which has a nearly 20 year legacy and looks nothing like what it was when it started: V1: Perl CGI, HTML forms, very little js V2: Perl CGI, JQuery, Ajax (done badly with js code generated by Perl code) V3: Perl backend rest API (will be "public"). TypeScript+Vue front end. Each time a transi…
Neat, is this a public project. You make me curious what it is that you are hacking away at!
Re: Modern SPAs without bundlers, CDNs, or Node.js
#59On the same topic, I wrote some articles a while ago. Here is my own approach for making a VanillaJS SPA without using any bundlers or frameworks https://rishav-sharan.com/#/making-a-spa-in-vanilla-js Note that this blog right now converts markdown posts into html at runtime, which is definitely not an efficient way of doing things. But considering that I have just a handful of people landing there, I really haven't…
Nice work, and nice writing too!
Re: Modern SPAs without bundlers, CDNs, or Node.js
#60To go quite a bit off topic. The author says that he starts with a single html file and splits it or incrementally adds stuff when needed. That course of action has proven to be a really bad idea on every non trivial web project I worked on. Mostly for teamwork and maintainability reasons. E.g there is no clear project structure, the next dev will not understand stuff and do things differently. And welcome to the cha…
You are optimizing for entirely different use cases.
There are a whole bunch of devs who work alone or in (very) small teams. For this type of work it’s really more of a hindrance to have an imposed structure and tooling.
We want to get to your goals as efficiently as possible. Minimal abstractions, guidelines, tooling, indirection, magic, surprises and general overhead are in order. We don’t want to struggle with questions like “how to do this in X”. We already know how to do it, so we just do it.
As time goes on and LOC get merged we find ways to add sensible structure and compress our code.