Agreeing on the debugging concerns. Adding another layer of abstraction on top of everything else isn't going to help anyone. Creating an abstraction that fits so well that you don't have to worry about the layer underneath is extremely hard. That might not show during initial development, but will come up in the maintenance phase for sure.
A bit unsure where the observation of more offline capabilities comes from. I have the impression that things are moving in the opposite direction: Everything needs to be online.
> Adding another layer of abstraction on top of everything else isn't going to help anyone
Ignoring the point that the frameworks we already use are major abstractions on top of abstractions, if this new "abstraction" truly eliminates the complexities of client-server-client it will greatly benefit developers and users alike.
A good many (most?) of the bugs and performance problems (and security lapses) in today's complex webapps is due to the complexities of managing this client-server divide. Even when the developer does things right according to docs and examples, it's possible to end up with a system which does not perform well without solid understanding of what's happening in at the endpoints and in the middle and clever optimizations to solve the special needs.
You're right, I was a bit harsh by disregarding the current use of frameworks. There're huge upsides to them. They still hide stuff, some do it well, some not so. Electric gives me the (unproven) vibe of hiding the lower layers a bit too well.
Regarding the causes of many bugs, your guess is as good as mine. You'll continue to have bugs and you'll have to continue looking under the covers to understand them.
You're right, over-abstracting is a primary risk and has been top of mind for us since project conception in ~2012. ORM, for example, is a nightmare of over-abstraction (remember Spring Framework's AbstractSingletonProxyFactoryBean?). In fact, studying the O/R impedance mismatch from first principles back in ~2010 was what led me to functional programming in 2011.
Electric is an attempt to find exactly the right level of abstraction. The goal is to remove and flatten layers, not add them, thus decreasing abstraction weight in the end if we succeed. Maybe we fail, but first let me share some details about how we think about this:
1. I've personally failed to build this project several times, Electric Clojure is something like the 7th attempt.
2. strong composition model as a starting point, based on category theory generalization of "function" -> "async function" -> "reactive function" -> "stream function" -> "distributed function". ORM does not have this. (This rigor is in response to the past failures.)
3. Functional effect system (monad stuff) at the bottom, which provides strong semantics guarantees about glitch-free reactive propagation, process supervision (like Erlang) (transparent propagation of cancellation and failure), strong resource cleanup guarantees (DOM nodes can never be left hanging, event handlers can never fail to be detached and disposed). Already this results in tighter operational semantics than we have ever achieved with manual resource management (and, again, we tried, see past failures). Our functional effects library: https://github.com/leonoel/missionary
4. Electric affords the programmer trapdoors to the underlying FRP/concurrency primitives. Electric is essentially a Clojure-to-FRP compiler, so if you code raw concurrency and effect management, that actually typechecks with what Electric generates, allowing seamless transition in and out of the abstraction.
5. 3k LOC + 3k test LOC is the size of Electric today (includes a rewrite of the Clojure analyzer). Spring Framework is, let me go check, 59k just for `spring-core/src/main/java`, and there are like 20 other modules I excluded. Indeed it is not a fair comparison but certainly we have complexity budget to spare.
Yes, that's what I meant. I didn't mean an app that's never online (or connected to a server), since that doesn't really make sense in the context of this kind of framework, I meant something that is resilient to being offline (aka "offline capable").
based on the todomvc example, I can say that it is resilient to being offline, in the sense that whatever you do while temporarily offline is resumed when you are back online. there's no optimistic updates so it looks like the items you add while offline are disappearing, but they end up in the list as soon as you are back online.
Everything needs to be online, but "online" those days probably means cutting off constantly between 5GHz and 2.4GHz wifi, with bad ISP DNS and IPv6 routing in the way.
A bit unsure where the observation of more offline capabilities comes from. I have the impression that things are moving in the opposite direction: Everything needs to be online.