Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What dif­fer­enti­ates front-end frame­works

themer.dev

Post reply on HN
Print view View original

211–220 of 256 posts

Re: What dif­fer­enti­ates front-end frame­works

#211

Post by JuanPosadas »

MauranKilom wrote: post #9

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?

Just note that I last used svelte/sapper 2 years ago. I have no idea if core updates or sveltekit or (hopefully) improved typescript support changes anything.

Some types of errors cause your application to halt (which might feel like a UI freeze). There's no way to catch these errors and show an error page, show an error message, or report the error to an error tracking service like Sentry. I'm subbed to the github issue for this and never saw a fix.

Poor composability of components. Components in svelte are awesome in the general sense, they're just missing this higher-level code organization possibility that react, solidjs, and vuejs users have cozy versions of.

The docs claimed a specific function worked like nuxt's asyncData function. Whoever wrote that has no idea what nuxt's asyncData function does, because that function worked very very very differently.

Re: What dif­fer­enti­ates front-end frame­works

#212

Post by rubymamis »

onsclom wrote: post #195
rubymamis wrote: post #184

Earlier quoted context omitted.

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…

Thanks for the thoughtful response. It's interesting hearing from someone who actually likes Qt. I use both React and Qt/QML for work, and I have a hard time enjoying the Qt/QML work. Maybe I'm missing something or doing things wrong? 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…

Thanks for the kind words!

> Maybe I'm missing something or doing things wrong?

To be fair, I have many annoyances with Qt Quick. I think many of the components don't look and work native out of the box, requiring significant customization that is time-consuming compared to what you get out of the box by using many libraries alongside React. And there are these other annoyances that we already talked about. But in my view, the QML paradigm is extremely consistent, even migrating from Qt5 to Qt6 was quite straightforward. I just updated my website to a new NextJS version and so many things broke in React there were serious paradigm changes if I remember correctly. I also enjoy working with Qt's Model/View, I appreciate the native performance I get from compiled C++ code (Most QML code is compiled to C++)[1], the community is very helpful, etc.

> I'm realizing C++ is a very unsafe language too.

Yes, and I think programming languages like Rust are very cool. I know there are Qt bindings for Rust. But I'm not sure how QML is unsafe. Probably because it compiles to C++? Converting Qt Core itself to Rust is quite an initiative that I'm not sure is necessary. But what is cool is that you can write your UI in QML (compiled to C++ somewhat safely if you trust Qt) and write your app logic in Rust[2]. I hope to see more things like that.

Regarding my React experience, I developed a fully working online marketplace in React + NextJS (but discarded the idea), a React Native app that finds rhymes for words (but didn't publish because chatGPT does it better in a way), and my personal website[3] is in React + NextJS - I love this combo for developing websites, I find it so easy and the integration with Vercel is amazing.

I like React for small projects but as it gets bigger I find it quite cumbersome. Though if we're talking about websites I guess it's one of the best approaches (although Svelte looks good but I never tried it).

React Native is so good because they cracked it with components behaving and looking like native components (well, they are the native components I guess). But I prefer to work with Qt/QML. I thought it would take me a long time to learn it but I bought a good online course from Udemy and in a day I knew all the basics, the next day I had a working prototype for my Kanban.

I tried Tauri as well, it sounds good on paper but when I tried it I didn't really like it. I don't remember why but I remember wrestling too much with things not related to actually writing code.

I keep an eye on Rust GUI frameworks but haven't seen something promising yet. I never heard of Dioxus before so I'll check it out, thanks!

[1] https://www.qt.io/blog/the-new-qtquick-compiler-technology

[2] https://www.youtube.com/watch?v=0HEJFYSxbB8

[3] https://www.rubymamistvalove.com

Re: What dif­fer­enti­ates front-end frame­works

#213

Post by aryanmann »

satvikpendem wrote: post #41
MauranKilom wrote: post #9

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?

You need to learn a custom DSL for logic instead of using just Javascript. This makes it worse for TypeScript as well as other tools like for linting, etc. Personally I'll never learn another DSL after JSX. Implicit 2 way data binding which makes logic hard to follow in larger projects, same with their reactivity model.

It really isn't that bad. You can frontload your logic outside inside the script section (or use @const's). The DSL is just a couple of {#if} and {#each}'s.

Is the 2 way data binding implicit? As I understood, you need the "bind:" keyword for 2 way data binding.

Re: What dif­fer­enti­ates front-end frame­works

#214

Post by JanisErdmanis »

onsclom wrote: post #195
rubymamis wrote: post #184

Earlier quoted context omitted.

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…

Thanks for the thoughtful response. It's interesting hearing from someone who actually likes Qt. I use both React and Qt/QML for work, and I have a hard time enjoying the Qt/QML work. Maybe I'm missing something or doing things wrong? 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…

Perhaps your experience with QML would be more pleasant if you would write backend in Rust or Julia (my current choice). In Julia I find that it is particularly easy to iterate as it avoids any compilation step although that is not as smooth as using VS Code with hot reload on the side. There is also Felgo for reloading which I guess also preserves the state, but I have not tried it yet.

One quite an advantage for QML is how easy it is to align elements to get started. Personally, I find it quite frustrating to get HTML to do what I want whereas in QML having only used for two months I already see how to model `Kanban` UI with QML.

Re: What dif­fer­enti­ates front-end frame­works

#215

Post by ogoffart »

rubymamis wrote: post #212
onsclom wrote: post #195

Earlier quoted context omitted.

Thanks for the thoughtful response. It's interesting hearing from someone who actually likes Qt. I use both React and Qt/QML for work, and I have a hard time enjoying the Qt/QML work. Maybe I'm missing something or doing things wrong? 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…

Thanks for the kind words! > Maybe I'm missing something or doing things wrong? To be fair, I have many annoyances with Qt Quick. I think many of the components don't look and work native out of the box, requiring significant customization that is time-consuming compared to what you get out of the box by using many libraries alongside React. And there are these other annoyances that we already talked about. But in my…

I'm the author of rust binding for QML (the qmetaobject crate). The idea is that this is "safe" because your Rust code is safe, and QML is also supposedly safe. The implementation of QtCore/QtQuick is not your code to maintain. So hope that other people made it safe. See it as an abstraction is just like the Rust standard library that uses lots of unsafe.

But anyway, I'm also making Slint [0], a toolkit developed in Rust, inspired from QML. So that even the implementation of the toolkit is safer.

[0] https://slint.rs

Re: What dif­fer­enti­ates front-end frame­works

#216

Post by unsupp0rted »

emorning3 wrote: post #42

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…

> then none of these libraries would exist.

I'd still have to use a framework for componentizing my components, scoping CSS, a namespaced store, etc

Re: What dif­fer­enti­ates front-end frame­works

#217

Post by naasking »

nine_k wrote: post #123
naasking wrote: post #86

Earlier quoted context omitted.

Change detection has nothing to do with the speed of DOM updates, it's about directly encoding dataflow dependencies to avoid code duplication and redundant UI updates. You could paper over the lack of dataflow updates by just updating the whole screen every time, but you still need to preserve various state, like scroll positions, highlighted text, etc. which still means only some state changes and other state does…

Redundant UI updates could be okay if done quickly and cheaply. Games refresh entire framebuffers 60 times a second, redrawing the entire world, and it works fine, because they do that efficiently, and flip entire pages so that you never see a half-draw.

Full refreshes aren't cheap though, games consume a lot of power.

Re: What dif­fer­enti­ates front-end frame­works

#218

Post by Capricorn2481 »

dezmou wrote: post #193
Capricorn2481 wrote: post #178

Earlier quoted context omitted.

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

States are scoped to a component, how "every" component that get the prop update ?

If you pass a prop to a child component, it will update whenever you change state

If two unrelated components are consuming the same context, it will update when that context updates.

Using Zustand, there's virtually no overhead to this and it's extremely reactive

Re: What dif­fer­enti­ates front-end frame­works

#219

Post by [deleted] »

aluminum96 wrote: post #131

> 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…

[deleted]

Re: What dif­fer­enti­ates front-end frame­works

#220

Post by [deleted] »

aluminum96 wrote: post #131

> 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…

[deleted]
Post reply on HN