4 ms·
facepalm. First, it is generally better to apply performance improvements to the existing framework than to create a new one. Second, different is not always b
by ynniv 15y ago
facepalm. First, it is generally better to apply performance improvements to the existing framework than to create a new one.
Second, different is not always better. This will increase call performance, but will incur a (de)serialization penalty, limit parameter types (likely to scalars and read-only hashmaps), and make debugging more difficult. And beware of telling the OS that you implement this protocol, or you will have created an XSS attack vector on your native app.
Whenever you break new ground, don't fool yourself into thinking that you're the first person who has had an idea, and make sure that you sanity check your work.
- Connorhd 15y agoWe totally agree that when things have a solid foundation it makes sense to build on top of them. The problem we saw with Phonegap was several design decisions we disagreed with (as we described briefly in the blog post). This left us with the option of putting up with it (and ending up with an inferior product), or writing our own bridge, and writing our own bridge made sense. Of course you are right in that writing anything new means you have to work hard to get it to as high a standard as the alternatives, which is why we work hard to test our platform - see http://trigger.io/cross-platform-application-development-blog/2012/01/26/how-forge-works-and-why-were-proud-of-it/ http://trigger.io/cross-platform-application-development-blo.... It's also important to remember that the native bridge is just one part of our product, we also write the code that generates and builds the app, which we want to integrate as tightly as possible. Writing our own bridge makes this a lot easier to do well.
- spacy 15y agoYou gotta admit the native bridge is pretty important though, it could be a bottleneck for all the nice bits native code. On that basis the bridge is fundamental to good performance.