Okay folks, i just spent the weekend coding a version of little kid's Lumberjack game that was programmed in React/Typescript (playable game at https://lumber-jack.netlify.com/). I did a high-fidelity clone of the React version in my Beads language, and published the results. The Beads version is here on GitHub (https://github.com/magicmouse/beads-examples/tree/master/Example%20-%20Lumberjack). Although the source code is comparable, the reduçtion in the number of source files from 13 to 1 is favorable, and the reduction of external API's referenced directly or indirectly from 1300 to 13 is 100:1 reduction in terms of dependencies. A big part of the problem with programming especially in the JS world is the horrible tangled web of interdependencies, which makes interchangeable parts impossible in the JS/framework space IMHO. If you have your own favorite language, why not try making the game yourself, the original React version has all the art and sound effect assets you would need already created. And if there are any lurkers on this group that would like to try Beads out please message me.

this is pretty interesting!

to use these modules, it requires a mishmash of magical tags in the source code like , , , <>,

was there supposed to be more examples there?

I don’t think that the comparison of number of files is a good objective measure. Many folks won’t necessarily prefer one monolithic file over something split into sensible modules.

It's nice to do comparison demos.. but I think the whole React / npm ecosystem is a bloated, under-designed, incoherent mess, so this is a bit like shooting fish in a barrel. You don't need the machinery of React and its extensions to make something this simple — just use the dang DOM, people! On the other hand.. I loved getting to finally see some Beads code! Thanks for posting that, Edward. It reads a lot like a minimal whitespace language like CoffeeScript, which I'm very fond of. Do you have a link to any document that outlines the syntax, statements/operators, and other core language features?

I suspect most programmers would prefer the react version simply because it looks less foreign.. all other advantages will sadly be secondary

"Less foreign" is ambiguous — They'll prefer the React version specifically because it has cultural momentum behind it. Recall, when React first blew up and people were seeing JSX for the first time, they lost their damn minds. It took a good while, a lot of Medium post advocacy, and more than a few Pete Hunt talks for people to get used to it. The culture has proven itself capable of adopting new ideas about syntax. It just takes a force capable of moving cultural norms. Popular music is a great comparison to study, since there's a lot of big-money machinery designed to bend the norms to its whims (akin to Facebook/Instagram in the React case), but it can also be moved by outsider individuals in the right place at the right time.

Yes, new syntax can be adopted.. if other attributes are compelling enough. But you're starting one step behind. For every 1 story about new things being adopted you can probably find 100 being rejected.

i would definitely like to try Beads out—i’m camping until monday, though

In this particular example, of a program of only 750-1000 words, it is a hindrance to comprehension to split a task this small into 13 pieces. If you imagine a project times larger, 130 files would be very unwieldy. Of course there is a point at which one splits things into submodules, but having lots of teeny files is very much an obstacle to comprehension.

i really like the array squared notation for 2d arrays

The term "al" is short for aliquots, which is a term from chemistry formulae where it refers to its proportional share of available space.

don’t understand how it works yet but really love the idea of proportional representation being first class

@Edward de Jong / Beads Project just a correction on the node modules, they’re not getting mutated by anybody, any mutation would mean a version change and your

yarn.lock

or

package-lock.json

file — depending on which package manager you’re using — will make sure that your project always contains the exact version of the modules you were working with initially unless you manually upgrade or update them

Unless they mutate the package but don’t bump the version number 😉. Or make a breaking change and only bump the patch or the minor number, or a bunch of other possibilities

It's also vastly more work to review the changes in versions of your dependencies (and their transitive dependencies) than it is to stay on top of changes in your (or your team's) own code. The culture of NPM (and rubygems, etc) is to just grab updates as they come out, to not review them (because if you're taking on hundreds of deps, and many hundreds or thousands of transitive deps, you clearly don't have the luxury of time), and trust that semver covers enough failure modes to make the risk worth it. Semver also doesn't, for example, cover the case of Angular 1 being largely abandoned by Google within a few years of its release in lieu of the totally redesigned Angular 2, requiring you to rewrite your app. Third party dependencies are by their very nature a Faustian bargain.

@Daniel Garcia it’s not possible to change the package without also changing the version. people can mess with minor and patch versions sure, but when you’re locked to a specific version it doesn’t matter to you

It’s possible on CI/CD environments, with every new build fetching the package version from

yarn.lock

, but the underline code being different in local/staging/production environments

I don't understand how freezing to a particular version is that great of a solution. If there is a bug in the external code that gets fixed, in order to get that bug fix you are going to have to upgrade to probably the latest version which indeed might force some rewrite. And if the tree of dependencies is large, who decides when it is safe or wise to upgrade the lower modules? Doesn't this basically cause you out of caution to freeze all this code? We have this problem all the time at my firm, where we use Asterisk/FreePBX/OpenVZ open source stack, and unfortunately in the case of OpenVZ the bug fixes we would like to take advantage of, break the software for several thousand virtual machines, and would take a huge effort to make the transition. Same thing with updates to FreePBX, it breaks all sorts of plug-ins which customers are using, and we aren't even aware of which ones will be broken. So we typically don't upgrade because it is too dangerous. We only upgrade when we have to. Not a perfect solution because security fixes aren't getting incorporated, and we are under constant attack by hackers (50 million break-in attempts per data center per day). In my Beads language, i have adopted a principle for the external modules that they are encouraged to stay tiny and focused, avoiding the fan-out of dependencies which i think is a huge problem. In the lumberjack example program that i converted from React, the React yarn.lock file had over 1300 dependencies, and the lock file was 40 times larger than the program! Also, let's not forget that all this fan out is building cognitive load on what these modules do. To understand what the subsystems do you then have to learn the subsystems they use. I want to totally understand my program from end to end, and not have it recede into gray as it gets deeper. There is no reason why a simple program like the lumberjack game cannot be completely understood by the author. It is only 700 words of code, that is like a short newspaper story. Should be a piece of cake to comprehend that. I want robust software that is rock solid and without an ounce of fat.

@Daniel Garcia yah, reproducibility between platforms is an issue. something that runs on os x might be slightly different on linux or not run at all on windows

React has the same problem jQuery had — people only learn the wrapper tool, and don't learn the underlying primitives, so they're unable to tell when the primitives are actually much simpler. That's how you end up with Stack Overflow posts like "How do you add two numbers in jQuery?" In the case of this lumberjack game, React and its ecosystem are colossal overkill. If you're building Instagram or Facebook, you'll want some infrastructure akin to React or Polymer, sure. But in that case, you're better to do what Facebook and Google did, and just build your own frameworks that you own and control. And in the case of this game, just build it using plain HTML, CSS, JS. It'll be small, maintainable, accessible (in multiple senses), and it'll still be somewhat relevant as an example in five years.

Ryan pointed out my ignorance of React. I suspect that the yarn file had more than just the transitive dependencies, it also carries the build toolchain which is also gigantic. I come from a commercial background where the companies i worked for strove to control every part of the codebase they could, not because they wanted to take care of more code, but because in a pinch they want to be able to fix anything. When you depend on some company, and they don't fix a showstopping bug quickly enough, you can get screwed royally. At least in the open source universe you have access to the code, and push comes to shove you can dive in to fix it. But to understand a system in its entirety, i think that most people agree that it is desirable to have as few dependencies as possible. The way people build libraries in the npm world tends to generate these giant balls of yarn, that are so vast as to be unknowable. i find a lot of people are using Meteor, Electron, React, Vue, etc., nowadays even for small projects. When you want to make something respond to screen resolution changes, regular CSS and JS are a disaster, because there is no arithmetic in CSS, and no IF statement to control layout in HTML. The #1 language stack (HTML/CSS/JS) used in the world today is really 3 incompatible languages rolled into one, where one can draw but not compute, and the other can style but has no IF statement, etc., is a bizarre historical artifact. The fact that these 3 languages don't agree on a line comment syntax is totally bizarre, and this crazy system cannot stand forever as the primary language; it is simply too mediocre a design to endure. Sure, it can proliferate like COBOL did, but who now starts a project in COBOL? nobody.

I'm working on the replacement of html/css/js.. it's called.. WebAssembly! (+WebGPU 🙂 And I'm only half kidding

Yeah, I'm writing GLSL by hand right now (ugh) and thus I'm very eager to see WebGPU evolve. Hopefully they can come to some consensus around it, the way they did with WASM.

@Wouter which half are you not kidding about?

@Ivan Reese WebGPU will likely be harder to program directly than WebGL+glsl.. it will also come with a shading language etc. But importantly it will be faster, so any friendly rendering library built on it will be better too

@Wouter to supplant rendering to the DOM with html/css, we will need a rich UI framework with wide usage. Do you see anything emerging to fill that role?

with WebGPU, anyone can design one.. I don't see why it needs wide usage, as each project can pick one individually

In my world, Flutter and SwiftUI are the most attractive future for UI. Would love to see a clone in WASM

if those are good UI designs, chances are, someone is going to end up making them for Wasm 🙂

@Ivan Reese “There’s so, so much post hoc rationalization of using these industrial scale tools like React at commercial or personal scale, probably because people have scale envy or tool obsession — I know I’ve got that, at least.” It makes total sense that people want to use industrial tools. When I switched from BASIC to C (an “industrial tool”) I programmed in C stuff that I could have had used BASIC for with more ease. Part of it is to learn the industrial tool, and part of it is because I’d rather even forget the limited tool if it may reduce my cognitive load which is already burdened with an abundance of stuff

Still rocking jQuery over here for my light DOM manipulation needs.

(Deleted some messages I wrote in a hurry while holding a baby. Decided they didn't add to the conversation.)

William: modern bowsers now support document.querySelector, which handles most of the basic stuff that JQuery used to be used for

@Dan Cook thanks, I am well aware. But it is good for a person to know about

querySelector

and

querySelectorAll

in case they're doing something especially light — don't want to have any external dependencies. Still I find jQuery's monadic semantics are just the right level of power/magic for me: better than iterating across a NodeList.

I wrote my own DOM manipulation library because I found my own sweet spot of concision, performance tricks, and abstraction. It's so short, and so stable, I often just copy-paste it into projects instead of pulling it down with yarn. It scratches a React-shaped itch with a JQuery-shaped stick, but I own that damn stick and nobody else is going to touch it. But that's besides the point. The point is — I want to see more of Beads, so I can learn what sort scratchers it features.

@Ivan Reese can I take a look at your DOM manipulation library? I’m more and more leaning towards minimalist dependencies and sounds exactly like something I’d like to give a try

same

same. Maybe you can put it on GitHub, even as just a code snippet?

@Daniel Garcia @Garth Goldwater @Dan Cook — It lives here: https://github.com/ivanreese/DOOM I just whipped up the README and don't know how helpful it is, so send me a DM here if you have questions. PRs welcome. The code isn't too thorny, but it was definitely written under the expectation that the only reader would be future me, haha.

@Ivan Reese you have such an unusually clear style of writing what i’d consider fairly procedural code. really like the way your brain works

Haha, thanks!? I would not kiss my mother with that code. I'm much, much happier with how my module system micro-library reads (https://github.com/cdig/take-and-make), but that's just me. I find CoffeeScript to have the most readable syntax of any language I've worked with. I love it.

Of yeah, CoffeeScript! It was a nifty surface syntax, forgot about CoffeeScript.

tried to make a PR to fix formatting on www.rust-lang.org. cloned the repo, ran cargo, 350+ deps, 7000+ files.

This kind of geometric explosion of dependencies is what makes the largest software we use so horribly complex and basically unmaintainable. I recently encountered an intermittent bug in Safari, where including a module in the current folder fails. It goes into Apple's bug database, and never gets fixed. I can imagine that Safari browser is the millions of lines of code. The problem is that massive redundancy occurs because programmers cannot connect interchangeable parts, but instead keep importing packages, which duplicate sub-functions over and over. I would wager that 90% of Safari is effectively duplicated code.

@Greg Jarmiolowski does it not just run

rustfmt

over everything?