▲ | Dylan16807 7 days ago | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
Maybe for languages, but fast is easily left behind when looking for frameworks. People want features, people want compatibility, people will use electron all over. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | 9rx 7 days ago | parent [-] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
> fast is easily left behind when looking for frameworks. Nah. React, for example, only garnered attention because it said "Look how much faster the virtual DOM is!". We could go on all day. > People want features, people want compatibility Yes, but under the assumption that it is already built to be as "fast" as possible. "Fast" is assumed. That's why "faster" is such a great marketing trick, as it tunes people into "Hold up. What I'm currently using actually sucks. I'd better reconsider." "Fast" is deemed important, but it isn't asked for as it is considered inconceivable that you wouldn't always make things "fast". But with that said, keep in mind that the outside user doesn't know what "fast" is until there is something to compare it with. That is how some products can get away with not being "fast" — until something else comes along to show that it needn't be that way. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|