|
|
|
|
|
by rictic
2355 days ago
|
|
I get framework and tooling fatigue, but it seems misaimed here. This project is an attempt at minimizing complexity, not adding onto it. There's a fundamental problem with writing JS for the browser: how do you expresses your dependencies? jquery-era code solved this by just putting the dependencies in the README of a project (e.g. "this project requires jQuery and jQuery UI version 3! load them before loading this script!"). It worked, but it was error prone and manual. More recent code has solved it by writing code that used abstract specifiers, like require('jquery'), which meant that you needed to use a complicated and often hyperconfigurable bundler to run in the browser (because the browser can't go searching the filesystem to figure out where the code for the 'jquery' package is) With ES modules we're almost there, browsers can import files now, but they still need a bit of additional info to tell them how to resolve underspecified modules like 'jquery' (as opposed to './utils.js' which they can handle with no problem). You can write your code with fully specified imports, but the difficulty is that that code doesn't travel well, e.g. if you write `import '../node_modules/jquery/jquery.js'` that won't work if someone uses your package as a library, because jquery.js will actually be at '../jquery/jquery.js' because your package lives in the node_modules directory. |
|
because literally just putting them in a folder somehow became insufficient for any number of reasons, some of which seem to have to do with JS's lack of an include() function like every other interpreted language has had since forever
like, how about i don't need 20,000 dependancies, and just use an application stack that includes normal things like trimming a string