Of course, it's pretty easy to see through this: introduce law in a few states, but now every OS needs to comply and because it's hard to actually tell which country/state user is in, they'd just have to implement it for everyone. It will be verification through some third party. You can opt out, but then major websites will be forced to deny you access (by, for example, Cloudflare) unless your OS provides a verified and signed certificate of your age. Then it's done: nothing will be possible without an ID, which means no dissent will be tolerated.
I don't understand the hype around CI and that it's supposedly impossible to run something like that without Git, let alone Github. Like sure, a nice interface is fine, but I can do with a simpler one. I don't need a million features, because what is CI (in practice today, not in theory)? It's just a set of commands that run on a remote machine and then the output of those commands is displayed in the browser and it also influences what other commands may or may not run. What exactly is the big deal here? It can probably be built internally if needed and it certainly doesn't need to depend on git so much - git can trigger it via hooks, but that's it?
I think the real problem is we were sold all these complex processes that supposedly deliver better results, while in reality for most people and orgs it's just cargo culting, like with Kubernetes, for example. We can get rid of 90% of them and be just fine. You easily get away without any kind of CI in teams of less than 5-7 people I would argue - just have some sane rules and make everyone follow them (like run unit tests before submitting a PR).
> what is CI (in practice today, not in theory)? It's just a set of commands that run on a remote machine and then the output of those commands is displayed in the browser and it also influences what other commands may or may not run. What exactly is the big deal here?
The key is hermetically/reproducibly - you don't want to run commands on some random machine, you want to run commands on a well-controlled/versioned machine that won't change under you, that you can recreate at will. Which sure you should be able to do with Nix or something, but the kind of person who doesn't want to use CI doesn't want to use Nix either.
And the other key is whose machine? Particularly when it comes to e.g. Macs, which are expensive. Maybe you have a spare server farm in your closet, but most people don't.
For a solo dev, what are the advantages of _not_ building on your own machine?
Is the compiling and test running too resource intensive?
Do you build every commit? If so, why?
I see the value in larger teams, but for solo stuff I just find it slow and annoying. I'm using go, and it compiles fast, so that could be a part of it.
> For a solo dev, what are the advantages of _not_ building on your own machine?
I end up with all kinds of random crap on my own machine. It's very easy to accidentally e.g. globally install a library that wasn't properly listed in my dependency management. So having a separate standardised/controlled build environment is a good way to catch those. It also helps with flaky tests or random "works on my machine" problems - this way my tests are at least getting run on two quite different machines (different OS/arch/etc.)
Ok, that solves like 20% of the problem. How (and where) are you provisioning these VMs? How are you managing what versions of what are installed on them, and is that process reproducible?
None of this is hard, exactly, but you do have to put in the legwork of doing it, and it's mostly only the big players who've done so.
It's not rocket science. As I said, it's a case of doing the legwork. But you do have to actually do the work rather than just handwave it away. Ok, your VM manager allows you to clone from a disk and maybe allows you to have an overlay layer. Great. Now draw the rest of the owl.
The big deal is that GitHub provides it for free. Plus it integrated properly into the PR workflow.
Good luck implementing merge queues yourself. As far as I know there are no maintained open source implementations of merge queues. It's definitely not as trivial as you claim.
Alpine/htmx are great, but they're more "sprinkle behavior on HTML" tools. Qite is closer to a structured component system: explicit events, a state engine, and a consistent way to wire parts/fields/children together without ad-hoc glue.
You can build similar things with Alpine/htmx, but once things grow, you end up reinventing structure. Qite just bakes that in from the start.
What you probably saw isn't code in quotes, but simply matchers like `price: "isPresent()"`. The () is there to signal it's a matcher, not a value. If this matcher doesn't exist, you'll get an error. The reason I chose () to signal it's a matcher is to distinguish it from values. Maybe there's a better way to do it.
Yeah, I get the reaction. It's not JavaScript, it's simply a way to reference a matcher for the value, not match against literal value. You can totally use your custom matcher like this:
Thank you. Since you had this positive reaction to which I very much relate, may I ask you what did you personally think was confusing in the docs that may still turn people away?
Btw, looking back at the index page, I think I might have made the initial example a little bit too much (because realistically, you don't often get components that complex). If you guys want a simpler saner example, the one the second page looks nicer: https://qitejs.qount25.dev/Explained-by-ducks.html
Yeah, several apps have been built with it, but they're not public (or not public yet). Also, Qite.js has a number of prebuilt-components. I haven't gotten around documenting them, but you can find working example here:
It's a bit more nuanced than that. State in Qite is held both in HTML and in JS Component. The html serialization is sort of consequence of changing a field (like when you want to update textarea content, for example). You can completely ignore it or you can also use it for CSS, for example. Another usecase is when user interacts with the pages, changes text in said textarea and it also automatically updates the JS Component field. Finally, there are also flags, which aren't stored in DOM. I'd like to point out this architecture isn't random, it came from building apps and realizing how everything interacts.
It works better than "just like" in the sense that it also takes care of things like CSRF, POST/GET params, request/response types etc for basically free.
reply