4 ms·
It is a little disappointing that this doesn't directly address the issues with the original article's claims. Instead it continues focusing on CPU execution ti
by npalli 13y ago
It is a little disappointing that this doesn't directly address the issues with the original article's claims. Instead it continues focusing on CPU execution timings. Like many responses to the original article, the elephant in the room is javascript performance on DOM manipulation/UI. To take an example on the desktop, if I gave you two options a) language a which is about 2 times slower than C in doing some math operations b) language b which is about 15 times slower than C in doing some math operations. Both are GC languages with large memory footprint (3-8x) that of C. Which language would you choose to write your UI? If you chose a. you chose WRONG!. a) is java with its horrible AWT/Swing libraries and b) is Visual Basic.
Nothing specific to Java though, the .NET guys have spent about 15 years optimizing their GC. Yet every UI framework on that platform seems like a turd compared to Visual Basic (WinForms, WPF, Silverlight). Looks like they are throwing the towel and asking everyone to move to HTML and javascript. I wish javascript guys spent more time benchmarking UI performance than making it look like C++ (asm.js and other things). Take a paper draw circle on it. Push it on a smooth desk. That's your use case and how things should perform. No jitter, no flashes. Don't care about some fancy assembler optimization for matrix multiplications.
Of course that is only one part of the problem with javascript. The other big problem is lack of tools for putting UI's and writing large programs. On top of that you have to add in all the libraries (jQuery, Angular etc.) now you are totally hosed. You don't know where your performance issues are. In any case, mobile apps today have really two platforms - iOS and Android. They have quite different use cases (paid vs advertising). Most UIs are thin wrappers on services. Porting to the next platform is not some huge rewrite.
- mwcampbell 13y ago> Most UIs are thin wrappers on services. Porting to the next platform is not some huge rewrite. I beg to differ. In my current project, the client (written in JS) has about 10x as much non-UI code as the server. Currently this app only targets desktop platforms through a thin wrapper. When it's time to target mobile platforms, the UI will need to be native, or at least a mix of native and Web. I have no plan to rewrite all the non-UI code twice, once in ObjC and once in Java. So we need a way to have a common, memory-safe language for non-UI client code, that can be shared between the major mobile platforms and the Web platform. I'm going to take another look at Titanium Mobile, though I don't like the way it attempts to provide a greatest-common-denominator API for the UI. I'd rather use the platforms' native UI APIs, in their native languages if necessary, while using a common language for non-UI code.
- _random_ 13y agoWorking with HTML feels quite low-level after having worked with WPF. And there can't be core HTML innovation because of standards.