Yes customisability is a big selling point of KDE but I'm afraid it may end up being a time sucking trap for someone with my personality type... You know, why spend time just getting things done when you can spend it customising your environment so you can be as productive as possible and actually get things done faster eventually, some day, maybe... lol

(btw I was talking about Qt vs electron in my earlier question, obviously KDE wasn't related to the discussion)

I'm actually quite fond of the way GNOME shell works on my laptop, but I'll give KDE a chance on another machine for sure (if only for KDEconnect which is quite awesome, also dolphin is way better than nautilus). There just seems to be too many oldschool menus on KDE apps, I like the way GNOME feels moderns and always try to hide the stuff I'm not using right now, helps me to keep focused on what I'm doing...

I see that many people complain (and I can also see it for myself) that electron apps use up a lot of RAM and CPU compared to native solutions. I know KDE is based on Qt so I guess it has to be a more efficient solution compared to electron?

This is an old discussion, but when you said " I am a desktop-developer, too, and I love(!) JS. It is super-easy to create and script a GUI with web techniques and super-performant to have the hot code in a compiled language" , what do you techniques do you refer to? Do you use electron (I thought electron was 100% JS all across) or is there some other options out there?

You are right. Quoting an answer from stackoverflow, " a = a + [5] is syntactic sugar for a = a.__add__([5]) , and since a.__add__([5]) returns a new object, a holds a reference to the new object rather than the old object." This is likely to be coherent with the principle that python does not like implicit side effects. If you want to mutate the list object, you have to be explicit about it, and use the "compound operator" += : " a +=[5] (as well as a.append(5) ) is syntactic sugar for a = a.__iadd__([5]) . The difference is that the latter method - __iadd__() - does not create a new object in memory. Rather, it modifies the existing list object, and returns a reference to it."

In case anyone stumbles upon this question, in addition to Stephen's answer here, there's a link that gives excellent explanations to questions regarding the topic of mutations in python : http://www-inst.eecs.berkeley.edu/~selfpace/cs9honline/Q2/mutation.html Also I've asked this question over on stackoverflow and got some interesting answers as well. Here's an edit I added to my original question over there to summarize the answers : -In python mutating operations are explicit -The addition or multiplication operator performed on list objects creates a new object, and doesn't change the list object implicitly [Both of these "facts" are the reasons why alist=alist+[5] won't mutate alist, whereas alist+=[5] will] I could also add: -"Every time you use square brackets to describe a list, that creates a new list object" [this from : http://www-inst.eecs.berkeley.edu/~selfpace/cs9honline/Q2/mutation.html ] Also I realized after Kabanus' answer how careful one must be tracking mutations in a program : l=[1,2] z=l l+=[3] z=z+[3] and l=[1,2] z=l z=z+[3] l+=[3] Will yield completely different values for z. This must be a frequent source of errors isn't it? I'm only in the beginning of my learning and haven't delved deeply into OOP concepts just yet, but I think I'm already starting to understand what the fuss around functional paradigm is about...

Thanks again for your replies "WASM does not have to do a lot with JS. WASM was born in order to overcome problems with JS, specifically by not using JS. However, compared to TypeScript and others, WASM goes a step further and feeds prepared and optimized byte-code into the interpreter. Just think of WASM as yet another way to battle the shortcomings of JS. " I must have expressed myself very poorly because this was very clear to me already. I guess I was hoping that WASM would help to get rid of the JS frameworks madness, but I now realize thanks to you that the main source of web apps frontend madness isn't the limitations of JS iself but rather simply the fact that we're creating an app running on the browser and connected to a database somewhere in the world through the world wide web. I hear so many bad things about JS from "desktop" (non-web) developers that I thought getting rid of JS was the answer... I was hoping that thanks to WASM using a nice modern high-ish level language like Kotlin would make web app frontend development a breeze... But now you're telling me that rust or C++ would be the languages of choice, which makes sense as WASM is mainly about performance first and foremost. Does this mean the end of the days where any web developer worth his salt could get by without knowing any low level language?

" It might as well be the other way around: These frameworks might be ported to Rust or C++ and then compiled to WASM and used by other projects. That would fragment the communities and hurt developers, since it becomes even harder to decide what to use (WASM or not? Which stack? Which language? etc.) " Thanks, I guess this answers my question. One of my "problems" with these JS frameworks though is that they bring extra overhead (eg typescript, JSX) because of the inherent limitations of JS itself. Shouldn't porting them [the frameworks] to another language then compile to WASM fix this "problem" at least?

Thanks for your reply. Like you said, WASM specific use-case is to "create real applications which run in the browser". Isn't this also (in part at least) the purpose of those ambitious JS frameworks such as Angular and React? Doesn't it mean that these somewhat inelegant, over-engineered JS frameworks will lose relevance once it makes more sense to use a more adequate language along with a more coherent/elegant framework for the tasks of creating complex web apps with elaborated UIs? "Simpler" JS libraries such as Jquery (or even Vue.JS?) will be (are) more than enough for most "traditional" website UI cases (those who don't aim to be full fledged complex apps). Because these frameworks (Angular, React) have a steep learning curve, as a beginner I'm just wondering if it's worth spending the time necessary to master them vs spending that time focusing on learning backend technologies with a much longer lifespan. (I think I have "Javascript fatigue" before even starting! lol) What do you think? Any other experienced fullstack web developer opinion on this?