Opinion: If we want a "small tech" movement seperate from big tech, that doesn't rely on the master's overcomplicated tools to dismantle the master's house, JavaScript can only be a stopgap to reach people where they are today.

Are you aware how much code goes into implementing JavaScript? Or it's APIs? How much ingenuity it takes to run anywhere near as fast or securely as C?

Only Big Tech has enough coordinated manpower to implement JavaScript as it exists today!

Me and Aral disagree here.

Much as I like a lot of Aral Balkan's rhetoric, and rewatching him discuss the sad state of modern browsers, I just end up reflecting back to arguing with him regarding JavaScript.

He, like some others I've heard, think we need JS to build peer-to-peer technologies ontop of.

I envy you for not digging into how your dependencies work, not finding out how much JS epitimizes Big Tech. The eldritch horror drove me nuts!

Sure use JS as a stopgap, but longterm let's move away from it. Please?

Show thread

@alcinnz This pretty much sums up my gripes with his position. Like, his analysis is basically right but he's approaching things on the wrong level.

And I mean I have that problem too, to a degree since I too do webstuff, but at least I'm foregoing JS to make things less horrible. The web could be nice, if it wasn't abused as platform for the delivery of untrusted applications…

@phryk Yeah, I saw toots this morning saying the most innovative thing a new platform can do now is not have a web browser.

Here I am beavering away to make the web an enabler of innovation rather than disabler...

@alcinnz @phryk I think a plurality of solutions at different levels is a good thing. They're not necessarily incompatible in mission..

@theruran @alcinnz @phryk that plurality is key, and also not to let perfect be the enemy of good (enough).

The underlying concepts of #smalltech and #smalltech are what matter most. And each one gives their own swing at that. Stopgaps are okay.

Re: JS low-barrier.. given site.js target audience (end-people, any-devs) and KISS approach isn't (node)js a valid choice? Should it be e.g. Haskell?

Imho its valid, though I hate node's dependency hell thingy.

#dat #p2p in node.js is another matter.

@humanetech @theruran @alcinnz @phryk for me, JavaScript is nice place to start, but bad place to stay for long time. Because the "KISS" we see is just an illusion, created by actually running a virtual machine...

@alex that is true, and I agree but given the requirements and that for Aral as experienced dev this was already a dedicated year's work of programming, what would have been better choices? PHP maybe?

(Discussing technology choices tends to go into religious beliefs. The key is *this* choice's validity, in current tech environment)

@theruran @phryk @alcinnz

@humanetech @alex @theruran @phryk And besides maybe one day someone can try running it on a JavaScript engine that's slower but significantly simpler?

The complexity is all down to our expectations of performance.

Follow

@alex @theruran @phryk @alcinnz @humanetech

imo, the problem with JavaScript from a perspective isn't that it's running in a VM – it's that it's running in a VM *written in 2 million lines of C++*.

That means there's no on-ramp for people who develop *in* javascript to become people who develop javascript. Which keeps big tech dominant

In comparison, many self-hosted/bootstrapped languages encourage users to engage in compiler hacking, which further encourages simplicity in design

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.