This actually makes no sense. C++ can do multithreading just fine. What people mean when they say "a multi-threading safe language" or "multi-threading optimized language" is that the language has some mechanism which makes threading a bit easier (like built-in concurrent loops) and can guarantee to a degree absence of deadlocks and other concurrent problems. By no means it implies that you cannot do concurrency otherwise. It's honestly just a bit more work, but you do need to spend more time on testing and debugging. And testing and debugging concurrent programs is difficult. The problem they might be referring to in regards to language is that threading on Windows is retarded and by default C++ has to use Windows model. But they can get a library which encapsulates the crap, like boost and be just fine. But adding a library to a project might not be that easy or good. Some frameworks do interesting and useful things. I would say that jquery is pretty useful. I wouldn't say that angular is useful. Especially with the learning curve it has. Screw it. I can also agree that two-way binding is useful, but you can do it yourself in like 10-15 minutes without the framework. You also don't need frameworks to do oh so popular now MVC design... in that regard I might like react better since it only provides the mechanism without the crap ton of useless bulk. Frameworks also take away your control. You call the framework, then some magic happens, and then you either get a result or you get an error, and you don't really know why it happened. I looked at it, but since I haven't seen it before I have to really look into it to say anything. I can't form an opinion by just reading some examples. Also looking at their styling example, I wonder how they butcher html of the page to get style scoping, or however they achieve that.
I'm not saying C++ can't do multithreading. What I mean in my previous post that the legacy codebase written in C++ with single threading originally, and if they want to do concurrency and parallelism, if it's Mozilla Firefox we're talking about, I'm sure they'll use Rust, since it's a programming language they've invented themselves. Angular has fallen out of favor recently because of its size and complexity added with built-in typescript. It's designed for large apps. When I began look into frameworks two years ago I also prefer others than Angular. I'm sticking with Vue for webapp and Svelte for lightweight ones now. There's no need to learn Angular if we just want to make small to medium sized web apps. They just add an unique class for elements for every components during the compiling process. Works just fine for me until now.
It's not that simple. They would have to rewrite separated libraries/components to do interop properly. It is possible to write thread-safe data structures and then use those in the main program. If the code is written properly, that wouldn't even require that much work to rewrite. Something tells me that in the case of firefox it won't be that easy Pretty much my point. Few years back the hype was over the top for angular, I never liked it tho. People abuse JS way too much, that's why we get these monstrous sites with the size in megabytes and nothing to show for it. I wanna put all these JS people back, if not on 56k, then on 1M lines, give them their frameworks and ask for the web site that loads under 1s with that speed. See how much you framework then. Yea, I saw it. Seems a decent lib for now.
They have started doing it https://servo.org/ Rewritting entire codebase is risky thing. Most devs feel as long as it just works they don't need to reinvent the codebase and learn new tricks to improve users' experience--that isn't a good thing for developers that using bloated frameworks and libraries. But some were actually trying. I've read some cases about companies dropping react for their landing pages and used vanilla js instead. If my memories correct it's Netflix and Spotify. One interesting case come from a company in my country Tokopedia, they clone the homepage (made with React) with Svelte and precache the rest of the webapp instead--they managed to down the js bundle size from 220kb to 37kb, only for the homepage tho. The recent hypes today are web components and compiler frameworks like Svelte. Since web components supported natively in new versions of browser and thus future proof, and compiler frameworks compiling almost to vanilla js sizes, I'd say the next generation of javascript land is looking bright.
So, now in addition to all your ram, Firefox will also eat all your CPU. Can't wait I am in general strongly against hype. These people have no common sense and no critical thinking. Someone shows them a sparkly framework and they all go nuts about it switching immediately. It's like people really have no idea how things work and just follow what someone tells them. But then I also remember how someone deleted from npm a function that checks the end of an array and more than 10k projects broke.... I looked at the video about Svelte, it seems like something I am at least willing to try. The learning curve seems to be not too steep, and the interim language not too absurd. I am overall in favor of precompiled things, especially in case of JS. I also hope that someone will make a better language for scripting someday and it will get accepted by the community.
That just means Firefox will finally able to use all of your CPU cores. I also don't really follow hype, but certainly it can be a good indicator to guess the future trend. If in a few years people migrating from bloated angular apps to some compiler frameworks like svelte then it's definitely a major win for general users. There's also a very promising project from creator of nodejs. https://deno.land/ It's basically the next generation of nodejs. I've been looking forward to see future javascript powered static site generator that can compile 1000 pages in seconds.
I just imagine some defunct process responsible for rendering or something with leaky memory just sitting there and eating up all your resources. It can be, except that there are more hyped things that are lost into oblivion than those that stay. It is often easy to say which ones are going to be gone and which ones are going to stay, tho. javascript on server side always horrified me. I don't want to use it even for some simple front-end scripting, why would I torture myself with it even on the server side? I would rather code on php!
Rust has its own memory management system rather than allocating memory manually, and it doesn't use garbage collector either. Rust do memory management during the compiling (as far as I recall). So they should manage memory leak better when they develope the engine with Rust. Deno use Rust as its backend, and provide types with typescript. The end result should be a more powerful nodejs though whether it can succeed nodejs smoothly is still questionable. Since javascript is the sole language that can interact with browser DOM it's necessary to have it upgraded. You don't have to use it if you don't want. If I have to do some server side I also rather learn Golang or Rust. But since I'm not interested doing backend, all I've been digging around mainly javascript till now.
Doing memory allocation at compile time is impossible. The manual for Rust also says it's pretty much the same memory management as current c++, 17 or whatever version they are up to now. It is possible and fairly easy to get leaky memory. They basically use scope to decide when a variable is deleted from the memory, which is how C++ and pretty much everything else does it for local variable. But with the pointers and references passed around, what supposed to go out of scope does not always go out of scope. Java and C# has shown that you can write programs that leak even in supposedly fairly safe languages. Rust also includes features like raw pointers, so the whole shabang with memory safety will become useless with those. It's all sounds fine and dandy in theory, but look at C++ where pretty much the same system is already implemented and tried. People just don't write code in a way that takes advantages of the best features. It doesn't really matter what language was used to write the server. I am talking about using JS to write server-side scripts. It is probably the worst idea I've seen in the past 15 years. JS is just a really bad language overall... why would you want to write server-side code in it? TypeScript is cool and all, but it also has its problems. There is a plethora of better languages for the server to pick from... honestly, just use Haskell - that will get you all the type safety you want. Or Python if you like weakly typed language... or php, that is still better than JS
I'm not saying javascript is the best language. But, for the web, I'd argue it's the most important--at least for now. As long as javascript monopolizing access to browser DOM then it'll always be the spoiled kid of web development community. The reason why people so hyped when they can write server side with javascript is because they only need to learn one language for front and backend, it's obvious. With how fast the web landscape changing every year it's already exhausting to learn javascript alone. And in the future more languages and frameworks will emerge, making it more overwhelming I'm sure. In a parallel world where the web rapidly changed becoming a fullstack dev would be very difficult if nodejs never happened.
JS is really one of the most widely used languages, but learning a language is really no big deal. Any developer knows 3-5 languages easy and experienced ones can know 10 or more. What is more difficult to learn are all the frameworks. Not only there is no standard to them, they are usually designed with some purpose in mind that only the author of the framework knows. In that regard JS is really not in a good position. Also, VB used to be a scripting browser language, but it's worse than JS, so it got kicked out of the competition. But saying JS is the only one is also incorrect. Technically, all languages do have to compile to JS, you have other JS knockoffs that are available, but in addition you have stuff like Brython, which lets you write Python instead of JS. There is also project Pyodide, which will bring native Python to the browser. And all the disadvantages of JS will just make writing server-side horrible and not extensible in the future. And JS leaks like no other, and debugging it is a nightmare. If I had an arch enemy, I would make him code only JS for both client and server side. I don't like the language if you can't tell. But I don't like more the way people abuse it. It was never meant to be used this way. We need something new.
I looked into pyodide github repo, so it's basically a web assembly project for data science. Web assembly can't access DOM. EDIT: Looking at it again, I guess it can, huh. It's still debatable whether web assembly can kill javascript or not. Looking forward how it turns out in the future.
They use WebAssembly to run Python. It is still questinable if it takes. I hope it will. If people will say "no Python, JS forever til the day we die", nothing will probably come of it. What I hope to see is at least some frameworks or libraries on Python. JS community is weird, so who knows...
Microsoft also host the same project with Web Assembly for C#. It seems already support data-driven UI out-of-the-box. The time when JS frameworks become obsolete is nigh. https://devblogs.microsoft.com/aspnet/blazor-now-in-official-preview/ Last time I checked it's still experimental, but now it's out officially. Microsoft announced they'll commit into it. Oh boy, javascript seems screwed now. If one of these web assembly projects managed to gain hype and live through it then definitely it can be the end of JS monopoly over browser. Anyway, I think we're already out of topic. We're not talking about firefox anymore...
Seems like a cool stuff. And since it's Microsoft, they have the power to push it onto people to a degree. I am not really in the game with .net core because I am doing other stuff. Yea, we went off-topic there from leaky memory in Firefox lol
Do people really have hundreds of tabs open normally? Because unless you use a potato or have tiny ram, even with multi-processes firefox shouldnt take up that much ram compared to a lot of other things unless you have absurd numbers of tabs open.
There's a long discussion about e10 (electrolysis) in the mozilla.dev.platform Google group, specifically cJMzxi7_PmI. You can set an env variable MOZ_FORCE_DISABLE_E10S to 1 or lower the content process count in the about:config tab.
this might be a dead post, sorry for reviving it. opera only takes 1GB of ram. and please upgrade your rams.
Firefox takes 500mb even with multiple processes in my pc rn... >.> Still feels like way too much, but far better than what Opera consumes at the very least.