I don't think he minds the energy as long as we keep building his crazy vision of the future.

This is how he sees humanity, it's important for everyone to understand so we can agree to lock him up and throw away the key.

It’s building pyramids all over again.

LinkedIn is creepy even compared to Facebook imo.

And the content is the worst trash you'll find online, bottom of the barrel.

God help us!

Far from everyone are cut out to be programmers, the technical barrier was a feature if anything.

There's a kind of mental discipline and ability to think long thoughts, to deal with uncertainty; that's just not for everyone.

What I see is mostly everyone and their gramps drooling at the idea of faking their way to fame and fortune. Which is never going to work, because everyone is regurgitating the same mindless crap.

Delphi had a good thing going for a while, a ton of potential.

But they pivoted themselves out of that real fast...

Are they still sending the entire stream as an element? Thereby making dealing with that xml a lot more painful than it needs to be.

Back in the days, I had to write my own parser, existing xml parsers couldn't handle the case well.

There's plenty of middle ground here, you don't need fancy frameworks to do partial reloads.

I am open for suggestions, but anything wanting to give a desktop like experience is going to be complex. Like the user clicks a button, now widget a1 » a1.3 » a1.3.2 » a1.3.2.2 should be in an "open state", while widget b1 » b1.2 » b1.2.1 needs to be in "disabled state" and widget c3 » c4 » c5 shows a status message.

Sure, and the further you go in that direction, the more you're building a traditional desktop GUI experience, which was always a bad fit for the web.

So yes, if that's really what you want to do, React or similar is probably what you want.

If.

I used to do things like that with about 10 lines of jQuery.

But we as a species decided that jQuery bad :(

Likewise, I never liked JS much, nor the frontend dev experience.

I started out with the Seaside framework, but I've done several variations on that theme in different languages along the way.

It goes something like this: A typed server side DOM with support for native callbacks, generates HTML and hooks up callbacks. Changes are submitted to the server similar to traditional HTML forms, but using JSON. Changes to the DOM generate JS that's returned from the submit.

One headache with this approach is that documents need to stick around or callbacks will fail, and you need to hit the same server to get the document.

It should be doable to put a serialized version of the DOM on the client and passing that to callbacks to be rebuilt on the server.

I've been playing around with dropping most of the parens, but keeping the rest.

https://gitlab.com/codr7/shik

People have played around with those exact ideas for decades. No-one has ever come close to making it work.

It's working just fine here; but I'm not simply changing syntax, this is a ground up redesign.

Any thoughts on SRFI-119's syntax?

https://srfi.schemers.org/srfi-119/srfi-119.html

I don't think this is something that will happen inside of an existing language.

It needs to be a complete redesign where all parts pulls in the same direction.

It's not like it's changing by itself, you can always opt out of the slop race and scratch your itches instead.

https://gitlab.com/codr7/rem

A desktop playground [0] for a scripting language [1] I've been working on.

https://gitlab.com/codr7/rem

https://gitlab.com/codr7/shik