31–40 of 185 posts
Earlier quoted context omitted.
Claiming "this is PHP" misses the point entirely, which is turning PHP-like templates into apps that can react to user input
There has got to be a better way of achieving reactive templates than what is described in this project though.
It had me at the title "You don't need a web framework, you need a web language" but then it immediately dived into arbitrary syntax instead of exploring in abstract what a modern web language would entail.
Yeah I had a really hard time understanding even with the backend frontend highlighting
Clojure and Clojurescript are the same language (more or less). They just target the JVM or Javascript.
The author is mixing the frontend (Clojurescript and Reagent) code with the backend (Clojure and Datomic) code in the same expression. Then through their magical system and the beauty of lisp, they pull the frontend and backend parts out to serve them separately.
looks very overcomplicated for generating an html table, building something more powerful would result in even more complex code. There's a reason why these things get decoupled
This is true, but I also think it's worth evaluating whether the lines along which we've been decoupling applications is the right one. Typically, the line of demarcation has been the client/server boundary, for a bunch of reasons: security considerations (it's also a trust boundary); different computational environment. This split has reinforced itself with the organization of companies into frontend/backend teams.
But there are a bunch of things that it makes a pain-in-the-ass. I've encountered this most with data-heavy apps, where I want to do some analysis on the server (e.g. Python/Pandas), but I want low-latency recalculations on the client in cases where the data is small enough. Doing it “right” requires implementing the same data-level logic in both Python and Javascript. Nobody has time for that, so we end up in our current world of laggy janky SaaS that needs to run off to the server every time you click a button.
Which is to say, I'm excited that people are looking at alternatives (not just this; LiveView was on HN yesterday as well).
Earlier quoted context omitted.
Claiming "this is PHP" misses the point entirely, which is turning PHP-like templates into apps that can react to user input
There has got to be a better way of achieving reactive templates than what is described in this project though.
The general idea being to abstract away the difference between client and server code, so that you can write code that handles both, in a single file.
> There has got to be a better way
What's offensive about the OP to you? Is it just that you don't like functional programming / Clojure (fair, that's ultimately a matter of taste / aesthetics at some level)? Or is there something about the technical implementation you think is suboptimal?
Premature 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…
Maybe I’ve been in Node.js land too long, but I don’t get why this is better for my productivity or my ability to create efficient web apps.
However I think it’s missing the point of de-coupling. Security would be very hard to reason about, as would handling of intermittent network connections when the real structure of the client and server are abstracted away from you.
Ultimately I think GraphQL with live queries is the best model for this type of reactive work. You get a decoupled client/server, reactivity, support for mobile clients as you have an API, as well as full type-safety on the client.
Nonetheless I applaud the creativity on display here and I hope I’m proven wrong. Maybe this will be the next paradigm shift? Who knows
As a web developer with 25 years of experience and (I thought) up to the minute skills ... I have no idea what any of that means but it sounds cool and important and I want to try it.
This project looks very cool! I like the focus on composition, Meteor was lacking that (and really, most other frameworks do as well).
Finally 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…