If 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.
Reactive Clojure: A web language
111–120 of 185 posts
Re: Reactive Clojure: A web language
#112This 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…
> Imagine a programming language runtime whose runtime state (i.e. lexical scope) is partially broadcast over network as it happens, kind of like a remote debugger. This sounds absolutely terrifying from a security perspective... What's to stop a malicious client from broadcasting code that deletes my entire database?
Unfortunately (or fortunately) it's also a corner-stone of computing in general
Re: Reactive Clojure: A web language
#113Earlier quoted context omitted.
Or Calva for VS Code. It's the best dev environment I've used for any language. It's brilliant.
Calva always exploded on me when I tried to set it up on Windows 10. Is it better on a *NIX system?
Re: Reactive Clojure: A web language
#114We kinda have that with livewire[1] and inertia[2] and as awesome as they are (no separate api etc) they also suffer from the “magic”
[1] https://laravel-livewire.com/ [2] https://inertiajs.com/
Re: Reactive Clojure: A web language
#115As 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.
More work and learning basically in "front end" land, before you can do anything practical -- as usual.
Re: Reactive Clojure: A web language
#116Earlier quoted context omitted.
> At first glance, this appears to be much more complex. React is a relatively simple DOM diffing library. Their implementation is 2k lines of code. The React repo has 350k lines of code. The Rails repo has 336k lines of code (both of those according to tokei). Of course this includes tests, lots of other stuff, etc. But still, that's two orders of magnitude.
LoC != Complexity. React has one job, and it does it really well, part of that 350k lines of code is a LOT of tests. Just because it has those tests doesn’t mean it’s “much more complex”. My two cents :)
> React has one job, and it does it really well
I'm not sure I agree. It's hard to compare without a minimal copy of React to see how small it can get, but I'm guessing it could be an order of magnitude smaller. For example, React supports different ways of doing things (class components, function compenents, hooks). Backwards compatibility is a great thing, but it's not the same as "having one job and doing it well", it's a different tradeoff. The React team has lots of people that depends on their code, and thus choose stability over being small and nimble. I think that's a responsible choice. But this leads to complexity, and losing the "having one job and doing it well".
As a more general remark, there's a cycle in software. React starts small and nimble, especially compared to the "jQuery behemots of the past". It gets really popular. So people start depending on it. So it grows, and grows, and grows. And then someone else comes out, maybe Photon, maybe Svelte, maybe something else. Compared to React, it's small and nimble. Maybe in 10 years, Photon will be really popular, will be 200k lines of code, and someone will build an alternative because it's too big and complex.
Edit: as a more meta-remark: My message is way longer than yours because I was trying to steelman my argument, and you didn't do the same with yours. Considering you made a small message "defending" React and I did a long one "defending" Photon, I think we already agree about the tradeoffs involved here.
Re: Reactive Clojure: A web language
#117This 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…
In this sense it's same as what microsoft is trying to do with Blazor - except they are skipping whole javascript crap and compile to wasm.
Re: Reactive Clojure: A web language
#118Re: Reactive Clojure: A web language
#119This is exactly what I've been thinking of lately. I started web development in 1998 and in 2000 I got searching for some way to store data. At first I tried Macromedia Coldfusion, later acquired by Adobe. Now that I checked on it, it seems to be going strong, to my surprise. It was too hard for me. And it was closed software. There was no way for me to learn it without spending money on it. And it wasn't what I was…
Once that lightbulb of the power of a Lisp goes off, there's no turning back. As Eric S. Raymond said, "Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."
Re: Reactive Clojure: A web language
#120Earlier quoted context omitted.
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
How is this different from any other framework? Try fixing a React or Rails bug. At least their system is only 2k LOC, which will presumably be well documented.
I also wouldn’t presume good documentation as a general rule. That’s something that must be proven, not presumed.