181–190 of 256 posts
You can argue over if you prefer React, Angular, Vue or Svelte but at the end of the day you're still shipping 1-3mb bundles instead of 1kb and resuming
Earlier quoted context omitted.
I don't see it that way. The main need for change detection in my opinion is to remove the need to update parts of the DOM in an imperative manner. It is fine to do that for smaller projects but when a project gets large, it becomes difficult to reason about the myriad of changes happening without a system to handle that. I find any one of the examples in the linked post way more easy to reason about than manual DOM…
Having worked extensively with the major frameworks in multiple orgs, I have largely found that templates synced with state via change detection (like Angular) result in more readable/maintainable projects. While I personally like React, it's pretty tricky to use in reality. I have found that its idiosyncrasies make it less resilient to suboptimal contributions from engineers that are still early in their careers. Br…
If you haven't I recommend having a look. If found it amazing for maintainability.
You have to be carful to structure everything well. If not you blow up the number of messages in one file. But once you get past that it's really amazing.
Earlier quoted context omitted.
This is an issue of you not understanding how to properly manage the state of your application, not React. It's very likely that you're using effects improperly.
Effects are way too easy to use improperly. I used to be a fan of useEffect when it came out because of its concision, but after working with countless devs/agencies, it's clear that most people misuse it. The rules of useEffect are inelegant, and creating readable state machines with useEffect is very hard. You end up with spaghetti code either in your custom hook, or directly in the component. While most components…
QML wins with bindings and signal and slots! (In this example the the text property of the Text componenet is binded to count , so whenever count changes the text changes). ``` property int count: 0 Button { onClicked: { count--; } } Text { text: count.toString(); } Button { onClicked: { count--; } } Button { onClicked: { incrementLater.start(); } } Timer { id:incrementLater interval: 1000 onTriggered: { count++; } }…
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…
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 be the default in Qt Creator).
5. I agree that QML documentation is lacking. That's probably my biggest pain point. Some of the examples also use deprecated/bad-practice code which is annoying (eg, using that magic `index` property rather than defining it as a required property.
I think you have fair points. I actually have a doc with similar things that QML needs to improve in. I never tried Svelte but I'm familiar with React, and I must say that Qt/QML is a breath of fresh air after using React. Developing in React always felt hacky like using duct tape and glue compared to building something properly which QML/QT feels like.
Apart from the points above, I still think QML has been great for my productivity and I'm impressed how easy it is to develop with it complex UIs easily. I've been developing a feature in my Qt C++ app in QML that turns Markdown tasks into Kanban[2]. It worked out perfectly. The tasks processing is done in C++ which sends the data to QML.
[1] https://github.com/patrickelectric/qhot#integrate-in-qtcreat...
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.
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?
> 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…
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 problems tends to be that reactivity is a property of bindings, not data; and as a secondary effect, mutation is therefore rather hazardous.
> 50-something reactive variables in a moderately complex chain
It sounds also like you’re fighting the framework. I’ve seen stuff like what you describe in some React libraries (e.g. mirroring something DOMmy in React—common, but I hate it because it’s so much mindless duplication, among other faults), but in Svelte at this scale you’re likely to get better results from seeing if you can bag things together (e.g. let x = {a, b, c} rather than let a, b, c), or passing through components rather than reactive variables. But these are vague concepts which may not actually be relevant or applicable.
Svelte is a framework that definitely requires that you work with it, or you’ll have a miserable time, whereas with React you can, to a much greater extent, do awful things and get away with it.
And when you speak of 3.x and 4.x and such—there’s basically no chance any of this stuff will ever change in Svelte, it’s too fundamental. In some cases you might end up with better compiler warnings, but that’ll likely be the extent of it.
Earlier quoted context omitted.
how would the above QML example be implemented in svelte?
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…
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 (C++) in QML.
Offtopic: The cursive italics are apparently a feature of the Victor Mono [1] font used for the full page. While it'd be amusing in Tumblr context (where cursive is used for hyperbolic emphasis), I can't fathom why one would consider it in a code context, but to each their own... You can change it (at least on Safari) by going into developer tools, clicking any node, and removing "Victor Mono" from --font-family [1]…
There are 10 types of front-end frameworks in this world; those that are htmx, and those that aren't.
