[pkage]

This reminds me of Meteor.js[0] from back in the day (2014?), which had a very similar approach—you wrote code that ran on both the frontend and the backend, and database updates were propagated automatically. It suffered from a pretty hard reliance on Mongodb and its own package manager (Atmosphere), and it was at odds with the rest of the JS ecosystem which was settling on NPM.

This project looks very cool! I like the focus on composition, Meteor was lacking that (and really, most other frameworks do as well).

[0] https://www.meteor.com/

[svachalek]

Yeah Meteor was an interesting example of an amazing project that fell into a hole based on a couple of bad decisions. It's basically fixed those at this point but become something pretty different in the process. It sounds like it may be something I can use now but I haven't tried it.

[strictfp]

Another big problem was that you rarely want exactly the same code on client and server.

[basch]

one that sort of fell by the wayside when Meteor and Ember got popular, was/is Derby.js/ShareDB. https://github.com/derbyjs/derby https://derbyjs.com/ https://github.com/share/sharedb

The LiveView lead resurgence in server side rendering is exciting. Does anyone have any insight as to why ShareDB never really took off?

[cjblomqvist]

Having been fairly close to the Derby.js project I'd guess that the difference between it and just using React and a web API just isn't that much in reality. Live updates of data isn't something most applications need (and very few parts of those that actually do). The added complexity is not to be underestimated, and there are some things inherit with live data which makes it more complex. What happens when one piece of data updates at an unexpected point in data, half-way through a method where you process something? Plus you still have the difference between backend and frontend, just that now it's more difficult to understand where and when what is run where under what conditions.

Then specifically for Derby/Share JS they didn't put enough resources into the project to make it good enough compared to the alternatives.

[zerr]

And http://opalang.org/

[daxfohl]

The language itself was a really interesting halfway point between typescript (near JS syntax) and purescript (stronger type system), before either existed. Plus some extra goodies thrown in.

It's really too bad they bound it so tightly to the framework, as I think there's a chance it could have succeeded as a language in itself. But these reactive shared-code things never seem to work out.

[leetrout]

I feel like Meteor lost a lot of ground to Firebase.

I think what we are seeing with these tools to make data synchronization in the frontend more invisible will continue to proliferate.

I am looking forward to the next, rich landscape of interactivity on the web powered by WASM, WebGL, etc.

[FractalHQ]

> I am looking forward to the next, rich landscape of interactivity on the web powered by WASM, WebGL, etc.

All of which will likely be a broken mess on iOS thanks to Apple

[aroman]

i think you mean WebGPU rather than WebGL. also WebTransport will play a big part for truly real-time interactive web apps

[leetrout]

Sure thing. Thanks.