191–200 of 256 posts
Why can't we just use Model-View-Controller for change-detection? Views subscribe with the model to get notifications about changes to different "aspects" of the model. When they get a change-notification they update themselves by asking the model for its latest data for a given aspect.
> Angular’s change detection is a disaster. The developer gets two suboptimal choices: (1) the slow and naive default implementation, or the complexity of managing change detection manually. This is completely wrong. The "naive" approach is the one you should always use, with the onpush strategy reserved for breaking certain cascading situations manually. But the default approach works perfectly fine, it is performan…
React is not reactive at all, the "state" management is you calling a function "setState" to re-render the component. And I find manual render very usefull and once you do it, you can have a global state as simple as a global object, no need to use useState anymore. https://github.com/dezmou/useRender
The reactive part is every component getting that prop will update versus needing to write a function in jQuery to manually update the inner HTML of those components
> To overcome the shortcomings of the default change detection paradigm, the Angular team is working on a new approach called Signals. Conceptually, signals are similar to Svelte stores (which we’ll get to later), and fundamentally, they solve the change detection problem the same way as React; the framework is taking control over the application’s state so that changes can be easily monitored and re-renders can be a…
For a little while it looked like mobx was going to displace Redux in React-world, and if that had happened it would have brought this to React without having to change React itself.
The proxy stuff I don't trust. Burned me once, never again.
Earlier quoted context omitted.
Having used both QML and Svelte, I enjoy Svelte a lot more. The reactive APIs are very similar, just declare variables, mutate them, and use them. But Svelte is much nicer for many reasons: 1. It uses modern JavaScript and not some limited custom ES5-like JavaScript 2. Svelte can be used with TypeScript so your UI code can be statically typed 3. The integration with Svelte and VSCode is much better than QML and Qt Cr…
1. Yes, but I never found it limiting. If I need to write some complex logic I mostly do it on the C++ side (that's should probably be the best way anyway). 2. True. 3. Yes, Qt Creator is very lacking in that department. There are many instances where it doesn't recognize certain commands and you need to guess if you're writing correctly or not. 4. Live reloading is possible in QML. See[1] (But this should definitely…
That reloading tool is cool, though its not quite as useful as modern dev servers. It seems like this simply restarts the app on every change, but modern dev servers remember your state too.
I'm curious to hear more about your React experiences. I don't love React, but I still prefer React+TypeScript over Qt+QML. With TypeScript on the strictest setting, programs are much safer than with QML or Qt. We both know QML is very unsafe. And after using TypeScript and Rust, I'm realizing C++ is a very unsafe language too. It has unexpected nulls, memory leaks, seg faults, etc. I find C++ such a rough language to use, and that could be it's own mega rant. Qt's crazy macro system makes things even worse and generates some crazy errors.
There are so many options for building great cross platform UIs now. Tauri, Flutter, React Native, etc. Those all seem to have a better dev experience than Qt/QML. If performance and safety are really important, then you can use Tauri and write your critical code in Rust. There are also UI frameworks for Rust popping up like Dioxus so you can write everything in Rust.
Your "Better Notes" app is amazing and that Kanban is looking amazing. Though, I feel like you're a great dev making great stuff albeit Qt/QML, not because of Qt/QML.
Earlier quoted context omitted.
> maybe someone can shed some light into the downsides of Svelte Svelte trades off runtime size for component size. It was created in the context of infographics for the New York Times online and for projects that roughly line up with that it's pretty much the technically best option. I like the Svelte authoring experience and introduced it for a few components in a React based low-code platform. The reason I phased…
> I also ran into what seemed to be some transient invalidation issues. It sounds to me like you didn’t understand the details of Svelte’s reactivity model, which are very important, and fairly straightforward to learn, but different from what people are commonly used to—and so even if you theoretically learn the model, it may take time in more complex cases for it to come naturally. The crux of these sorts of proble…
This is a reasonable assumption given what I've described. It's been almost two years but from what I remember the problem was updating what should have been the same reactive binding in two different locations. When trying to debug a problem I was stepping through the code and noticed that the indicies passed to `$$invalidate` were different. Checked for typos and shadowed declarations and found none. Rolled back to checkout and found the indicies matched. In the process of undoing/redoing my conclusion was that the introduction of an unrelated reactive binding was the difference. I could have been wrong; I was pretty exhausted at that point.
> It sounds also like you’re fighting the framework.
Sure. In this case it was getting a big chunk of JSON back from an endpoint I didn't control and trying to use a number of reactive variables to select out pieces for display. I've done similar things in a half dozen other reactive/FRP libraries without issue but I assumed I was off the beaten path in Svelte.
I realize that this is empty complaining about other peoples' hard work. I don't have the code any more and I don't have a reproducible test case so I have no problem with anybody waving this off.
Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention any (it's apparently "win-win"). Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?
For example:
const cells: Record = { a: "hello world", b: hello world, c: }
This becomes a problem, when you build composed components that decide their layout based on logic thats too complex to express in CSS or Sveltes templating system.
For example:
- A component for tabbed navigation that automatically becomes a sidebar on desktop.
- React Router defining its entire navigation tree [1]
- Ant.Design defining the columns of the table, where you can trivially supply a short callback to render a cell [2]
[1]: https://reactrouter.com/en/main/routers/create-browser-route... [2]: https://ant.design/components/table
Earlier quoted context omitted.
This QML example is implementing the example from the article, and the article already implements this example in Svelte. However, the Svelte implementation becomes even more concise when you inline the functions: let count = 0 count--}>decrement {count} count++}>increment setTimeout(()=>count++, 1000)}> increment later Play with this in the Svelte REPL here: https://svelte.dev/repl/97d42ad98e4b4a929d3c5a3de880e6fc?v…
Haha I was typing fast just to show the QML syntax. I don't really think good code is about lower amount of lines, but rather more about "making sense". And that's what I tried to show. Regarding the timer, so in your Svelte code a new timer is being created each time? I wonder how to implement the efficiently in QML. I don't think it's as straightforward. EDIT: Probably the best way is to expose QTimer::singleShot (…
> Regarding the timer, so in your Svelte code a new timer is being created each time?
`setTimeout`[1] isn't even a Svelte thing, it's a JavaScript API that QML would have access to if it was real JavaScript ;).
[1] https://developer.mozilla.org/en-US/docs/Web/API/setTimeout
Totally disagree with this. Change detection is nothing but a hack to get around the fact that interacting directly with the browser DOM is very slow and blinky. Imagine a world where interacting directly with the browser DOM didn't suck, then none of these libraries would exist. The crux of the problem is that the browser immediately reflects changes to the DOM to the screen. And when you make a bunch of changes to…
I think your idea of speeding up the DOM is the right one, but the view transitions API has almost nothing to do with it. That’s more for whole page changes, and doesn’t solve the main issues which is that the DOM simply does way too much and is bloated to all hell, and that JS is single threaded. I’d like to see a new mode introduced ala “use strict”. I know the big brains at the top hate this but we need a way to s…
It's my observation that React and similar frameworks really help to bloat the DOM.
Now someone will say it is how people misuse React and similar frameworks.
and then I will say if large parts of the population using a technology make the same misuse of it, even people who know better, it seems like the technology supports that misuse and is to blame somehow.
Earlier quoted context omitted.
For example, there's the way it's still impossible to pass data between native Web Components without stringifying it first.
This is an absolutely stunningly false and ignorant statement. I can't believe it's still being repeated. Web components are objects and they have properties that can be set. The entire web components community - which includes the developers of apps like Photoshop, Reddit, Chrome, Firefox, and a lot more - passes properties down through trees of web components _all the time_.
Maybe a bit verbose, but here is an example https://jsfiddle.net/8kvucm9f/5/ in the context of the blog post (and with my preferences of doing things; there are just many different ways of "writing web components", and can adapt many use cases).
Also, by using their HTML attributes (id="", name=""), it is possible to make really nice features with CSS.
Finally, they can offer a clear API (just like the or or elements), to the users of these elements.
They can be inserted, to give "markdown" documents (or .org mode etc. if it is converted to HTML), JSX like features, by being "just embedded HTML text".
It is super powerful, maybe feels a bit scary at first, but all problems seems to get solvable with clean patterns.