Not related, but is Notion becoming new Medium?
Reactive Clojure: A web language
71–80 of 185 posts
Re: Reactive Clojure: A web language
#72If you are trying to allure front end devs, maybe don't use tables in you example. To my taste, all of that is way too overcomplicated. I don't know why we need to make writing and maintaining web pages more complex with every year that goes by. To my mind, this industry looks completely derailed.
What would you use to represent tabular data like a list of T-shirt orders as in the example? That should be an HTML table. Using tables for positioning is bad in front end. Using HTML tables/sections/headers for document data structure is exactly what HTML is for.
Re: Reactive Clojure: A web language
#73Finally the problem which PHP solved more than two decades ago has been solved again. How do we include server-side code in client-side code? Do we build the client-side on the sever, and render? Why no, that would be PHP. Let's build the client-side in the browser, and rig a series of complex code-generating primitives disguised by the beauty of a language, to AJAX our way to a presumably good-enough solution. I thi…
PHP lets you have a piece of server code that can see the local variables of the client code it's enclosed in? And it's all reactive?
That's amazing!
Re: Reactive Clojure: A web language
#74Earlier quoted context omitted.
More work and learning basically in "front end" land, before you can do anything practical -- as usual.
Because software engineers are known for being people who are averse to learning and trying new things out.
As opposed to actually spending their time building useful practical things?
Re: Reactive Clojure: A web language
#75This is not reinvention of PHP as some are commenting. In fact I think this is extremely cool. If I understand it correctly, it allows you to achieve reactive data flow in a single page app without any boilerplate. Meaning - you update the database on the server and all the relevant UI(s) will automatically receive the updated data and re-render only the parts of the UI that display that data. This would require a to…
The problem with this type of system in my experience is that it’s great until you hit a bug, and then you realize you have no idea what’s going on under all the automagical stuff and you go crazy
Re: Reactive Clojure: A web language
#76This is beautiful. I used to think about this problem deeply. The best imaginary system I did imagine was: - A system that starts with our database schema - a language in the front-end that abstracts away server connection and db access - this imaginary language should allow defining react-like components but treat the db as a local datastore - Most clients are UI stricture interpolated with that user’s data queried…
>"- A system that starts with our database schema
- a language in the front-end that abstracts away server connection and db access"
Optimal data layout for storage and for processing / presentation can be quite different. Automatically mapping one to another I think can not be efficiently implemented in automatic fashion. I've tried different frameworks that claim to achieve it but at some point you always hit the wall. As a result I've long abandoned all those attempts and do manual transformation in code that are optimal for my particular situations
Re: Reactive Clojure: A web language
#77This 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…
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?
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.
Re: Reactive Clojure: A web language
#78This 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…
And http://opalang.org/
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.
Re: Reactive Clojure: A web language
#79Premature compositionally in the root of all evil, or something like that. I've looking for better ways to do document.createElement and addEventListener ever since the days of DHTML. Anyone looked into diagram theory already? The only productivity gain I've found is being fluent enough in your stack of choice to do the work to solve a problem and nothing more. And sure, spend the rest of your time researching diagra…
Would any of the 3+ people that dislike what I said like to explain why or is it more, like, "THE WAY YOU SAID IT", that is rubbing you faggots the wrong way :P.
Re: Reactive Clojure: A web language
#80One thing I admire about the Clojure community is audacious projects like this. While a ton of these seem to run out of steam, they certainly shoot for the stars and tend to come pretty dang close for a while.
For those working in Typescript, Blitz.js seems to do a great job at drastically decreasing the plumbing you have to write to shuttle data between Postgres and React. There’s also a ton of goodies like auth built in. From my first impression it’s the closest the JS community has ever come to a Django, and that’s very high praise in my book.