
The end of Framework Churn - Sujan
http://blog.ionic.io/the-end-of-framework-churn/
======
eric_b
I do not believe Web Components will stop framework churn.

The big problem I have with web components is that they aren't very useful.
Everyone seems to think the component is the key to victory with modern web
applications. It's true that it's sometimes valuable to have turn-key UI
components, but they almost never stand completely on their own. They need to
know about the rest of the application and what's happening - and this is
where web components fall short.

Imagine a shopping cart indicator on an E-commerce site. (A so-called "mini
cart"). These are ubiquitous. When a user adds something to the cart from
other places on the page, the indicator (usually in the upper right corner of
the page) increases the count displayed, and maybe adds a small
picture/description to a dropdown list showing what's in the cart.

Components help with a vanishingly small portion of that interaction. Sure,
they allow you to drop a single tag on the page and have the UI look the same.
But how does the cart component know to update? Global event bus? Click event
handlers? Polling? Callbacks? That mechanism is undefined with Web Components.

Communication _between_ components is the key to winning the web application
war, and this is why I think React has done so well. Their data
flow/communication pattern with Redux is really understandable and easy to
reason about. They've got first class support for passing application state
around, and ensuring an action in one place on the page cascades to all places
that care about it. To me that is infinitely more important for productivity
than stamping out the same custom element over and over.

~~~
news_to_me
I think the point is more that by using web components, whatever framework
you're using becomes more interchangeable. Web components only solve a piece
of what, say, React does – the component piece. For state management, you can
still reach for Redux (which tries to be framework agnostic), or even still
embed them in React if that makes sense for your app.

So maybe web components won't _stop_ framework churn, but they'll make it a
lot easier to transition between frameworks.

~~~
eric_b
I dunno, I'd rather use "vanilla" React/Redux/JSX than try and get those tools
to fit with custom elements, shadow DOM and the html import/template stuff.

The web components specs look poorly thought out to me. They seem
superficially like good ideas, but when you actually bother to build something
with them you hit the rough edges and missing pieces. I do not appreciate that
Chrome rammed them unilaterally down our throats, or that their Polymer
evangelists continue to flog these technologies as though they are somehow an
answer to the vast majority of problems web developers face.

~~~
amsheehan
React is an ideal version of web components in a world where ui = f(state)

------
kitotik
In my experience, the biggest cause of framework churn is bad architecture and
development patterns - no clear separation of business logic and 'framework',
which forces these all-or-nothing rewrites with the sexy framework of the day
in the hopes of a massive productivity boost.

If you can manage to get >50% of your core logic in a 'vanilla' language(js,
python, good ol' C) with minimal external dependencies, these yearly framework
shifts become much less of a big deal.

I just wish I had internalized this lesson way, way, way earlier in my
career...

~~~
autokad
I was once using angular, and I wanted to use a common thing I had done in the
past (autocomplete for a form I think it was). I already had a simple and
effective way of doing it in jquery, but getting angular and jquery to work
together is kind of a pain.

at the time, it wasn't implemented in angular very well, and there were some
specific things I wanted to do that was incompatible to the way angular did
it.

when I posted to the community how to get it working, their response was
'using jquery is not the angular way'. my way is getting things done with code
I have used time and time again.

it took a bit of wrestling, but I was able to get it done with jquery and
angular.

------
ralmidani
As I've said before, universal web components are a pipe dream.

Developers disagree on even the most trivial things, like the best way to
parse a query string. What makes anyone think those disagreements will
magically disappear once web components become a standard?

Sure, give us native APIs that allow developers to build web components. But
even then, people are not going to be abandoning their preferred frameworks.
Frameworks can change their internals to target the new native APIs, but on
the surface, they probably won't change much.

~~~
TimTheTinker
The goal of what folks call "universal web components" isn't (or shouldn't be)
to create a single universal UI library -- that would indeed be a pipe dream.

Instead, the goal is (or ought to be) to create a native, app-directed API for
creating and manipulating UI components. HTML and the DOM are a universal
content format and API, and we need its equivalent for web apps (as opposed to
content).

The web is a strange dualism between content and apps[1], and unfortunately,
the app side has been forced to implement its constructs on top of an API that
at its most fundamental level is built for presenting content.

[1] I like the diagram on page 33 of Jesse James Garret's seminal _The
Elements of User Experience_ :
[http://www.jjg.net/elements/pdf/elements_ch02.pdf](http://www.jjg.net/elements/pdf/elements_ch02.pdf)

------
hilti
It's mid of September so this can't be an April fool. Having read this
headline I was hoping that they are doing something more 'vanilla': just good
old Javascript for the core logic, HTML5 with data attributes describing the
markup of an app and CSS3 to for styling.

Instead they announce switching from Angular to Web Components before they
ship a stable version of their current framework. It's great for doing really
basic applications - but if it's getting into serious business their framework
is just too buggy and the incredible demand to rewrite the whole app in pure
JS becomes overwhelming.

I disagree that Ionic has found the end of the framework churn. What stays is
a mixed feeling of a click bait. At least to me.

------
caleblloyd
One of the reasons that React, Vue, and other reactive frameworks have become
so prevalent is because of Virtual DOM reducing the number of Physical DOM
updates.

Web components are a nice standard, but don't force reactive DOM updates. Web
components can contain their own script block and can do whatever updates they
want, breaking reactive patterns in apps. In order to keep a reactive app
behaving properly, developers will have to vet web components to ensure they
work properly with their reactive app. In all likelihood everyone will
continue re-implementing components in the reactive framework their app relies
on.

~~~
ergo14
You can use vdom, lit-html or hyperhtml to force that (so yes everyone will
use their favourite tool I guess, and that is a good thing). But individial
components can be shared and reused.

------
coldtea
> _To end Framework Churn once and for all, we need a way to create components
> that speak a language every developer and framework can understand. A
> component language that can be standardized but is also compatible with
> existing framework component languages._

Components are just one thing frameworks do -- among many other things. So the
existence of a 'standardized component format' wont do anything to reduce
framework churn.

Nor are Web Components going anywhere.

------
aargh_aargh
The reason for the churn is not lack of a standard for components. It's that
the ecosystem is both new and large, so many experiments are going on, some of
which become popular until the next best thing comes along. This won't be
solved by components. It will be solved slowly over time as innovation levels
off.

~~~
Sujan
To me custom components feel like one of the "innovations" that bring us more
to a state where one part of the equation will be "solved" and there won't
need to be any more experiments. It will just work. With all frameworks. And
that is great.

~~~
pjmlp
I look forward to see the Web finally catch up with 90's.

Maybe in a couple of years we get our Delphi and VB component designers and
toolboxes for the Web.

------
barkingcat
As much as hacker news frowns on humour replies. I really frankly laughed out
loud when I read

"To end Framework Churn once and for all, .... Thankfully, there’s an answer:
Web Components. "

I was expecting something like "Plain Javascript!" or something fundamental.

This is a content free reply, but I can't help but think this is the beginning
of another churn.

~~~
masiulis
I had the same reaction because it's ridiculous to claim that Web Components
can stop the Framework Churn when they predate most of the frameworks and
didn't stop the churn from happening.

There are fundamental shifts happening in UI development, but Web Components
are definitely not it.

~~~
lomnakkus
> it's ridiculous to claim that Web Components can stop the Framework Churn
> when they predate most of the frameworks

How on Earth do you figure that? I'm well aware that e.g. the <video/> element
is basically implemented as a Web Component in most (all?) browsers, but the
reason people are excited is that it's now possible for _non-browser_
developers to use Web Components and have those components work just like
native elements.

~~~
masiulis
> How on Earth do you figure that?

We were discussing Web Components at the time the Angular was getting popular
and before React was even released.

> for non-browser developers to ... have those components work just like
> native elements

Honest question, how do Web Components help native developers in any way?
Because from UI devs perspective, Web Components are useful only in a single
edge case - when you must make sure than it's impossible for Cascading Style
Sheets to cascade to your component.

For a developer, Web components are solving problems that almost no one has or
that were solved better by React and Vue.

~~~
lomnakkus
Do you not count e.g. jQuery as a framework? Angular and React are also pretty
late entrants. Before that there was Backbone, Ember, etc.

> Honest question, how do Web Components help native developers in any way?

Being standardized, i.e. any old framework that can work with the DOM can with
them, i.e. it reduces the number of truly necessary components to an "N"
problem instead of an "NxM" component. Simple as that.

(Let's say we're looking for a "scrolling/sortable table" component. N is the
number of different components along the 'features' axis. M would be the
number of frameworks (Vue, React, etc.). It's a _massive_ waste of resources
that M > 1.)

EDIT: Yes, frameworks will still be around and that's fine.

~~~
masiulis
> Do you not count e.g. jQuery as a framework?

Not really, it was used as a library to make JS work consistently across
browsers and add missing features like querySelector and ajax fetch. But it
had no opinion on how you should structure your app.

Angular, Backbone and Ember is from the same post-jQuery era when talks about
Web components started.

> Being standardized, i.e. any old framework that can work with the DOM can
> with them

But does a developer really care that it's possible to use the same component
in different frameworks, when you need it to work with just one (yours)?

I think the biggest fallacy is that people expect a technology to appear where
you could just drop the component and it would work perfectly. From my
experience, that will never happen - external component libraries are 90% what
you need and 10% of hacking around missing features. The easier it is to
safely and predictable hack the last 10% the better the framework/component
library is.

Web Components provide nothing that help in UI development:

Helps manage multiple components state? Nope.

Provide a declarative API for components? Nope, imperative - the one we are
trying to get away from.

Prevent CSS from affecting components? Cool, or I could just not write global
styles, use BEM or CSS modules.

Easy to share components? NPM still works just fine for that.

> It's a massive waste of resources that M > 1

Agreed, that's something I thought a lot about. So I have created a cross-
framework visual component editor - one component exports to many frameworks:
[https://github.com/UgnisSoftware/ugnis](https://github.com/UgnisSoftware/ugnis)

~~~
lomnakkus
> Angular, Backbone and Ember is from the same post-jQuery era when talks
> about Web components started.

Really? Maybe I was just out of the loop. I hope we can agree that Web
Components were little more than a gleam in somebody's eye at that point,
right?

(I'd love if you could point to any relevant mailing list/google groups
discussions or whatever around this time, because apparently I missed 'em.)

> But does a developer really care that it's possible to use the same
> component in different frameworks, when you need it to work with just one
> (yours)?

Yes! I often have to work with multiple frameworks. Also: It'd be _fanstastic_
if I had a choice matrix of "N" vs. "MxN" when I had to choose an
implementation of, say, a scrollable-live-loading-table. That would be
amazing, especially since we'd already decided on the "M" axis and written 20k
LoC! I could choose the _very_ best feature set for me! Ok, I might have to
write a thin "shim" to have it interact with React or Vue.js or whatever, but
the point is that this would be a trivial shim. I wouldn't have to rewrite the
whole frontend when $BOSS decides that they want SuperLongUberTable.

The mere fact that the contents of such a table are just DOM nodes would also
mean that I would be able to publish (as OSS) our own implementation of said
beast... to much acclaim and prestige.

I also appreciate the fact that changing "NxM" to "N" means that (eventually)
we'll get higher-quality components. For example, the components shipped in
your browser are actually quite good. How many "good" video players did you
see before HTML5 <video/>? My point is: The fact that anyone can write them
means that there'll be a sort of evolutionary competition which tends towards
an (admittedly, local) maximum -- but it's not as if the framework world has
done much better, so... (Of course this is _still_ at least a little
hypothetical. We'll see, but I'm cautiously optimistic.)

EDIT: I might not have articulated it, but I think it goes without saying that
I obviously want _all_ components to evolve towards the "stateless-and-emits-
events-to-container-components" model of e.g. React... and I think that _will_
happen because it's simply easier to integrate into _any_ framework.

~~~
masiulis
> I'd love if you could point to any relevant mailing list/google groups
> discussions or whatever around this time

I heard about Web Components spec in late 2012. There are some blogs from
around that time: [https://hacks.mozilla.org/2013/05/speed-up-app-
development-w...](https://hacks.mozilla.org/2013/05/speed-up-app-development-
with-x-tag-and-web-components/) In five years not much has changed.

> Yes! I often have to work with multiple frameworks.

There is an easier solution to this than Web Components - using a single
framework. Unless you are a consultant same as me, than we can only blame
ourselves for having to deal with this.

> My point is: The fact that anyone can write them means that there'll be a
> sort of evolutionary competition

That's not what happened with React component libs (material-ui, react-
toolbox, etc.) - none of them has "won", all of them are pretty similar in
quality. I would say that quality of a component is less important than how
easy it is to adapt them to your business needs is.

My point is that having more ways to create a component is irrelevant -
Framework churn existed not because we couldn't share components, but because
writing components and managing state was awful. Web Components are still
terrible at both of these things.

The good thing is that there hasn't been any new JS innovations in three years
since React, Cycle, Elm, ClojureScript boom. And I would claim that there is
not going to be because we are limited by the textual representation of our
programming language. So the Framework churn ended not because everything is
perfect, but because we couldn't make UI development better.

~~~
lomnakkus
> There is an easier solution to this than Web Components - using a single
> framework.

Yes, we all know how easy that is. I mean, really, come on -- that's not
realistic in any reality.

EDIT: We all know the "n+1" standards XKCD joke, but the reality is that
standards (HTML, CSS, HHTP, DNS, TCP, UDP, IP, etc.) brought us the fucking
Internet, flawed as those standards may be. As I said, I'm cautiously
optimistic that standardizing "custom DOM" will eventually get us to a
standard slightly above raw HTML.

~~~
masiulis
> I mean, really, come on -- that's not realistic in any reality.

Huh? Most projects use a single framework in a project, sometimes two if they
are migrating. If I had multiple frameworks in my project, sharing components
between them would be the least of my problems.

> standardizing "custom DOM" will eventually get us to a standard slightly
> above raw HTML

I understand this sentiment, but DOM is irrelevant to front-end work right
now. DOM is just a render target for frameworks, making DOM smarter changes
nothing.

------
zackify
I've been using the same JS framework for 3+ years. I don't agree with all of
these complaints on JS churn being too much. Web components aren't the answer
either.

------
interlocutor
Web Components solve a number of problems with other component libraries such
as React.

React components are brittle. The brittleness comes from the global nature of
HTML, CSS, and JS. The DOM tree inside a React component isn't encapsulated
from the rest of the page. This lack of encapsulation means your document
stylesheet might accidentally apply to parts inside the widget; your
JavaScript might accidentally modify parts inside the widget; your IDs might
overlap with IDs inside the component; and so on. This means React components
cannot be safely reused.

Web Components solve this problem. What's more, you can use JSX with Web
Components (to implement Web Components as well as to use Web Components). See
here:
[https://github.com/wisercoder/uibuilder](https://github.com/wisercoder/uibuilder)

~~~
catpolice
I was really pumped about Web Components at first, largely because this sort
of argument made a lot of sense to me. A few years on, I'm a lot less
convinced that these are the problems that need to be solved.

Element IDs, for example, are useful if you're doing a kind of old-fashioned
select-and-mutate approach to DOM management. But if you're using React
idiomatically, you're never running query selectors or ever reading from the
DOM at all (modulo trivial things like getClientHeight in lifecycle methods).
It's hard to imagine when you'd have an ID conflict with React because it's
hard to imagine when you'd need an ID.

Similarly, over the past few years I've had maybe two or three cases where CSS
leaks due to under-encapsulation were a problem, and I was able to pick up on
them and solve them with very little effort. Over the same period I've devoted
much, much more effort to solving problems with over-encapsulation in cases
where I needed to style a supposedly reusable component but some clever
attempt at encapsulation (e.g. inline styling) prevented me from doing so and
forced me to do a lot of work or re-implement the component wholesale.

I've known a few projects that were excited about things like Shadow DOM and
went through a lot of work to incorporate them only to end up stripping them
out (see Atom: [http://blog.atom.io/2016/11/14/removing-shadow-dom-
boundary-...](http://blog.atom.io/2016/11/14/removing-shadow-dom-boundary-
from-text-editor-elements.html)) for related reasons.

So at this point I see a lot of the touted benefits to things like Web
Components as a potentially painful set of solutions to a set of problems I've
never really had. I don't really get it, but maybe they scratch some itch I
don't have.

~~~
interlocutor
Here's an example of why you need IDs:
[https://stackoverflow.com/questions/29420835/how-to-
generate...](https://stackoverflow.com/questions/29420835/how-to-generate-
unique-ids-for-form-labels-in-react)

CSS name clashes are an issue if you have to incorporate independently
developed React components.

~~~
catpolice
I guess I'm not saying that there aren't conceivable situations where you'd
need an ID - it's just that they're typically small issues that are easily
worked around. A duplicated "for" attribute problem is going to come up when
you have two forms on a page and both of them use labels in this way and use
conflicting IDs. There's a potential collision, but it's relatively easy to
foresee and prevent, I've never seen it come up in practice and the worst
outcome when it goes wrong would be something like the user's input focus
going somewhere unexpected if they click a label instead of a control.

W.r.t. CSS name clashes, yeah they can come up especially in the contexts of
independently developed React components. But in my experience over-
encapsulation comes up far more often in the same context. I'm almost never in
a situation where I want to slot a component in as-is. Instead, I want some
find grained control over its styling or behavior, and if that's hidden behind
an encapsulation barrier, that makes re-use even harder.

I do think the React component paradigm has some issues, but IMO they're the
same sort of issues that come up in a lot of OO designs where abstraction and
encapsulation happen in the wrong places. I still feel like Web Components
solves some re-use problems I rarely if ever see in practice while doubling
down on ones that I do.

------
revelation
Web components are syntactic sugar and a registry (yes, Java coming to a
browser near you!) around the following:

    
    
        interface Component { void render(); }
    

If you think this somehow solves all JS framework issues, I have a bridge to
sell you. Or there was never a meaningful problem in the first place.

------
bandrami
OK, so we'll spend a year moving the unwieldy multitude of frameworks to
instead be inside web components that will be distributed just as wantonly as
frameworks are now. What's really gained there?

------
tabeth
As long as there's something to gain for an aspiring developer by creating a
_new_ framework, there will always be churn as there will always be new
frameworks. Rather than reducing churn we should aspire to make it less and
less painful to the point of irrelevance.

Some ideas:

Standardization of certain APIs (see the craziness in the Javascript world
regarding promises, though that night not even matter with 'async')

------
placebo
>The era of Framework churn is coming to an end, and now we can all go back to
working on what makes our apps unique instead of spending precious time,
energy, and money jumping to something new every year.

I believe this to be naively optimistic, but I'm all for Web components or any
other development that help simplify things a bit. It's just that there will
never be any silver bullet. I can make a list of the types of "The era of
<Problem X> is now over and from here on it will be smooth sailing forever"
that I've witnessed followed by the introduction of <Problem Y> that couldn't
be anticipated. In a world of exponential complexity and creativity, I don't
think this cycle is avoidable. It seems that the best we can hope for is that
the rate that initiatives of abstraction, consolidation and standardization
will manage to keep up with the forces (market and other) of defragmentation
and growing complexity.

------
joshiefishbein
Web components don't take care of the full ecosystem that is the front-end and
will prove irrelevant to framework churn.

If anything, web components make framework hopping marginally easier resulting
in a more likely (marginally) exodus of a framework when something new and
shiny comes by.

Front-end framework churn is ultimately a result of the ever-growing
Javascript community and its relatively fast-paced development. Because we now
treat the front-end as seriously (and formally) as we treat the back-end and
server/service stack, we will see the constant invention/innovation/adoption
cycle that we see in these aspects of technology.

Framework churn is here to stay until browsers change the way the front-end
works altogether.

------
H1Supreme
I've been wanting to use Web Components since Polymer was pre 1.0. But,
browser support still has a ways to go. I think we would all love a solution
that has all our dependencies baked into the browser.

But, until that actually happens, I'll carry on using Vue.

------
jl6
They say history repeats itself, and I feel we have been here before. Is the
web framework landscape not a little like the Windows desktop in the 90s? What
does history say will happen next?

------
danieka
Considering how jarring the change from Ionic to Ionic 2 was (we haven't yet
had time to migrate our 30k line app) I'm kind of worried how the upgrade path
looks from Ionic 3 to 4. Moving forward is good, I suppose. But I would have
appreciated some information on what this means for us that have yet to
migrate to Ionic 2/3\. Should we wait for version 4 to be completed?

Anyone have any input for a confused developer?

~~~
Sujan
From what I have seen and heard, upgrading to v4 will be a bit more work than
from 3.5 to 3.6 - but not nearly as big as the v1->v2 transition.

Here is a currently working link to a branch where this is developed (pre-
alpha, so can change of course): [https://github.com/ionic-
team/ionic/tree/core/packages/ionic...](https://github.com/ionic-
team/ionic/tree/core/packages/ionic-angular) & [https://github.com/ionic-
team/ionic/blob/core/packages/ionic...](https://github.com/ionic-
team/ionic/blob/core/packages/ionic-angular/BREAKING.md) As I see it mostly
the syntax and attributes of components were cleaned up.

Ionic Framework is still fully based on Angular, it will just be using Custom
Components (bundled in a package called @ionic/core) inside instead of the
"Angular built Components" (no idea how to name these...) in v2+3. These
custom components are built using the Stencil compiler by the Ionic team, but
as a Ionic Framework user you won't (have to) come into contact with that at
all.

These new components can be used in other frameworks like React etc as well -
or even AngularJS (Ionic v1!) or plain Javascript.

An alpha of v4 is planned pretty soon I hear.

~~~
danieka
Thanks, that's comforting to hear.

------
halis
We have the revolutionary answer to framework churn! Nothing will ever be the
same! Ya'll ready for this!

Behold! Web Components!

Can someone please queue the Picard facepalm meme?

------
z3t4
Or you could just ditch HTML and XML, and use only JavaScript and CSS. You
still use elements like input, button img, but under an abstraction layer.

------
tabtab
Tag based interfaces? Sounds kind of like client-side Coldfusion.

------
pkrumins
You should never be using frameworks.
[http://www.catonmat.net/blog/frameworks-dont-make-
sense/](http://www.catonmat.net/blog/frameworks-dont-make-sense/)

~~~
coltonv
This is an extremely short sighted article. It points out potential weaknesses
of frameworks and then concludes unilaterally that they should never be used.
This doesn't help anyone. Without the Rails framework my job would be
significantly harder since I'd have to piece together several libraries for
ORM, HTTP requests, DB Connections, etc. This would be significantly _more_
cumbersome than just using a framework, since any one of those libraries could
go defunct just like a framework could. My only other option if I can't use a
framework is to write my own implementation of _every single core feature_ of
rails. No thank you.

Use frameworks when they are appropriate, stand on the shoulders of others who
have made significant contributions to the community.

------
hprotagonist
_To end Framework Churn once and for all, we need a way to create components
that speak a language every developer and framework can understand. A
component language that can be standardized but is also compatible with
existing framework component languages._

[https://xkcd.com/927/](https://xkcd.com/927/)

~~~
majewsky
I'm downvoting this because this is a knockout argument: People use this comic
way too often to shush those of us who want to have a debate about whether a
standard would be useful in a particular situation. I don't think this was
Randall's intention when he did this comic.

~~~
coldtea
> _People use this comic way too often to shush those of us who want to have a
> debate about whether a standard would be useful in a particular situation_

And more often than not, they are right.

In this particular case Web Components only solves part of what frameworks do,
and solves it badly. As badly as CSS solved the layout problem the last 2
decades.

I wouldn't mind a nice Web Components solution, but the current design reminds
me of the over-engineering of things like Swing and JSF.

~~~
marcosdumay
> And more often than not, they are right.

And yet, every time that the number of standards is reduced, it is by this
same process.

So, yes, it is the one way to do it. And yes, more often than more, it fails
completely. So, let me ask you, what is the point of complaining that somebody
is going through that?

~~~
coldtea
> _And yet, every time that the number of standards is reduced, it is by this
> same process_

Is it? I'd say it's usually rather because:

(a) Some of the competing standards wither and we get rid of them.

(b) Some standard emerges as the winning one and is adopted by everybody.

But very rarely by the addition of a new standard.

~~~
marcosdumay
So, some standard emerging does not require creating standards?

And for competing standards to wither, there somebody must have created the
other standards too.

~~~
coldtea
> _So, some standard emerging does not require creating standards?_

I wrote "emerges as winner". Not "emerges period".

Which does not require creating a NEW standard on top of existing ones (N+1),
since an already existing standard (of N) can emerge as the winner.

------
dehef
This is totally a shame.

I'm watching the conference where there are saying that "that is not yet
another frameworks" but come on, that IS TOTALLY A NEW JS FRAMEWORK.

Let tell to a recruiter that you work 3 year on angular 1, 2 year on angular
2, but no really you feel you are ready for web component but you already
failed your job interview, because you are a distancied old programmer working
on old'good angular 4.1.3

Guys at ionic, you should work to correct your current version totally buggy
(I know what I say, I will soon release my first app that I worked 5 month
full time on)

Next time for sure I will stick with angular cli and a naked cordova

~~~
Sujan
Ionic Framework users won't come into contact with Stencil at all, just with
the custom components built using it. The old `ion-textarea` (for example)
will be replace with a new one that was compiled with Stencil.

So no, this is not a new JS framework that will be relevant to framework
users.

