Comment by carshodev

There was a complete fork to support it, Dartium.

https://chromium.googlesource.com/dart/dartium/src/

Dart is only around because it was rescued by AdWords team, which had just migrated from GWT into AngularDart, and wasn't happy to do yet another transition.

Most of the key names from Smalltalk/Self background that were part of Dart 1.0 left the team at this point.

It managed to stay around long enough to get the attention of the Flutter team, originally their prototype was done in JavaScript, which is also the reason why Dart 2.0 was a complete reboot of its type system, from dynamically typed with optional typing, to strongly typed language with type inference.

And it isn't as if Flutter is a great success, Fuchsia never made it big, the Android team counter attacked with Kotlin's adoption, JetPack Compose, and Kotlin Multiplatform.

Agreed that Dart was an effort to do exactly this.

To be a bit pedantic... "relegated to transpiling to JS" makes it sound like that was something they had to do later, but in fact that was up front part of the transition plan. The idea was, write your code in Dart and it would work natively in browsers that (eventually) support it but would still work in everything else via JS transpilation. You're right that it was relegated to only working that way once it was rejected.

The problem was (if the Wikipedia article is to be believed) that developers took offense to one company unilaterally deciding on the future scripting language of the web. A little ironic given that's how JS evolved in the first place, but fair enough. Later, WASM was created instead, with the idea that no particular language had to be chosen (and frozen) as the JS replacement. Dart compilation to WASM followed.

And what's crazy is with ai the percentage of apps developed using react in comparison to all other frameworks has INCREASED over the last 3 years.

It is truly mass hysteria, I would say that 95% of developers, project managers, and CTOs do not truly understand how these systems work under the hood, or at the very least are too scared and comfortable to try other systems. They just repeat the same things they hear and tell each other "react has a big ecosystem" "react is industry standard" "everyone uses react" "react was developed by facebook" "we will use react" "Developers only know react, how could we hire for a different framework?"

In my mind its clear that the alternatives are massively better. When i visit certain websites I often get a random tingle that it uses svelte because its way faster and has better loading and navigation than other sites and when i check the devtools I'm almost always correct.

I also get the same feeling sometimes when I hit a laggy slow webapp and I open the devtools and clearly see its a nextjs app.

A dev team could be trained on svelte or vue in literally 3 days, and so long as they actually understand how HTML, JS, and css work under the hood they would increase their speed massively. People just don't want to take the risk.

I managed to avoid learning React long enough to become a manager.

I'm not saying I won't ever end up in engineering and won't ever have to learn it, but at least right now, it feels kinda like I got away with something.

I remained unemployed after I was laid off until a change of career happened. I refused to back to Angular/React/Vue. I was not going to shovel shit anymore for people who were clearly incompetent and really entitled about it.

It lasted because React genuinely did introduce a useful new paradigm - of UI being a (mostly) pure function of state. This has actual benefits. Unfortunately the way this was implemented was (very) suboptimal, and now they're locked in.

I agree that this stubborn clutching to that original idea, despite better options that acheive the same paradigm having arisen in the meantime.

Unfortunely it is hard to avoid when doing backed development with SaaS, iPaaS products, where JavaScript is in many cases the only extension language for backend widgets.

I am kind of alright with Next.js, as it is quite similar to using SSR with more tradicionla backend stacks.

Also at least node's C++ AddOns give me an excuse to occasionally throw C++ into the mix.

I would want this to happen personally as there is no other way that the tech can advance at this current point.

It's clear that there is no global browser federation that works together to make standards. Every browser does things themselves and implements things differently. So the only way that it is feasible is if the browser that is used by 75%+ of sessions is the one that implements it.

Would I like it to be open source? of course. would I like it to be a separate project that was not directly controlled by google? yes. But this does not change the fact that it would ONLY be possible if they accept it into chrome.

The alternative is to forever use Javascript and never advance or change things.

Tech moves quickly and it could be possible that a new browser could take market share in 10 years but it is inconceivable now and would take some groundbreaking shift.

It feels like current browsers can never change their language and it will only be once a new platform is standard, like Vision/Glasses or a voice AI assistant.

It could have been possible if Huawei was allowed to stay in the US market as they are making their own kernal, operating systems and browsers, but they are now excluded. So only google and apple are present to control how things operate.

Over time things must adapt if they become better, there is always pushback when change occurs, but change is necessary for growth.

Almost had this with dart

I've worked on large React and Solid codebases and don't agree at all. You can make a mess of either one if you don't follow good practices. Also dynamic dependency management is not just a nice to have, it's actually critical to why Solid's reactive system is more performant. Take a simple example of a useMemo/createMemo which contains conditional logic based on a reactive variable, in one branch a calculation is done that references a lot of reactive state while the other branch doesn't. In React, the callback will constantly be re-executed when the state changes even if it is not being actively used in the calculation, while this is not the case in Solid because dependencies are tracked at runtime.

Vue's model is more constrained: sharing variables to child components, signals to notify parent components. I found this a lot simpler to reason about than React.

I wouldn't call it good, but Go was designed for applications performing large numbers of concurrent processes. It is really easy to just wrap a block of imperative code in a try/catch, but it becomes much more difficult when you have a bunch of different goroutines communicating over channels producing outputs at indeterminate times. Like you need bespoke error handling for every use case, you can't just say: "400 try again later".

> Letting google implement a new language for the web would probably result in something even worse than javascript.

Why? Javascript was famously written in ten days, was intended for casual scripting, and has not made up its mind whether it wants to be a Java or a Scheme. What could google invent that would be worse?

I analyzed all the major frameworks years ago and went with Svelte when svelte 5 came out. It is all I use now, the development team is highly responsive and cooperative with the community, the founder Rich Harris has a pragmatic approach and tries to keep it as compatible with html/js while still providing great DX and massive efficiency. It natively supports serverside rendering that turns into a SPA once it hits the browser.

Angular is probably more efficient than react but The DX is going to be worse than svelte or vue.

If you want the fastest apps in environments with low ping then use Qwik.

If you want the best overall experience, great customizability, compatability with any js package, great efficiency in most situations, and a great developer experience just go with Svelte (or vue maybe).

Angular might be fine, I don't know. I never used it extensively. But I do know that svelte is the only framework that I like using now.

Angular uses directives for rendering, that allows compilers to optimize rendering.

React model uses plain JavaScript expressions which are harder to optimize.

Do some research, experiment. Make up your own mind.

it's not a really unbiased view. React's team has made very clear that they won't even start considering a different approach, and this (and other) is just their narrative to support their stance (which never seemed under discussion), and it borders on gaslighting the community which still has to deal at least with the two giant issues of:

1) knowing why something rendered is almost impossible 2) even for skilled developers who know what they are doing it's quite easy to introduce performance regressions. In other words, it's not a pit of success performance wise

Meanwhile (and this is also never addressed by the React team) if you use other frameworks some issues (for one: effect dependencies) simply are not issues

There are other areas.

Embedded development, high critical systems, mobile platforms (the choice isn't really there), game consoles.

It is mostly C or C++, Swift/Objective-C, Java/Kotlin.

There are other alternatives you might want to point out, notice however they need integration layers, leaky ones, some yak shaving not much different than targeting WebAssembly, and still having to talk to JavaScript.

I come from the native desktop/mobile world more so than from web, but I’d strongly contest the idea that declarative/functional is always better than imperative/OOP.

My experience is that declarative starts getting mind-bendy and awkward past a certain point of complexity. It’s nice when it’s simple enough for everything to fit on a single screen without too much scrolling, but past that you need to start breaking it out into separate files. That’s not too bad initially, but eventually you end up with an infinite-Matryoshka-doll setup which sucks to navigate for anybody who doesn’t know the codebase because they have to jump through 7 files to drill down to the code they’re actually interested in and makes it more difficult to get a thousand-foot view of it all.

Also, the larger the project the more likely it is that you’re going to have to pull off acrobatics to get the desired behavior due to the model not cleanly fitting a number of situations.

Declarative is solid for small-to-medium projects, but for more “serious” desktop class software with complex views and lots of panes and such I’d be reaching for an imperative framework every time. Those require more boilerplate and have their own pitfalls, but scale much better on average for a dev team with a little discipline and proper code hygiene.

React is not actually functional - hooks are not functions, they're magic functions that smuggle state.

The main problem with react is that it's, ironically, not reactive. It greedily re-renders, whereas Vue actually reacts to state change.

If you don't understand why these are faster then you need to look at the source code and benchmarks.

Qwik is faster because it splits every single reactive element into a loader that only hydrates exactly what is needed when its used, that's why its good on low ping environemnts but can be very bad on high ping environments regarless of DL speed.

Svelte is faster because it uses signals under the hood, has tons of optimizations, doesn't use VDOM, and has a much better diffing algorithm to only update what is needed.

Yes you can make react "fast enough" noone is denying that. Its used by millions of websites. That does not change the fact that all of these other frameworks are faster than it at doing the same operations/dif changes.