4 ms·

I've been experimenting recently, with quite some success, with having a 'libs.js' file that pulls in and re-exports everything external I want, and providing a

by mst 2y ago

I've been experimenting recently, with quite some success, with having a 'libs.js' file that pulls in and re-exports everything external I want, and providing a script that applies 'bun build' to just that. I haven't yet decided if/how I want to include a prebuilt version of it in the repo, I *think* I may go the approach of having a commit that modifies libs.js and/or the lockfile and then an immediately following one that commits an updated prebuild ... oh, huh, actually, I should probably also consider doing those two commits on a branch, then forcing a merge commit so they land on master atomically but it's easy to tease out the human changes and the regen changes by poking inside said merge commit ... yeah, like I say, still thinking about exactly how to do this, don't mind me. Also for even simpler cases I've been using the preact-htm prebuild directly, since htm gives a lit-style html() tagged literal consuming function that can produce vnodes for preact so I can mess around without needing something that understands jsx between my editor and my browser window. vue's component system is IIRC noticeably less nice to work with if you don't have a compile step, but it's still pretty nice even without that so please don't think I'm trying to dissuade you here :)

em-bee 2y ago
note that my websites/apps are completely free of anything to build. the source that is used for development which goes into the repo is what is being loaded into the browser without change. saving a prebuilt version of code that needs building is of course also helpful, and much better than having to rely on keeping your build tools working. but when you want to make changes to the site you have to either deal with the build tools anyways or work with the prebuilt version which may not be as practical. either way i would simply save the prebuilt version to a branch and if any changes are made in that branch cherrypick them over to the dev branch if they even can be use, which i am not sure about. i'd probably rather avoid making changes to the prebuilt code in the first place how does lack of a compile step affect the code? are there things i won't be able to do if i don't compile? i haven't started yet, and my website is not very complex so i think i'll manage either way, but i am curious. can you link to an example?
- mst 2y ago
  I understood what you were doing, yes. However you said you're using a prebuilt version of the aurelia framework - and I'm using only using a prebuilt version of the frameworks I'm using. Which seems pretty equivalent to me, except that your framework prebuild is created by somebody else running a script and my framework prebuild is created by me running a script. Either way the result is a single framework file to load that gets treated as basically a black box from then on. My actual application sources are being direct loaded unchanged just like yours are. The difference is basically syntax - vue recommends (and most example and/or real world vue apps I've seen use) their Single File Component syntax, and *that* requires a build step - see here for the difference in that and the build-free definition syntax: https://vuejs.org/guide/essentials/component-basics.html#defining-a-component https://vuejs.org/guide/essentials/component-basics.html#def... As I hope I managed to make clear, not a big deal at all in the grander scheme of things, just something to be aware of.
  - em-bee 2y ago
    "your framework prebuild is created by somebody else running a script and my framework prebuild is created by me running a script." you are right, i didn't read it that way, but i get it now. i forgot about that aspect of vue, but if i read that correctly the joke is on them because the single file component syntax is one reason i initially rejected vue. i felt that it would make editing harder because editors would need special support to handle the file format. although looking at it now, it doesn't look so bad. it's just html with inline javascript. anyways it looks like instead of inline templates i can also reference external templates and that would let me structure the code the way i want. you are right, it's not a big deal in the grand scheme of things, and even from someone being prejudiced against the component syntax, it is a tiny issue compared to all the other good or bad choices a framework can make. thank you for the link.
    - mst 2y ago
      Yeah, I can see how you read my initial comment, and given the combination of "I could probably have been clearer" and "my approach does not seem to be one people take very often" it makes sense for you to've read it how you did, hence me turning the verbosity up to 11 for my second attempt at explaining it :D Given the javascript is still inside a <script> tag I would presume any editor that can handle a normal HTML page with some inline javascript wouldn't notice the difference, yeah. Hadn't honestly though of that since one of the first things I do in any editor is turn all the file format handling stuff off because I'm a curmudgeon who thinks in https://github.com/n-t-roff/heirloom-ex-vi https://github.com/n-t-roff/heirloom-ex-vi Yes re external templates; my usual approach to 'keeping the code and template close together' is to have them open in adjacent 80x24 xterms. You might find mobx of interest - I tend to use that for state modeling no matter the framework doing the rendering - everybody seems to be getting very excited about 'reactive signals' these days and ... they basically all have their own implementation that feels, to me, like Yet Another NIH Of A Tiny Subset Of MobX ... except invariably missing at least one feature that I really wanted. Which is how I ended up with my own libs.js on a current project, the sum total of which is export { render, createElement, options as 'preactOptions', Fragment } from 'preact'; export { observable, action, computed, flow, createAtom, Reaction } from 'mobx'; export { observer } from 'mobx-preact'; and then on the fairly sporadic occasions that I need to adjust the exports I have a shell script that does a tiny bit of bookkeeping and then runs bun build --format=esm src/web/libs.js >bundle/web/libs.js so I run that, and then go back to forgetting that the build process (and the node_modules directory it's sourcing those libraries from) exists. I also have about 20 lines' worth of custom dev server that will serve the bundle/ file preferentially over the src/ file if it exists, plus a couple other minor things. But this is, for me, all about keeping things as simple as possible barring some slight effort towards ergonomics, plus knowing that I understand every part of what's going on so I don't end up stuck in a "one of my abstractions is leaking and I've no -ing idea how or why" type situation (hence also my very minimalist choice of editor, any time I try a more clever one I fairly rapidly end up in a situation where the tab completion does the wrong thing so I just type everything out anyway, or where the syntax hilighting produces colours that give me a headache, or ... just colour me a curmudgeon who learned his chops on ancient BSDi and Solaris systems, I don't expect anybody else to want to use my dev environment but it works for me). Anyway. None of this is to try and convince you of anything much, I just thought you might find my setup vaguely interesting. I'll stop waffling now :D

by mst 2y ago

em-bee 2y ago

note that my websites/apps are completely free of anything to build. the source that is used for development which goes into the repo is what is being loaded into the browser without change. saving a prebuilt version of code that needs building is of course also helpful, and much better than having to rely on keeping your build tools working. but when you want to make changes to the site you have to either deal with the build tools anyways or work with the prebuilt version which may not be as practical. either way i would simply save the prebuilt version to a branch and if any changes are made in that branch cherrypick them over to the dev branch if they even can be use, which i am not sure about. i'd probably rather avoid making changes to the prebuilt code in the first place how does lack of a compile step affect the code? are there things i won't be able to do if i don't compile? i haven't started yet, and my website is not very complex so i think i'll manage either way, but i am curious. can you link to an example?

mst 2y ago
I understood what you were doing, yes. However you said you're using a prebuilt version of the aurelia framework - and I'm using only using a prebuilt version of the frameworks I'm using. Which seems pretty equivalent to me, except that your framework prebuild is created by somebody else running a script and my framework prebuild is created by me running a script. Either way the result is a single framework file to load that gets treated as basically a black box from then on. My actual application sources are being direct loaded unchanged just like yours are. The difference is basically syntax - vue recommends (and most example and/or real world vue apps I've seen use) their Single File Component syntax, and *that* requires a build step - see here for the difference in that and the build-free definition syntax: https://vuejs.org/guide/essentials/component-basics.html#defining-a-component https://vuejs.org/guide/essentials/component-basics.html#def... As I hope I managed to make clear, not a big deal at all in the grander scheme of things, just something to be aware of.
- em-bee 2y ago
  "your framework prebuild is created by somebody else running a script and my framework prebuild is created by me running a script." you are right, i didn't read it that way, but i get it now. i forgot about that aspect of vue, but if i read that correctly the joke is on them because the single file component syntax is one reason i initially rejected vue. i felt that it would make editing harder because editors would need special support to handle the file format. although looking at it now, it doesn't look so bad. it's just html with inline javascript. anyways it looks like instead of inline templates i can also reference external templates and that would let me structure the code the way i want. you are right, it's not a big deal in the grand scheme of things, and even from someone being prejudiced against the component syntax, it is a tiny issue compared to all the other good or bad choices a framework can make. thank you for the link.
  - mst 2y ago
    Yeah, I can see how you read my initial comment, and given the combination of "I could probably have been clearer" and "my approach does not seem to be one people take very often" it makes sense for you to've read it how you did, hence me turning the verbosity up to 11 for my second attempt at explaining it :D Given the javascript is still inside a <script> tag I would presume any editor that can handle a normal HTML page with some inline javascript wouldn't notice the difference, yeah. Hadn't honestly though of that since one of the first things I do in any editor is turn all the file format handling stuff off because I'm a curmudgeon who thinks in https://github.com/n-t-roff/heirloom-ex-vi https://github.com/n-t-roff/heirloom-ex-vi Yes re external templates; my usual approach to 'keeping the code and template close together' is to have them open in adjacent 80x24 xterms. You might find mobx of interest - I tend to use that for state modeling no matter the framework doing the rendering - everybody seems to be getting very excited about 'reactive signals' these days and ... they basically all have their own implementation that feels, to me, like Yet Another NIH Of A Tiny Subset Of MobX ... except invariably missing at least one feature that I really wanted. Which is how I ended up with my own libs.js on a current project, the sum total of which is export { render, createElement, options as 'preactOptions', Fragment } from 'preact'; export { observable, action, computed, flow, createAtom, Reaction } from 'mobx'; export { observer } from 'mobx-preact'; and then on the fairly sporadic occasions that I need to adjust the exports I have a shell script that does a tiny bit of bookkeeping and then runs bun build --format=esm src/web/libs.js >bundle/web/libs.js so I run that, and then go back to forgetting that the build process (and the node_modules directory it's sourcing those libraries from) exists. I also have about 20 lines' worth of custom dev server that will serve the bundle/ file preferentially over the src/ file if it exists, plus a couple other minor things. But this is, for me, all about keeping things as simple as possible barring some slight effort towards ergonomics, plus knowing that I understand every part of what's going on so I don't end up stuck in a "one of my abstractions is leaking and I've no -ing idea how or why" type situation (hence also my very minimalist choice of editor, any time I try a more clever one I fairly rapidly end up in a situation where the tab completion does the wrong thing so I just type everything out anyway, or where the syntax hilighting produces colours that give me a headache, or ... just colour me a curmudgeon who learned his chops on ancient BSDi and Solaris systems, I don't expect anybody else to want to use my dev environment but it works for me). Anyway. None of this is to try and convince you of anything much, I just thought you might find my setup vaguely interesting. I'll stop waffling now :D