I use react-native-reanimated-2
I understand that this library uses TurboModules and Hermes engine
Reanimated 2 is in an early version. As we wanted to share it with the community as soon as we could, the library still has some rough edges and limitations that we plan to address soon. Unfortunately some of the limitations come from the immaturity of React Native's TurboModule architecture that Reanimated 2 relies on. As a consequence we won't be able to support older versions of React Native and some issues that we yet plan to resolve may require full support of TurboModules which is not yet available to the public.
source
However, their documentation does not mention that you should enable it.
Further confusing is the fact that the value is false in the example project.
It is explicitly written in the comment that it should be set to true in order to allow libraries to use it.
# Use this property to enable support to the new architecture.
# This will allow you to use TurboModules and the Fabric render in
# your application. You should enable this flag either if you want
# to write custom TurboModules/Fabric components OR use libraries that
# are providing them.
newArchEnabled=false
Official React-native-reanimated-2 example
I am very confused.
Related
I am asked to target ESNext modules on my Nuxt app, how can I do that? I could not find anything on the web.
Related to this issue: https://github.com/solana-labs/wallet-adapter/pull/107#issuecomment-939443776
Looking at the freshly released Nuxt v3 beta, we can see that ESmodules are only partially supported in Nuxt2.
You should probably wait/upgrade to Nuxt3.
checking the documentation itself, I found no reports of support for ES Modules, however, it is known that "vitejs/vite (vue)" and VueJS 3 via Command Line support these modules, I believe the Nuxt community needs to create a project template with this setting is built into the project settings.
Polyfill services like polyfill.io seem to be delivering only small feature detects to the browser and then lazy-load only the polyfills that are actually needed.
As I understand the babel documentation on polyfilling, babel always include the full set of potentially needed polyfills: it will process a browserslist and then include those polyfills from core-js that the weakest browsers need. A bundler like webpack would then probably merge all these polyfills into the application, but without runtime feature detects.
My application uses modern ES language features but also targets a wide range of browsers, including IE10 and IE11. That requires a lot of polyfills and will probably bloat the bundle, especially for modern browsers that may not need the most of the polyfills.
So I was wondering: can I tell either babel and/or webpack to only include feature detects, split the polyfills off into separate chunks (individually or into small bundles), and then, at runtime, only "lazy"-load what is actually needed?
Services like polyfill.io investigate your User Agent against a predefined set and based on that provide you with different bundle of polyfills. What you're trying to do is actually way different.
One solution I could thing of is to introduce code splitting into your build (it is on by default in Webpack 4 production build) and create several files in your project, where each would import a different set of polyfills. This will require you to import polyfills manually, but will allow you to have several polyfill chunks, each with a different subset of missing features. After you will have those chunks, you could use some feature detection (probably Modernizr) on the startup of your application and dynamically load only those chunks which are needed by the browser. Keep in mind that this process is rather cumbersome - you will need to take care of including each polyfill manually. Also another disadvantage of it, it will need to make several requests to the server, which will additionally slow down your app start time.
As to other part of your question - webpack/babel will not do the automatic polyfill chunks splitting and runtime feature checking for you, those will need to be handled manually.
I want to have Meteor as a server and Ionic2 as a client. I currently have a headache with authentifiacation. It seems that there are two different approaches:
First is use of Meteor server and Meteor client with ionic-angular library. This approach described here
https://angular-meteor.com/tutorials/socially/angular2/ionic2
I guess the advantage of this method is use of Meteor native architecture, on the other hand I guess we're using Ionic2 just like a subframework and maybe loosing some stuff from native Ionic2.
The second is using separate Meteor server ('client' folder deleted completely) and native Ionic2. This approach described here
https://angular-meteor.com/tutorials/whatsapp2/ionic/authentication
This option is vice versa: use of native Ionic2, but it has to use libraries like meteor-client-side, accounts-base-client-side, accounts-password-client-side etc, which I'm not sure are native for Meteor.
The first approach looks better, because there is a ready-to-use UI component for authentification. But I wonder what issues I would have, when I come to the step of completing my applications for different types of devices.
Thank you in advance for your help.
These approaches are essentially the same for the authentication itself.
What you are pointing out is more about what mobile platform to choose to develop and run mobile projects.
In the first case, you use Meteor's built-in Cordova platform to run the app and Meteor's compiler and bundler plugins (like TypeScript package or Meteor core packages for Babel and UglifyJS etc) to develop the app. In the second case, you develop and run the app solely on Ionic 2 CLI.
But from the app logic point of view these approaches are absolutely same: you import the same Ionic 2 components and use the same Meteor packages with the only difference in the second case is that these packages are now NPMs not Atmosphere ones (essentially though they contain the same scripts since these NPMs are built from Atmosphere packages).
The reason why What’sApp clone is built in that way that differs from the Socially’s one is simply described in the README of
the What’sApp repo (see https://github.com/Urigo/Ionic2CLI-Meteor-WhatsApp). If to repeat: since Ionic is a one of the best Web frameworks that specializes solely in building mobile apps, it’s reasonable to guess that it’ll be (and likely it is) much more powerful in building them than Meteor itself. From that point of view the second approach seems more future-proof, I would say. You could think even of building your project in some way that will allow you to substitute Meteor easily with some another framework if you decide to use it at some point in the future.
If you are though concerned about using those NPMs mentioned in the second case (e.g., if the process of building them doesn’t look transparent to you), you could try this project https://github.com/Urigo/meteor-client-bundler to bundle Atmosphere packages you need into separate scripts and use them after.
WHere can I get a XD version of dojo source like the one hosted on google? What I want to do is to host dojo source from my local CDN, and my custom dojo module in my web application. Is this a good practice? or I might as well just include the dojo source in my web app, and run the custom build?
Thanks,
You can build an xd version of dojo from the source code
Here are instructions on how to do it:
http://dojotoolkit.org/reference-guide/1.7/quickstart/custom-builds.html
See the section on "doing xdomain builds"
In our organization (a large one), we do have a CDN version of dojo deployed on internal CDN mainly since some of our webapps are not allowed to access extranet (firewall issues).
For performance, though, a custom build gives biggest boost since it is customized to the modules you need/use - once the custom build is done, you only need to ship a single compressed js output file and a small number of supporting files
When doing your custom build, you can use the xdDojoPath and loader=xdomain if you wish to use cross domain dojo to load your optimized js - see http://osdir.com/ml/cometd-users/2011-08/msg00050.html for some notes on this
Also see related SO question: Dojo on a CDN vs own install
The good news is that with Dojo 1.7+ and the new loader, you don't have to do anything special for a cross domain build (good answer above from #Vijay Agrawal, but I think that reference guide link may need some updating for 1.7) Just write your code to the new AMD format, use asynch:true, run the build tools to create layers, and deploy them on any server. AMD makes use of callbacks and many of the tricks the old Dojo xd builder used to employ, but in a much simpler way.
To support older code, there is a legacy cross domain mode mentioned in the loader docs.
I have recently been browsing frameworks such as JavaScriptMVC, qooxdoo, Sproutcore and others alike which are using javascript to create desktop-like apps in the browser with minimal, or none css/html (depending on the framework).
What I know of titanium is that it uses html/css for the views, and language of choice (javascript, ruby,python,php) for everything else. Then it gets compiled(?) into a native app.
What are the quirks? if any?
Is it necessary for the user to install some sort of a runtime to execute the compiled app?
I suppose javascript is the prefered language, but how are the other ones handled?
For example, which Ruby interpreter would be included, would I be albe to use the ruby stdlib or external libraries? Would it affect the speed of the app? I.e JS > Ruby in terms of speed.
Since the views are CSS/HTML, would it still be necessary to style the elements, add them effects via JS librarier to achieve a widget-like feeling? Or does it come with some pre-made settings/classes for that?
I am not sure if it applies to the desktop package, but is there some syncing with the appcelerator's server required? What would it be necessary for?
I am sorry if the questions sound stupid, but I didn't even realise there are than many tools until recent. I am ultimately looking for something which is easy to use, has an option to work with a back-end server for data exchange, looks preferably good 'out of the box' or doesnt require that much work to get it themed nicely and works on mobile as well as desktop devices.
With Titanium you build your app out using javascript. Titanium ultimately generates its own XCode project for you that is compiled and deployed to a device.
The user does not require any runtime be installed prior to installing your app.
Unless your building custom modules to hook up your own controls you stick with javascript.
Your javascript calls end up as native controls, early versions required css like styling due to reliance on webkit but this is no longer the case.
There is no IDE but it does come with an app to create Titanium projects, test in emulator, deploy etc. It also talks back to HQ for updates.
In answer to (2), Titanium Mobile is Javascript only, but Desktop also supports Python, Perl and PHP.