4 ms·

"Like every other framework, we've come to the realisation that Knockout was right all along." Nope, nope. Been there, done that, with 2-way data binding and n

"Like every other framework, we've come to the realisation that Knockout was right all along." Nope, nope. Been there, done that, with 2-way data binding and never going back.

deleted 3y ago
[deleted]
capableweb 3y ago
I thought that quote of yours was a sarcastic overview you yourself had written but no, it's an actual quote from the article! > Like every other framework, we've come to the realisation that Knockout was right all along. > Svelte 5's reactivity is powered by signals, which are essentially what Knockout was doing in 2010. More recently, signals have been popularised by Solid and adopted by a multitude of other frameworks. > We're doing things a bit differently though. In Svelte 5, signals are an under-the-hood implementation detail rather than something you interact with directly. That's a sad development and further makes the framework more complect (as defined by Rich Hickey), with more hidden layers and "magic".
- deleted 3y ago
  [deleted]
hinkley 3y ago
> with 2-way data binding and never going back. We used to know that, too. We also used to know that entirely event-driven architectures were a level of chaos you shouldn’t invite into your enterprise. Don’t need to look hard to see those either. Whole industry has been cycles of collective amnesia going back to at least 1975. [Edit] but in this case what we seem to be doing is having another go at Aspect Oriented Programming, which I was interested in for some time but concluded it, like event-only systems, are a poor fit for the average developer’s mental model, and also a terrible way to encode business requirements. Particularly from a testing perspective. They are usually dabbling at functional core, imperative wrapper architectures, but tend to retain global shared state which is a reliability nightmare waiting to happen.
tambourine_man 3y ago
I’m still waiting for every other framework to realize that jQuery was right all along. But if these guys are only now reaching Knockout, I still have to wait for them to catch up to Backbone.js, I guess.
- devmor 3y ago
  > I’m still waiting for every other framework to realize that jQuery was right all along. I find myself feeling this way a lot while writing front-end code. While I am primarily a back-end developer by trade, I find myself working in Vue or React quite often just to get things done and regularly come to the realization that the majority of the reactivity in the projects I am working on is either unnecessary or so simple that it would be handled with less complexity as a line or two of jQuery.
  - interactivecode 3y ago
    Thats similar to me as a frontend dev seeing all the backend complexity and thinking it would be easier just to read and write a json file instead of a db + apis. It works but on longer projects where requirements can explode in complexity it becomes a problem. It really helps to have tools that can stay maintainable.
    - tambourine_man 3y ago
      Yeah, sure. It's pure joy of mantainability and dependencies. Just watch out for that dust, if you sneeze next to a 5 year old Node.js/React project, the whole thing falls apart.
    - devmor 3y ago
      That comparison works against your point quite well because there are an absolutely incredible amount of backend services built with scalability and sharded postgres dbs with redis caching or what-have-you that would have been perfectly served by a perl script and an sqlite file.
  - tambourine_man 3y ago
mgaunard 3y ago
My experience with JavaScript is limited, but knockout is what I use because it's what makes sense.
- chrisco255 3y ago
  Knockout is fine to use if your JS doesn't exceed 1000 lines or so. After that, in more complex apps, 2 way data binding becomes an absolute mess of side effects.
  - recursive 3y ago
    I've used knockout in much larger apps than this. I still don't understand what side effects people are talking about when they say this. I don't love knockout, but I find it easier to debug than react. Mainly because stuff is synchronous, meaning the thing that caused the change is above the problem in the callstack. In react, a lot of stuff goes through an async work scheduler, so the originator of the problem is long gone.
  - mgaunard 3y ago
    I've built frontends that are much larger than that (and I'm not even a frontend developer) and they all worked fine. If anything it makes it clear what's going on and when, which is important for the kind of stuff I do which has a lot of interconnected components which are constantly refreshing.

"Like every other framework, we've come to the realisation that Knockout was right all along." Nope, nope. Been there, done that, with 2-way data binding and never going back.

deleted 3y ago

[deleted]

capableweb 3y ago

I thought that quote of yours was a sarcastic overview you yourself had written but no, it's an actual quote from the article! > Like every other framework, we've come to the realisation that Knockout was right all along. > Svelte 5's reactivity is powered by signals, which are essentially what Knockout was doing in 2010. More recently, signals have been popularised by Solid and adopted by a multitude of other frameworks. > We're doing things a bit differently though. In Svelte 5, signals are an under-the-hood implementation detail rather than something you interact with directly. That's a sad development and further makes the framework more complect (as defined by Rich Hickey), with more hidden layers and "magic".

deleted 3y ago
[deleted]

hinkley 3y ago

> with 2-way data binding and never going back. We used to know that, too. We also used to know that entirely event-driven architectures were a level of chaos you shouldn’t invite into your enterprise. Don’t need to look hard to see those either. Whole industry has been cycles of collective amnesia going back to at least 1975. [Edit] but in this case what we seem to be doing is having another go at Aspect Oriented Programming, which I was interested in for some time but concluded it, like event-only systems, are a poor fit for the average developer’s mental model, and also a terrible way to encode business requirements. Particularly from a testing perspective. They are usually dabbling at functional core, imperative wrapper architectures, but tend to retain global shared state which is a reliability nightmare waiting to happen.

tambourine_man 3y ago

I’m still waiting for every other framework to realize that jQuery was right all along. But if these guys are only now reaching Knockout, I still have to wait for them to catch up to Backbone.js, I guess.

devmor 3y ago
> I’m still waiting for every other framework to realize that jQuery was right all along. I find myself feeling this way a lot while writing front-end code. While I am primarily a back-end developer by trade, I find myself working in Vue or React quite often just to get things done and regularly come to the realization that the majority of the reactivity in the projects I am working on is either unnecessary or so simple that it would be handled with less complexity as a line or two of jQuery.
- interactivecode 3y ago
  Thats similar to me as a frontend dev seeing all the backend complexity and thinking it would be easier just to read and write a json file instead of a db + apis. It works but on longer projects where requirements can explode in complexity it becomes a problem. It really helps to have tools that can stay maintainable.
  - tambourine_man 3y ago
    Yeah, sure. It's pure joy of mantainability and dependencies. Just watch out for that dust, if you sneeze next to a 5 year old Node.js/React project, the whole thing falls apart.
  - devmor 3y ago
    That comparison works against your point quite well because there are an absolutely incredible amount of backend services built with scalability and sharded postgres dbs with redis caching or what-have-you that would have been perfectly served by a perl script and an sqlite file.
- tambourine_man 3y ago

mgaunard 3y ago

My experience with JavaScript is limited, but knockout is what I use because it's what makes sense.

chrisco255 3y ago
Knockout is fine to use if your JS doesn't exceed 1000 lines or so. After that, in more complex apps, 2 way data binding becomes an absolute mess of side effects.
- recursive 3y ago
  I've used knockout in much larger apps than this. I still don't understand what side effects people are talking about when they say this. I don't love knockout, but I find it easier to debug than react. Mainly because stuff is synchronous, meaning the thing that caused the change is above the problem in the callstack. In react, a lot of stuff goes through an async work scheduler, so the originator of the problem is long gone.
- mgaunard 3y ago
  I've built frontends that are much larger than that (and I'm not even a frontend developer) and they all worked fine. If anything it makes it clear what's going on and when, which is important for the kind of stuff I do which has a lot of interconnected components which are constantly refreshing.