wisdom

agine pressing a button and what you want is just there before your brain can process screen flicker. This results in a wildly different set of user behaviors than slow software that causes users to wait between interactions. Then there are downstream consequences to massive performance improvements, the second order consequences. If your software is extremely fast across the board then your test automation can be extremely fast across the board. Again, there is a wildly different set of expectations around quality when you can run end-to-end testing across 300 scenarios in under 8 seconds as compared to waiting 30 minutes to fully validate software quality. In the later case nobody runs the tests until they are forced to as some sort of CI step and even then people will debate if a given change is worth the effort. When testing takes less than 8 seconds everybody and their dog, including the completely non-technical people, runs the tests dozens of times a day. I wrote my study of performance just a few months before being laid off from JavaScript land. Now, I will never go back for less than half a million in salary per year. I got tired of people repeating the same mistakes over and over. God forbid you know what the answer is to cure world hunger and bring in world peace, because any suggestion to make things better is ALWAYS met with hostility if it challenges a developer's comfort bubble. So, now I do something else where I can make just as much money without all the stupidity.

r performance and lower complexity the most desirable solution is to create a new language with forced simplicity directly in the image of JavaScript, where simple means less and not easy, and transition to that new language slowly over time. Yes, I understand Google went down this road in the past with Dart, but Dart solved for all the wrong problems and thus was dead on arrival. Instead the idea is to take something that works well and shave off all the bullshit reducing it down to the smallest possible thing. Forced simplicity means absolutely ignoring all vanity/stylistic concerns and instead only focusing on fewer ways of doing things. As an example consider a language that requires strong typing like TypeScript and thus thereby eliminates type coercion. Another example is operators that have a single purpose (not overloaded), single character, and no redundant operators. Will there be a lot of crying about vanity bullshit... yes, absolutely. Just ignore it because, you cannot reasonably expect to drive above 120mph on a child's tricycle. If people wish to offer their own stylistic considerations they should include performance metrics and explanations how their suggestions reduce quantity of operations without unnecessary abstraction.

eductions, and refactors that yield smaller code. * Competence. Finally, if your developers aren’t competent then no amount of platform improvements or rewards will matter. Set extremely high standards for code quality and give your developers the time and support to rise to the challenge. By code quality I do not mean superficial or vanity nonsense. By code quality I mean writing original code that achieves desired business objectives with fewer dependencies and is absent identified bad practices. Don’t let the children run the daycare. If there are developers that cannot rise to the challenge them fire them and provide them a wonderful recommendation for their next opportunity. Code quality must be determined by evidence, not preference. Here is an example: https://github.com/prettydiff/wisdom/blob/master/performance... That’s really it. As the manager you set the standards, but you must understand there is not so magical switch that makes your developers deliver code faster. If you are serious about this you have a lot of work to do. You absolutely have to understand rapid delivery can only occur after your leadership sets the right conditions, using evidence, and doesn’t waver.

licity and reuse even if greatly inconvenient. That often required an irrationally high level of refactoring. * Speed is an understanding of tree models and transmission and nothing more. Always navigate tree models where they are available, such as the file system and the DOM, in preference to string parsing. String parsing, in any form, is a performance killer. Binary payloads and bidirectional communication are vastly superior to HTTP in every conceivable scenario. * Other UI developers are cowardly. Don’t let that limit your ambition. Don’t listen to a bunch of bullshit cliches. Measure things and execute according to evidence. Reinvent absolute everything you see fit, and yes it will make other UI developers cry. Real world users don’t care about the sad tears of your peers.

are framework. I describe it here: https://github.com/prettydiff/wisdom/blob/master/state_manag...