4 ms·

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, an

by pkage 5y ago

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/ https://www.meteor.com/

leetrout 5y ago
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 5y ago
  > 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 5y ago
  i think you mean WebGPU rather than WebGL. also WebTransport will play a big part for truly real-time interactive web apps
  - leetrout 5y ago
    Sure thing. Thanks.
strictfp 5y ago
Another big problem was that you rarely want exactly the same code on client and server.
basch 5y ago
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://github.com/derbyjs/derby https://derbyjs.com/ https://derbyjs.com/ https://github.com/share/sharedb 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 5y ago
  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.
svachalek 5y ago
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.
zerr 5y ago
And http://opalang.org/ http://opalang.org/
- daxfohl 5y ago
  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.

by pkage 5y ago

leetrout 5y ago

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 5y ago
> 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 5y ago
i think you mean WebGPU rather than WebGL. also WebTransport will play a big part for truly real-time interactive web apps
- leetrout 5y ago
  Sure thing. Thanks.

strictfp 5y ago

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

basch 5y ago

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://github.com/derbyjs/derby https://derbyjs.com/ https://derbyjs.com/ https://github.com/share/sharedb 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 5y ago
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.

svachalek 5y ago

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.

zerr 5y ago

And http://opalang.org/ http://opalang.org/

daxfohl 5y ago
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.