Any method for front end tooling is potentially the fastest. It always comes to what you measure and how you measure it. If you don't have any measures at all then your favorite method is always the fastest no matter what, because you live in a world without evidence.

Even after consideration of measurements radical performance improvements are most typically the result of the code's organization and techniques employed than the language its written in. But, of course, that cannot be validated without evidence from comparison of measurements.

The tragic part of all this is that everybody already knows this, but most front end developers do not measure things and may become hostile when measurements do occur that contradict their favorite techniques.

▲

codingdave 4 hours ago | parent [-]

I have yet to meet a front-end dev that gets hostile when you show them how their code can be improved. On the contrary, the folks I have worked with are thrilled to improve their craft.

Unless of course you are not showing them improvements and are instead just shitting on their work. Yes, people do get hostile to that approach.

▲

austin-cheney 4 hours ago | parent [-]

Then you and I are talking to different people. Fortunately, I don't work in JavaScript for employment any more. As a frame of reference just the mere mention that a site could be 50-200x faster by dumping React creates conflicts of interests for impacted developers and the results are typically not immediately welcoming. That isn't shitting on anybody's work, especially if you provide guidance for improvement, but if a large group of developers cannot function without React their perception of "shitting on their work" will be less objective.

	▲	johnfn 2 hours ago \| parent [-]
		It doesn't surprise me that you got a lot of people upset at you. "Dumping React" is not a viable strategy for the large majority of organizations. This would be like saying that you could improve performance by rewriting the backend into Rust.