
Ionic React - asaddhamani
https://ionicframework.com/blog/announcing-ionic-react/
======
tootie
I did an Ionic/Angular project a few years back and it's a perfectly cromulent
technology if stay within it's wheelhouse. If the app you're building could
easily be a website, but the client wants an app store presence, this is by
far the easiest way to get there. For delivering content-heavy screens that
aren't a drag on CPU, it works fine. And it's also fine for layering in basic
device functionality like location services.

If expectations and budget are low, it's a great option.

~~~
yesimahuman
Thanks for teaching me a new word in “cromulent.” While we think Ionic is for
more than just low-expectation apps (many brands and consumer apps use Ionic)
we appreciate that it fills a need beyond that. Cheers!

~~~
ezequiel-garzon
And me! Now this is interesting:

 _Cromulent first appeared in the February 18, 1996 episode of The Simpsons
called "Lisa the Iconoclast," in what could be considered a throw-away line
given during the opening credits. The schoolchildren of Springfield are
watching a film about the founding father of Springfield, Jebediah
Springfield. The film ends with Jebediah intoning, “A noble spirit embiggens
the smallest man.” One teacher at the back of the room leans over to another
and says that she’d never heard the word embiggen before she moved to
Springfield. “I don't know why,” the other teacher replies. “It's a perfectly
cromulent word.”_

[https://www.merriam-webster.com/words-at-play/what-does-
crom...](https://www.merriam-webster.com/words-at-play/what-does-cromulent-
mean)

~~~
evil-olive
It's one of my favorite Simpsons quotes. Wonderful little bit of linguistic
hackery.

They make up one word, _embiggen_ , and just from the obvious root word of
"big" it's clear what it means. Doubly so when taken in context, "A noble
spirit embiggens the smallest man."

Then they make up a second word, _cromulent_ , and the meaning can be
_entirely_ inferred from context. Embiggen is a perfectly cromulent word.
Acceptable, adequate, maybe a bit unorthodox but "good enough".

~~~
tootie
And it's a pretty useful word. It's somewhere between "acceptable" and
"plausible". It can kind of just mean whatever you need with a slight air of
"I don't really know what I'm talking about, but don't worry it'll be fine."

------
s1mpl3
Kudos! This is a great project. I have one bone to pick, though. Had a show
stopper issue a few months back with capacitor and the entire Ionic team was
unresponsive, even on github. The issue was sending cookies to the server.
Cookie would get set on the response but subsequent requests would not include
the cookie. This was extremely aggravating and I had to halt my development.
Relevant Github issue: [https://github.com/ionic-
team/capacitor/issues/1373](https://github.com/ionic-
team/capacitor/issues/1373). Would be great to know if a solution was ever
found.

~~~
GordonS
I used Ionic for 2 projects a few years back. Support on GitHub was, frankly,
_crap_. I can sympathise to some degree, because they were still trying to
figure out a commercialisation model, but they were far more interested in
shipping new stuff and breaking things than actually stabilising what they
already had. Major bugs affecting lots of people were ignored forever or
closed without comment. It made for a horrible dev experience, and I honestly
can't see myself touching it again with an extra-long barge pole.

~~~
yesimahuman
Sorry about that, we definitely had some growing pains given we were a team of
< 5 on the OSS side with a user base in the millions. Tried to automate as
much as possible on the github side and over-applied our issue robot. I think
our process has improved quite a bit recently and hope you give us another
shot!

------
tschellenbach
Nick did a post about this: [https://dev.to/nickparsons/how-to-build-an-ionic-
chat-app-wi...](https://dev.to/nickparsons/how-to-build-an-ionic-chat-app-
with-react-and-stream-3c1g) I was surprised with how good the performance was.
Really, better than unoptimized native apps, which is (at least to me) quite
surprising

------
JoshMnem
It would be nice if it were possible to not have it load Material Design by
default. It's a bad idea in general for people to build their products with
Google's visual branding. It basically paves the way for Google to become the
entire platform.

~~~
fifafu
that depends on your browser / user agent. If you use chrome it’s material, if
you use safari it’s ios.

If you enter responsive design mode in the chrome dev tools and switch to e.g.
an ipad config, it will use ios styles.

I really like ionic and capacitor and have built lots of great apps with it.
Performance is really ok nowadays (was a problem in the days of ionic 1)

~~~
JoshMnem
That's much worse than I thought. The Web is not a Google or Apple product,
and your product's design shouldn't change based on which browser you use.
That entirely misses the point of the open WWW. It's a terrible idea to build
things in that way.

~~~
yesimahuman
That’s ridiculous. We have to make it look like _something_ the user would
expect, and something good. Why not pick standard UI designs and patterns in
use today? The alternative is that we build our own standards and force users
to learn something new.

This is a feature of Ionic you’re free to disable but many users like very
much. It is more widely used for apps running in the App Store that want to
map to iOS and Android UI standards for each platform.

We also pride ourselves on making Ionic easily brandable so the platform
standards provide a good base you can easily remix to make it look quite
different.

~~~
JoshMnem
The Web is open and independent. Google's and Apple's visual branding are not
the standards of the Web. There are countless non-Google, non-Apple designs on
the Web and they are not forcing users to learn anything new.

Sorry to disagree, but Material Design itself lacks aesthetic restraint and
has accessibility problems with the constant flashing and animation, but
that's another conversation.

Edit: I'm talking about the browser, not apps (though I don't like MD there
either). I mean that websites shouldn't change their design based on the
company that makes the web browser.

~~~
chii
What if it hadn't been ionic, but was instead the browser itself that rendered
the same website differently when in different OS? Oh wait...that's already
the case...

~~~
JoshMnem
Google's browsers don't automatically load your websites with Google's visual
branding and Apple's browsers don't load your websites with Apple's visual
branding.

There's a battle between some of the large tech companies for appification of
the Web at the moment, and that way of thinking is a trap.

~~~
antonkm
You do realize that Ionic is mainly used for App Store and Google Play right?
You're free to not use it. It's a correct decision for Ionic to go with iOS
and Android standards, from my point of view, and the implementation is superb
as always with Ionic components.

~~~
JoshMnem
Yes, I know. The article says also the Web.

A company shouldn't design its _website_ with Google or Apple's visual
branding as if it were locked into a closed platform. It also appears to be a
problem with things like Flutter, though I haven't looked closely.

------
l_t
This looks pretty neat! First I've heard of Ionic, and I want to use it. I
have a question for anyone familiar with it.

I mostly make Web apps with very complex UIs that target desktop computers
specifically. I'm not as concerned with the mobile app story right now, I just
want a batteries included UI framework. Is that a valid use-case for Ionic, or
should it only be used if cross-platform deployment is needed?

~~~
xtracto
I´ve used Ionic for both mobile apps and PWA (web sites that access the device
hardware).

It is pretty straightforward to do both in Ionic.

As a side comment, the other day I wanted to do a very simple single page
"app" (I jog, so I wanted a "sonar" kind of app that told me how far to my
target speed I am, constantly).

I thought I was going to give native Andriod Studio a try... as this was a
very simple app and I was going to use GPS functionality, it sounded right. I
was badly surprised by the way UIs are built in Android Studio, it is so
fugly, it took me back to the AWT/Swing framework I worked with in the late
90s. After battling with the ConstraitLayouts and other bullshit, I went back
to Ionic to do a simple HTML layout and had the app working in 1 hour.

I can't believe in 2019 that is the way Google is making people build
interfaces in Android.

~~~
UlisesAC4
Constraint layout is a delight for working, I wish there was something like
that in css.

~~~
xtracto
I really want to understand it. It reminded me of my days migrating from the
Vb5/6 UI to java swing. It was painful, but after you groked its logic, it
made sense.

How can I get to grok Android's Ui layout process?

------
config_yml
We've abandoned V3 because of the shift in focus. I wish they would have
improved the native build service (I think it's called appflow now?) instead
of going for 2 more frameworks and an IDE. Wish them all the luck with their
new releases.

What we would have needed: \- Actually usable and maintained plugins. Getting
something like push notifications to work is too difficult. And then the
plugins won't even build on their build service. It's a lot of hair pulling
but should really be low hanging fruit for the ionic team. \- Easier
submission into the app stores, because onboarding new people on how to do all
the manual steps for every legacy app we maintain updates for is a pain in the
ass.

~~~
halfmatthalfcat
To piggyback off this: AppFlow is such a great idea in concept, however their
execution is half baked.

I would LOVE to have a build pipeline that builds both iOS and Android and
automatically submits them to the app store, ready to go (whether that's
TestFlight or an actual prod build)...AppFlow gets you 80% of the way there to
much frustration.

I ended up just using Fastlane myself and building my own pipelines that
accomplish the exact same thing. Funny too, if you look in the AppFlow build
output, they're also using Fastlane. I wish they would have pushed it out
_more_ feature complete and include the publish to app stores (I'd be first in
line to shell out).

~~~
yesimahuman
Stay tuned! Actively working on that...

------
mLuby
Ionic was a _huge_ velocity-booster at my last startup. They caught some
(unfair) flak for being Angular-centric when React got hot. Glad to see them
constantly improving things!

P.S. Can the creator.ionic.io get more love? 0:)

~~~
yesimahuman
Glad to hear that! And while creator.ionic.io likely won't get more love, our
new Ionic Studio product is quickly catching up to the simplicity of the drag
and drop experience in Creator and will quickly be surpassing it, so I hope
you check that out!
[https://ionicframework.com/studio](https://ionicframework.com/studio)

------
vially
I haven't used Ionic React, so I can't comment on that, but I've been working
on a medium sized Ionic Angular app and I have mixed feelings about it (to the
point where if I were to start a new project today I wouldn't use it).

Some random issues that come to mind:

1\. Stacked (push/pop navigation)

This was really bad in Ionic 3 where you didn't actually have a proper router,
so this was the only way you could navigate in an app, but it's still an issue
in Ionic 4. Basically you can have multiple (stacked) pages in the DOM at the
same time which negatively impacts performance (e.g.: more DOM nodes, more
computation during change detection cycles, etc). Also, extra cognitive load
because you now have to decide for each link whether you want it to push a new
page onto the stack, pop it from the stack or replace the root page.

2\. Performance problems and/or memory leaks

Simply navigating in an Ionic app is enough to create memory leaks:
[https://github.com/ionic-team/ionic/issues/19242](https://github.com/ionic-
team/ionic/issues/19242)

3\. Trying to use canvas (or size sensitive components) inside an Ionic app

\- [https://github.com/ionic-
team/ionic/issues/17920](https://github.com/ionic-team/ionic/issues/17920) \-
[https://github.com/ionic-team/ionic/issues/17940](https://github.com/ionic-
team/ionic/issues/17940)

4\. Slower developement edit/build/reload cycle

I don't have the exact numbers right now but last time I checked, just
importing the `IonicModule` into an Angular app module (without using any
actual Ionic components) resulted in an order of magnitude slower
edit/build/reload cycle (I think plain Angular was something like 100-200 ms;
after importing `IonicModule` that jumped to 1-2 seconds; not _that_ bad but
significant enough that you could actually feel it).

Given the overwhelmingly positive community feedback I hear about Ionic in
general, I think there's a good chance I may be doing something wrong, in
which case I'd love if someone could point it out.

That being said, huge thanks to the Ionic team for giving us Capacitor. My
experience from migrating the same app from Cordova to Capacitor was really
positive. I feel like it brings a breath of fresh air to hybrid app
development.

~~~
WA
Hey, I'm just an Ionic user, but maybe a few comments:

1\. Not sure about that, but the default is that it pushes to the stack. Isn't
this what anyone would expect?

2\. Are you sure that Chrome records the number of currently existing nodes or
the number of nodes created? I just gave this a try. I have a very simple
script that: empties a container div, creates another div, appends it to the
container. All of this executed when a button is pressed. The number of DOM
nodes should actually stay the same. But Chrome reports an increasing number
of nodes. So I'm not sure what the profiler actually does here.

3\. I use Canvas inside an Ionic app. If you render your Canvas at the right
point of your component lifecycle, it works just fine.

4\. Haven't observed this.

What I'm doing now: Instead of using Ionic 4 (I have an app made with Ionic
3), I switched to Stencil with @ionic/core. This gives me very fine-grained
control over everything. I like it a lot more than the Angular version of
Ionic. Maybe you wanna give this a try as well. Less moving parts :)

~~~
vially
Thanks a lot for taking the time to provide some feedback.

> 1\. Not sure about that, but the default is that it pushes to the stack.
> Isn't this what anyone would expect?

If you assume the stacked navigation model is the right model, then yes, I
guess pushing pages to the stack is a good default behavior.

However, I'm not completely sold on the stacked navigation concept in general.
Let's take GitHub as an example and try to think how the default Ionic
behavior of pushing pages on the stack would apply there.

1\. You navigate to the homepage. Stack: [homepage] 2\. You click on a link to
open a repository. Stack: [homepage, repository] 3\. You click on the issues
tab of that repository. Stack: [homepage, repository, issues] 4\. You open a
particular issue. Stack: [homepage, repository, issues, issue#1]

Obviously this is not very scalable as you now already have 4 full-blown pages
in your stack that are eating away resources (DOM nodes, more change detection
computation, etc). So in order to fix it, you now need to decide which pages
should be pushed on the stack and which ones are replacing old ones. And then,
as your app grows, you also start hitting some edge cases in the Ionic stacked
navigation implementation (e.g.: [https://github.com/ionic-
team/ionic/issues/18197](https://github.com/ionic-team/ionic/issues/18197)).
And at that point you start questioning whether this whole stacked navigation
is actually worth it.

> 2\. Are you sure that Chrome records the number of currently existing nodes
> or the number of nodes created?

I've been using the Chrome DOM Nodes counter in the past and in my experience
it's been 100% reliable (at least for the use-case that I mentioned in that
issue). What I did notice is that the baseline count fluctuates (e.g.:
refreshing the same HTML page sometimes gives you a different _baseline_
counter after each refresh; not sure what that's about). But the difference
between the initial baseline count and the resulting count always reflects the
DOM manipulations performed, so I think it's a good tool for identifying these
kind of leaks. However, you might want to spam the "Collect garbage" button
(found in the Performance tab) after performing these kind of tests as there's
a chance the DOM node was correctly destroyed but it just wasn't collected by
the garbage collector (and that's why it's still reported in the DOM Nodes
count).

> 3\. I use Canvas inside an Ionic app. If you render your Canvas at the right
> point of your component lifecycle, it works just fine.

Completely agree. Once you find the right hook everything seems to work as
expected. However, I feel like Ionic doesn't provide enough hooks for this,
and the introduction of Stencil in Ionic 4 only made things worse (actually
this started affecting us only after migrating to Ionic 4).

To give you an example, let's say you have this DOM structure:

    
    
        <ion-content>
            <ion-grid>
                <ion-row>
                    <ion-col>
                        <ion-card>
                            <my-canvas-component />
                        </ion-card>
                    </ion-col>
                </ion-row>
            </ion-grid>
        </ion-content>
    

In one particular instance we noticed that the <my-canvas-component> had to
wait for the `<ion-col>` component to be ready (using the barely documented
_componentOnReady_ stencil method) before its size was "stable". Which makes
it almost impossible to create a reusable `<my-canvas-component>` that works
everywhere, because it can't know in advance in which DOM tree it's going to
be placed.

> 4\. Haven't observed this.

The easiest way to test this is to start a plain Angular project and an Ionic
project and do a edit/build/reload cycle. Obviously, it depends on hardware
and you need to try match the dependencies as closely as possible, but what I
noticed is that the plain Angular project is noticeably faster.

> Instead of using Ionic 4 (I have an app made with Ionic 3), I switched to
> Stencil with @ionic/core. This gives me very fine-grained control over
> everything.

That's interesting, thanks. We may give that a try.

------
Yuioup
Currently we're working on an angular/ionic 3 hybrid project with libraries
shared though git submodules (Ionic does not support symlinks).

"Libraries" are shared between the Angular app (1 app) and a half dozen or so
Ionic apps. Basically the API calls, pipes, directives and other stuff like
that.

It works well, even though submodules are a pain.

We'll be upgrading to Ionic 4 at some point, probably keeping the architecture
the same. I don't think we'll be moving to React.

------
hmart
I feel Ionic is more engaged into open web than big companies trying to
enforce their own standards. The question is when Appple and Google will start
blocking (outside of walled garden app stores) hybrid apps?

~~~
_bxg1
Why would they block hybrid apps? Apple only cares if your hybrid app _loads_
its code at runtime. They couldn't care less if it's JavaScript.

Edit: If by "hybrid app" you meant "progressive web app", then yeah, Apple has
made it somewhat inconvenient to pin websites to your home screen as apps. But
they'd never really be able to block them altogether without blocking the web
itself, because there's no hard distinction between the two.

~~~
dougmany
I had a Cordova app rejected by the Apple store because it did not use enough
native iOS functionality.

~~~
_bxg1
Were you going out of your way to circumvent native functionality somehow? A
calculator app probably "doesn't use much native iOS functionality", but I
don't see how that would get it negative points on App Store approval.

~~~
dougmany
It is basically a search tool to help people find facilities. It does look a
lot like a web site though.

~~~
oakesm9
That's your issue then. They have rules to stop the App Store being flooded
with website wrappers. For it to be in the app store, there needs to be
something it offers to make it worthwhile for users. If it's just a website,
they can just use a web browser and pin it to the home screen if it's
something they use frequently.

------
nicoburns
I'd definitely consider using this. Mobile browser support used to be painful
for this kind these "hybrid web apps", and animation performance wasn't up to
scratch. But engine support is much better since Android 5, and phones have
only been getting faster. It's not that hard to produce a performance mobile-
web app these days.

------
The_rationalist
I espect Ionic React to take a huge share of react native developers on the
long term.

React native has far less support of web standards/ features than Ionic,
especially modern CSS support. Thus ionic give you more power to build feature
rich, UX rich apps.

Secondly react native has very poor debugging experience, meanwhile ionic
support devtools (I couldn't get it to work on RN).

Thirdly, contrary to popular belief, I expect ionic to have generally better
performance than react native. Chromium evolve quickly and has an army of
engineers that bring state of the art optimizations to the web. For example in
a few releases, chromium will render elements using Vulkan by default.

Lastly, ionic is more native than react could ever be as it supports all 3000+
cordova plugins and seamless Java interop.

The ability to reuse the codebase for the web and for electron are also huge
advantages.

Things will only get better once capacitor stabilize.

Still, I really wish that Ionic now focus on Vue.js/ts support.

~~~
yesimahuman
Wow, thanks, we appreciate the vote of confidence!

It is interesting to think about the possible performance gains to be had
running JS in the browser rather than in a detached JS engine. For example,
WKWebView on iOS has access to the full JIT-ed JS engine on iOS, while
JavaScriptCore does not (as I understand it).

~~~
The_rationalist
The challenge for your marketing is to educate people and to update their
beliefs.

It would be nice if you ran public benchmarcks of two equivalent app one in
Ionic, one in RN (and eventually more (flutter, etc)) If you are empirically
the fastest (maybe we will need to wait a few chromium milestones or to
manually enable Vulkan) You could market those numbers by showing you are the
first to have Vulkan rendering, HTTP3, CSS contains, dom fragments, etc (I
believe Microsoft is working on moving chromium input handling out of the main
thread)

And if you showed things you can't do/easily do in react native. For example
backdrop-filter has recently been added to chromium and is the future of UX.
[https://ferdychristant.com/please-help-make-backdrop-
filter-...](https://ferdychristant.com/please-help-make-backdrop-filter-a-
reality-f81805ba3d52) But really there's so many features that you offer and
others don't! OpenXR, SVG support, css width auto, css grid, etc If you want
an exhaustive list:
[https://www.chromestatus.com/features](https://www.chromestatus.com/features)

Really if react native was on [https://caniuse.com/](https://caniuse.com/)
people would see the truth (the feature gap).

Your marketing also could just make visualizations about the gap in size
between the ionic ecosystem (more plugins than RN + all npm packages) vs RN
npm packages, that would show the order of magnitude of order of magnitude
difference and so how many billions of dollars of man/hours developpers miss
by choosing RN.

Unrelated: I hope that you are aware of the cordova maintenance issue
[https://github.com/apache/cordova/issues/163#issuecomment-54...](https://github.com/apache/cordova/issues/163#issuecomment-542432768)
And capacitor won't be a true successor until it will have full compatibility
with prior cordova plugins.

------
sp33der89
How does Capacitor compare to for example Cordova or Flutter or React Native?
From their site I gather it's like Cordova 2.0?

~~~
kalev
I believe Capacitor is the absolute life-saver of hybrid development. I've
been using Cordova for quite a while and switched to Capacitor last year, and
it made my life so much easier. Where Cordova tries to do anything and
everything, for all platforms, with its super flaky plugins and buggy
config.xml, Capacitor is really focused on doing one thing well: being the
shell between your code and native hardware. One of the major points is the
code it generates for iOS and Android can be committed to GIT and is yours;
you have full control over the native part of your app and could extend it in
any way shape or form.

I have an app running in production now for almost a year and am so so glad
I've chosen Ionic 4 and Capacitor. Kudos to the team.

~~~
yesimahuman
Glad you're liking it! While we remain big fans of Cordova we do have the
fortunate advantage of building Capacitor in 2019 where we have access to much
better JS standards, native tooling that is far more mature than before, and a
clearer outlook on what devices/platforms need to be supported, not to mention
Progressive Web Apps. We've tried to take advantage of those technological
leaps and apply them where possible.

------
Kiro
I have a responsive React app that I want to convert to an app. I thought you
could just drop it in Ionic and it would work automatically but this is using
stuff like IonPage, IonContent etc. Do I need to rewrite a lot in order to get
it to work and how can I keep a shared codebase in the future? I really don't
understand the appeal vs using React Native if I need to rewrite it using
Ionic specific components anyway.

~~~
yesimahuman
Yes you would need to use our components because they have meaningful logic
when it comes to building an app experience.

Can't make the judgement call on whether it's worth you moving to Ionic vs
React Native, but Ionic would be a fit if you prefer a "web-native" approach,
using the traditional react dev experience around react-dom, and want to
target Electron and the web as a Progressive Web App with the same code.

------
traderjane
I wonder how people who were on the fence for Flutter will think about this.

~~~
cgs
I've had great experiences with Ionic in the past. Capacitor removing the
headache that is Cordova looks promising and I'm glad Ionic is moving in that
direction. It's a great platform and there's lots of support out there for it.
I've chosen Flutter for my latest project however for two main reasons: 1) JS
ecosystem fatigue. 2) Not having to write JS or CSS is frankly a breath of
fresh air. I can build a UI logically with out the refresh-and-pray
experience, even if things get kinda verbose. I should also add that this app
is not "brochureware" and needs a more app and less web-like UI. I think Ionic
currently excels in the latter.

~~~
svaha1728
After experiencing a year of 'let's build an Angular app with 60+ developers',
Flutter is a breath of Fresh air. I'm an army of one again!

~~~
brylie
I'm just a bit concerned how Flutter is basically going its own way rather
than building on web standards. E.g. HTML provides declarative layout while
JavScript is ubiquitous and could also be transpiled to native code. Rather,
Flutter is building its own declarative UI approach, rendered with its own
canvas, building on a significantly less ubiquitous language/ecosystem, and is
principally governed by a single organization.

That said, I am seriously considering using Flutter for a future development
project, but am on the fence due to the value and familiarity I see in the web
platform.

~~~
svaha1728
I wouldn't use Flutter for web development. It solves targeting iOS and
Android without having to use a Javascript Bridge. Neither mobile platform
defines its interfaces in terms of HTML. There are definitely a few
development teams where React Native is also a valid choice, but cross-
platform mobile app development has a learning curve regardless.

------
thoughtpalette
Huge congrats to the team! This is a giant milestone in Ionics life. Am a huge
fan of the original Angular.js and Angular versions and it's nice to see the
flexibility with React.

------
ausjke
Awesome news. For quite a while we had ionic for Angular, react native for
React, quasar for Vue, now glad to see ionic officially supports react from
now on.

At the moment though, React-Native has 7x downloads comparing to Ionic:
[https://www.npmtrends.com/ionic-vs-quasar-framework-vs-
react...](https://www.npmtrends.com/ionic-vs-quasar-framework-vs-react-native)

~~~
yesimahuman
re: downloads, it's not quite that simple. `ionic` is our CLI while `react-
native` is the actual library that is installed and will be installed
frequently for build systems, etc. Also there are multiple versions of Ionic
under multiple package names. Not arguing that React Native has more NPM
downloads though but Ionic is quite popular on its own!

------
rgharris
Really excited to see this. We have an Ionic Angular app that is running in
production and being actively developed.

We probably won't get the chance to use Ionic React soon but really hoping
this gets more people excited about Ionic. Being able to deploy to iOS,
Android, and web with a single codebase is incredible for starting with a MVP
and transforming it into a great product.

~~~
yesimahuman
Thanks! I believe that being able to publish a PWA alongside an App Store app
is a magic power for products that have a purpose as a web app through link
sharing _and_ an app in the stores. Why risk losing users to a download when
you can ease them into your world through a PWA first?

------
sireat
What's Ionic's real business model?

They have enterprise support version but my gut feeling is that they make more
money on the tooling.

~~~
yesimahuman
It's a combo. While we offer support and advisory services to medium-to-large
enterprises, increasingly companies are deploying our native solutions for
local app security ([https://ionicframework.com/identity-
vault](https://ionicframework.com/identity-vault)) or our Mobile DevOps
service that has seen a lot of growth recently
([https://ionicframework.com/appflow](https://ionicframework.com/appflow)).
Finally, our new Studio product has been growing very quickly and will be
getting a lot more "low code" dev features in 2020
([https://ionicframework.com/studio](https://ionicframework.com/studio)).
Those products are sold on a subscription basis, either yearly w/ multi-year
contracts for bigger companies, or on a self-service basis.

If you're curious I did a 2019 business update with more details:
[https://ionicframework.com/blog/ionic-2019-business-
update/](https://ionicframework.com/blog/ionic-2019-business-update/)

At a high level we are generating real revenue, growing > 100% y/y (and our
enterprise business is ~1.5 yrs old), and nearing profitability.

------
ss3000
First time hearing about Capacitor. Curious if anyone could share some more
concrete differences between Capacitor and Cordova?

~~~
stockkid
One of the main differences is that Capacitor projects treat build artifacts
as source code, and hence the artifacts are to be version controlled. I
thought such aspect was kind of nice for cases in which you need some
customization.

Here is an example. In Cordova, when using plugins, a developer would have to
use various hooks to produce an artifact with a specific customization. But in
Capacitor, they can just make changes in the source code itself. As a result,
the build is more predictable. On the other hand, such feature might make it
more painful to upgrade stuff if the artifact gets littered with tons of
customization. While such problem might be rare due to the infancy of
Capacitor, maybe in the future it might come back to bite many projects.

~~~
brylie
I might be misunderstanding how Capacitor code generation works, but would re-
running the build process overwrite code customizations on the previous build?
If so, how would this be avoided?

~~~
stockkid
I see how my comment was confusing. In capacitor, when you initialize a
project for a platform (IOS, Android, etc), a bunch of native source code is
generated and they are not overwritten.

------
sergiotapia
My ass has been chewed out by Cordova and PhoneGap too much in the past. I
hope this is different, I'll take a peek.

------
dcchambers
I love Ionic! Glad to see them reach this milestone. Great product and company
and while I am not using them in my current role I wish them the best of luck
moving forward. I hope I get a chance to use it again, if not professionally -
I'll have to take a look at Ionic React for my next personal project.

~~~
yesimahuman
Thanks :)

------
_bxg1
This is one of those products that I'm sure has a large value-add, but still
makes me feel gross that it exists. The amount of glue in here... yeesh.

Edit: I initially read this to be yet another layer on top of React Native,
but it appears to be an alternative to it. So less glue than I thought.

~~~
yesimahuman
You can think of it as a "Bootstrap for Mobile/Desktop Apps" if that helps.
It's not based on React Native but could be used with it to build out certain
screens in the app.

------
Diesel555
I'm a huge fan of Ionic. Capacitor is a great project and fixes a lot of
issues I had with Cordova. I have made a few apps that are websites and apps
on both stores and they work pretty well I think.

------
stockkid
Am I right in understanding that `@ionic/react` is a set of UI components that
are mobile-friendly?

~~~
yesimahuman
Yes, mobile, desktop, and web (Progressive Web App) friendly!

------
lucasverra
Any demo URL for :

best example of ionic @PWA ? What about iOS ?

Camera, gps, webauthn, you know the cool new api's

I wish to compare :)

------
mocha_nate
Big fan of this update!

------
notyourfatherd
> _Instead of building an abstraction on top of iOS and Android native UI
> controls, we wanted to build something that was DOM-native_

Native is dead, on both phone and desktop.

~~~
_bxg1
I'm a web developer and even I wouldn't agree with this. Especially on mobile.

