Okay, I will introduce, starting from our left, Silvia Moore. It's an organizer at AUSJS and developer at Typeform.
So, welcome Silvia.
Silvia was talking about Meteor, but Meteor is a little bit outside this domain, because it's a platform, actually.
They're not very tough as a framework, as a platform. It can work with Angular and React as well, for doing the backend and the frontend at the same time.
But, actually, she has worked with Angular, and in Typeform she's working with React and React, so she's a very expensive person for this debate.
Okay, so, the next one is Raul Kimeth, is a global developer expert and CEO by default.
Okay, she will be speaking about, he will be defending Angular.
And that's it. The next one is Philip Desmed, I named it currently, first and last.
He will be defending Angular. Yes, he's the CEO of Intuo, which is a platform for HR teams.
And the last one is Kauramon, he's the CEO of Factorial, he's a surgeon here, in it.
It's also HR. HR, yeah. We're not competitors.
Okay, we're switching to HR platforms.
The next one is going to be HR debates.
And he will be defending React as. So, okay, welcome everybody.
So, first of all, we are going to start with a round.
We are going to reverse everything now.
And you have a maximum of five minutes. I think five minutes is too long, actually.
So don't worry, you will not feel that.
But I will stop you at five minutes.
To talk about these pros and cons of the framework that they are defending and why you choose them.
Okay, that's fair.
So, as I said, I'm Paul.
And my experience with front-end development comes from the very beginning with Czech query.
Then I jumped into the wagon of backbone.
And actually, we did an event in this very room.
It was a framework debate. And I had to defend backbone, which probably if I see the video right now,
it would be a little bit embarrassing, but it's fine.
And I guess it's going to be the same when I see the video about React today, but it's fine.
I see this as a disclaimer.
So, basically, I was CTO before at Red Booth, before starting factorial.
And we had a huge code base with backbone and marionette.
And it was really, really painful to deal with state, basically.
And when React started to become more prominent, the thing that, for me, it was more obvious,
and it was unlining, it was a unidirectional flow.
So, basically, the fact that you have to only declare how the views have to render the content.
And then you can deal with the content, and then, automatically, the views get rendered.
So, this, for me, was amazing.
And the fact that it was only state and components, the composibility, it was really good.
That being said, I'm not going to defend React over the other frameworks.
I think it's quite good that there are many frameworks.
So, all the frameworks learn from each other and also compete about each other.
But, if all of you would use React, it would be amazing, because then I don't have to change framework
in four years like happen with backbone.
So, that's my second point is when starting in factorial.
So, obviously, we had to decide the stack.
And it's always the same.
Like, do I go hipster and I choose something like VUGES, or like ELM, or whatever?
Or do I want to use something I know, or something in between?
So, looking at all the profiles of what people that I wanted to hire, or, you know,
like, more or less about the community, I decided that React had the most, or, like,
the biggest pool of people that wanted to work with it.
And that was one of the decisions that I took.
It was to use React, because I thought the pool of candidates, if I had to assemble a team
for front-end development, would be bigger.
So, I wouldn't say all the pros and cons have to be on the technical side.
I actually think all the frameworks exposed today, none of them give you a competitive advantage.
Like, oh, if you use Angular, Ember, or React, you're going to be like 10x.
So, in this sense, I decided more about React, because it was the most popular at the moment.
I think that's it.
Okay, thank you. So, Philip, can you talk a little bit about Ember, pros and cons?
Yeah, definitely.
So, I really like what Paul said, by the way.
Thank you.
Because I was just 10 minutes ago...
You're not going to fight.
You're going to start drinking here.
That's a great reaction.
10 minutes ago, I was just talking to a friend, and he said,
I really hope this doesn't turn into, like, a front-end flame war.
So, I was like, well, let's see.
But I brought my list of notes of the pros of Ember.
But first, I think if you talk about, let's say, the big tree, Angular, React, Ember,
we're like the ugly little brother, maybe,
because no one really likes to use Ember if you talk to him.
A lot of people don't even...
or haven't even looked into Ember, and I think that's quite a shame,
because even though it might not be that popular,
it's backed by a lot of great companies, especially in the US.
So, if you look at Yahoo, LinkedIn, they use Ember a lot.
In fact, if you right now go to the mobile site of LinkedIn,
it's completely written in Ember.
All these nice and quirky animations there in Ember.
Something that people probably don't know is also Apple Music.
Apple Music, apparently, completely written in Ember.
Even though it's a desktop app, it's probably a wrapper around an Ember app.
So, I thought that was pretty cool.
So, even though it's not a big household name, such as Facebook and Google,
Ember has decent backing by companies,
and I think that should not be forgotten.
So, next time you open up Twitch, for instance, are there gamers here?
If there are, Twitch is completely written in Ember as well.
Anyway, I'm going to shut up about the companies using Ember now
and going into the real pros.
We use Ember as well, by the way.
And we're hiring.
But I think the biggest pro for me in Ember
is a concept people call in the industry convention over configuration.
I compare Ember a lot to Rails in the sense that it just works out of the box.
It comes with build tools, it comes with HTTP mocking,
it comes with a development server.
It's got everything you need, basically.
You're up and running in a day, a few days,
maybe in comparison to maybe something like React.
You have to choose your own whole stack, like frontend stack.
I mean, you have to choose Redux.
You can plug it into an existing application, fair enough.
But then you have to use Redux, Redux i or whatever you want to use,
which is also very powerful.
But I don't think these, let's say, architectural decisions
should be left up to the people wanting to use a framework.
But that's, like, obviously everything that's going to be satirized in an opinion.
And that's my opinion around that.
Another really strong point, I think, with Ember,
are the releases and the release cycle.
So every six weeks Ember does a release.
So whether or not there have been big improvements,
after six weeks it goes up into a minor version.
So they use semantic versioning. So now we're at 2.10.
In six weeks we're going to 2.11.
Whether or not there have been significant features built or whatever.
It's just going to be that.
Next to that, they also do LTS releases.
So if you're familiar with Unix, like Ubuntu, Linux,
they do that a lot.
So LTS means long-term support, by the way.
So if you use Ember 2.8 right now it is,
they will still release security updates for another, I think, 18 months at this.
So there's no JavaScript fatigue,
as in the sense that you don't have to upgrade if you don't want to.
And the Ember core team really thinks of it as a long-term project.
And it's really open source. They really work together.
They publish RFCs, like, you know, requests.
If someone wants to build a new feature, they really discusses as a team.
Where I think, if you look at React or Angular,
they are driven from a company point of view,
from Facebook and Facebook says,
we need to build this and we need to change it.
It's going to be changed.
Actually, in these front-end frameworks,
the exception is Ember, I mean, on the front-end part,
because we were talking before about it,
but we are almost discussing about Google or Facebook.
Because it's one is Facebook-driven, another is Google.
Oh, Jehuda.
In fact, it's my company, actually, but it's not Facebook or Google.
En fact, Ember was a hard fork of Sproutcore.
Sproutcore was developed by Apple in-house as a front-end framework,
but that's like six years ago, like when they forked.
But still, there's not really a driving force,
let's say, behind Ember as a framework.
So I think that's actually a pro.
I've got some other things, but yeah,
I think these are the most important ones.
I'm realizing we're not talking about the cons.
We're just saying the good things about it.
Yeah, but I have questions for this, after this.
Okay, this is not an interview.
I want you to throw bad things against the others,
but let's have a space now.
Okay, so Raúl, can you talk about Angular and that word?
Well, I've been using Angular for the last, I don't know,
five years, something like that,
so I have a lot of experience with Angular.
Before that, I was an action script developer,
so I worked with Flash, yeah, with Flash, you know?
Actually, that was a good thing at that time
because the good thing about Flash is that they use ECMAScript,
and I worked with Flash for 10, 12 years,
I don't know, a lot of time,
and the good thing is that I really, really, really
had a good understanding about all the product I,
and how ECMAScript works under below, you know?
And when Flash, you know, just was deprecated,
because it was deprecated.
I started looking to a new framework,
and back in the time, it was Ember,
it was Ember 1.3, something like that,
it was also a backbone, back in the time too,
and it was the early versions of Angular.
And I really, I've done, you know,
these pet projects with three frameworks,
and back in the time, I just choose Angular
because the template framework was very friendly for me,
and it was very familiar for me too,
for my background in Flash,
because I worked also with Flex,
so I said, okay, I can maybe do something like what I've done
to create custom elements, custom tags in JavaScript,
so that was super friendly for me.
So I think that this is something
that usually happens with developers,
you know, when you approach to a new technology,
you usually start working with the technology
that is more friendly for you, right?
And actually, right now, Angular has been involved a lot,
Angular 2 is, you know, a big step forward.
It's a big change, I will ask you about this.
It's a big change, yeah, obviously.
It's a big change, but if you see how the framework works,
it is basically the same thing.
I mean, obviously you can't just port an Angular 1.x
application to Angular 2.x
because it's going to be a pain in the ass.
We know that thing, that's obviously.
But the good thing is that the knowledge that you have learned
on Angular 1, it's completely useful in Angular 2.
So that's a very good, very good, two good thing.
Okay, okay.
I think, actually, the names of the things on Angular 2
and Angular 1 to Angular 2 have changed a lot.
Not that much.
I mean, all the directives basically have the same names.
It's just how you write these things.
But when you have learned how it works,
which is super easy because the new templating framework,
it's super easy to learn.
It doesn't have all the drawbacks and all the traps
that you can find in Angular 1.
When you learn that thing that can cost you one morning
understanding how the templating framework works,
then it's done.
You can just understand how Angular 2 works.
Super easy.
On the other hand, another thing that is super powerful
in Angular 2 that I really like,
it's something that is being mimicked by the Ember team,
actually, which is the Angular CLI.
No, no, I like this.
I like this.
And back in that time, I really liked the work
that Ember have done with the CLI.
Now I think that it's super powerful.
I really wish that Angular will have right now the Ember CLI
because it's awesome.
But the Angular CLI, it's improving every day.
Every day, it's even better.
And I think that, eventually, the Angular CLI
is going to be really, really good.
That's good, maybe, as the Ember CLI.
If I'm not mistaken, Angular CLI uses Ember CLI
under the hood, no?
Yeah, yeah.
I'm not trying to explain.
They are migrating.
At the same time, Ember CLI is based on Broccoli,
which is, like, the best pipeline, but still...
In any way, I mean, they are moving also to Webpack.
So you can use the Broccoli version and the Webpack version.
I think that right now, the Webpack version,
it's kind of more popular.
I'm using the Webpack version of the Angular CLI.
And I think that, on the final release,
all the Broccoli stuff is going to be removed
and they are going to embrace Webpack for the win.
And another thing that it's also super powerful in Angular 2
that it's only available in Angular 2,
the other framework that doesn't have this feature
is the Ahad of Time compilation.
With the Ahad of Time compilation, basically,
it's going to take all your HTML templates
and compile those templates to JavaScript.
And then they are going to interpret those JavaScript,
those templates in JavaScript,
and release a bundle size, super minimal.
You answered me before I made you a question.
Yeah.
And this, and the code that is generated
by the Ahad of Time compilation,
it's interpreted almost instantly
by the virtual machine, by the JavaScript virtual machine.
So that makes your app super fast bootstrap.
I mean, we are talking about an application
that has a lot of JavaScript
with, I mean, 200 kilobytes of application,
300 kilobytes, 500 kilobytes,
that can start up in less than a second
or one second or less than two seconds.
I read that Angular, I thought that Angular,
and the bundle of Angular and RXJS,
it's like 800 kilobytes out of the box.
Yeah, but if you used reshaking
and the Ahad of Time compilation,
you can have that in 25 kilobytes.
Wow, it's pretty amazing.
Okay, so, okay, move on.
Meteor, okay, we understand.
It's a little out of this debate,
but it's actually an interesting point
about, we want to help about Meteor,
because it's an option that you can start
developing all that Angular things
or React things.
I don't think Amber is included in this bundle
because there is a recommendation
for Blaze, Angular, and React.
But you can use Meteor as a platform
to serve that front-end applications
and with the same code, actually,
because it's in the models and that stuff.
People always think in Meteor, right?
So, can you talk a little bit about Meteor?
I have to say, whenever I've worked with Meteor,
I've always used Blaze.
So, if you have questions regarding
how to use Meteor with React or Angular,
I'm going to let you down, I'm sorry.
But I think it's a really good idea
that they, whoever came up with this idea
was very smart, because Blaze,
it's very easy to start with Meteor,
which is cool, and once you get to,
once you want to do more complicated things,
you, right away, realize, Blaze is a bit limited.
So, I think having the possibility
of using React or Angular 2 is really good,
because if you already have experience with those
and you can take advantage of the good things of Meteor,
it's a win-win, I think.
Having said that, I think the best feature of Meteor
is the real time, the data synchronization.
Yeah, because it does it on solids, right?
Yes.
And, well, that's,
there's one good thing about it,
and one not so good thing about it,
is that it's out of the box,
it comes, you work with MongoDB,
Mongo Databases, but it's, I know it's not impossible,
but it's super difficult to work with
any other type of databases.
I think it's even, a bad idea to even try,
because it, and also, why would you,
if it's so easy to use Mongo, right?
Because it's Mongo.
If we talk about databases, I always ask people,
why would you use Mongo, indeed,
because SQL, it just works,
why would you use anything other than SQL?
So, you're rather a rivaling another debate.
Sorry, sorry, sorry.
No, no, no, no, no, no, no.
Yeah, I'm sorry.
I prefer a Cellbotless.
Cellbotless, okay.
Okay.
I don't know.
Also, after using Meteor for a while,
not so much, actually,
but I mean, I have more experience with Angular.
regular, I have to say.
I will answer you about the act right now.
But I think there are many good things about Meteor also,
that it's a platform that allows you to do front and back
and both in JavaScript, because it's based on Node.js.
And so that's good that your whole team of developers,
they only need to learn, they only need to know JavaScript.
But at the same time, they are a bit coupled,
front and then back end.
So it's also not so easy to isolate teams.
You could have a team working on an API
in a very different language.
But in this case, it's not so easy.
And also, from my experience, I think there are really not
so many scenarios where I'd recommend using Meteor.
Because if you don't really need real time, if you don't
really need your changes being pushed to the client as a
necessity, it may be a burden to use Meteor.
And so the first Meteor application that I built was a
challenge that I had myself.
Yeah, a side project.
Yeah, it was a side project, but it was also depending on
bonus in my previous company.
So I was very interested to.
Nice motivation.
But also, I thought, OK, if I'm going to get a bonus for
something, at least let's do something that I really want to
do at home and that I can have fun doing it.
So I thought, what could be the best use case for such an
application?
And I think it's games.
Really, it's games.
Because you need to have that real time, fast data
synchronization.
And so it was a sort of board game made web application.
Another good thing of Meteor is that you can easily create a
smartphone application with the same code base.
You can build for web, you can build for iOS, and you can
build for Android.
It's integrated with Cordoba, Apache Cordoba.
I, myself, didn't get to that phase of my project to build
it for Android.
But I made it responsive.
So I could use the web app on the phone.
And it was on the first time we used it in my company.
We had this presentation.
It was a group of 20 people.
And we played the It's a Werewolves game.
I don't know if you may know it.
It's a board game, actually.
We play with cards.
And everyone was surprised at how fast it was.
And it's for sure.
And it was only 20 people in the world playing it at the
same time.
But it's super cool.
And it didn't take me long.
I did it in two weeks.
And I've kept improving it.
This is one of the good points of Meteor, bootstrapping.
If you need to bootstrap something, it's like, if you're
doing it with Meteor, you're going blazing fast.
I didn't prepare that.
No, but it's like, you're going so fast.
Bootstrapping this.
But then, if you're going in prediction mode, and you need
to have high scalability, I think stocked to
are too expensive, right?
Yeah.
I think it used to be a bigger issue in the past.
I haven't been using Meteor in the last few months.
And I'm actually not sure what version they are currently
in.
But I know it used to be a big issue to scale.
But nowadays, there are some tools, like there's one that's
very popular, that's named Cluster, that allows you to do
horizontal scaling easily.
By adding machines.
And that's not an issue anymore.
But I didn't know that.
So I think that wouldn't be a reason not to try Meteor
anymore.
Because I know that was, whenever you look on Google,
most articles of people asking, should I use Meteor?
They are worried about that.
That's their biggest worry.
Yeah, so I can try it elsewhere.
And also, that's also one good thing of Meteor, when you
just start, it's easy to get things done.
But when you want to improve performance, you have to really
go into detail tweaking the configuration of your
collection so that you don't impact performance.
But yeah, it's fun.
So I want to ask you about those frameworks that you work
with, Angular, which I think it's your preferred.
And React, which is the one that you're working with.
So it's a very good story for you.
So do you have anything to add on what those guys say?
About Angular or Angular?
There are what I like Angular.
I like Angular for reasons that I also like React on the
opposite side, with this kind of crazy.
But I like Angular very much.
When I started, I started with Angular 1.
And it was like, I get all I need from Angular alone.
And obviously, I can download packages, third-party
libraries, but with the bare Angular package, I have all I
need.
I have routing, I have templating, I have.
Yeah, it's all outside the wall.
And for someone that doesn't want to spend so much time
researching which tools I should use, that's great.
But then, if you are the kind of person that doesn't want to be
so type, and so your hands type, it's like, I want to choose
my own packages.
So that's also cool for React.
I heard about it a lot, but I don't heard about the name
app-emulated versus unapp-emulated, which is one
of the topics that split this debate.
It's like Angular and Amber are very app-emulated.
This means that the framework can tell you how to develop
your application.
They are telling you the way to do it.
Do you want to do routing?
This is the way to do it.
And React, by the other way, is very unapp-emulated.
And it's like, you want to do routing?
OK, do it yourself.
Or find something that you want, something that you want.
So yeah, I think it's a really bully point, and it's
actually, this is why I complain, that we only talk
about the good things.
So I didn't talk about this, for instance.
I think this is more political or philosophical, which is
really weird, because, for instance, I'm a real guy on
the backend.
I want the decisions to be made, but on the front end, I
really like to choose my dishes.
So I think, in the end, and you can find this in any
technology, there's always this dichotomy of the people that
don't want to make a decision, and the people that do want to
make a decision.
So React aligns more with the Unix philosophy of the right
tool for the right job.
The only thing is that you spend a lot of time figuring out
which tool is what.
But that's the only thing.
So I do agree, React takes quite a lot of time, and a
learning curve, it's really steep because of that.
Because you have to assemble your stack.
But then the good thing, if there is, or if people value
it, is that you can actually assemble the right stack.
So for instance, when I was starting factorial, I really
wanted to have typing, like incremental typing.
So basically, I had two choices, TypeScript and Flow at the
moment.
So Angular, for instance, comes with TypeScript, which I
think is great.
But at the moment, they didn't have nullable types.
Now they do.
And for me, that was something that I really wanted.
So I was really grateful that in React I could choose to use
these, and so on.
So I think it depends on the kind of person and who you are
and what you want.
So for instance, in my opinion, in the back end, I
prefer my decisions to be taken.
In the front end, I want to take my decisions and choose
what I like most.
At the expense of the time.
This is maybe a problem from React, because I can't.
A problem, and an advantage.
No, or I'll find it.
Actually, the adoption of React, it's very, I think, no,
it's not low.
Not at all.
It's not at all.
But it's less than it has to be because of this thing.
Because some developers want some guides to do something.
We have done a remove.
That's a good thing.
And the fanboys.
Tara.
OK.
We will talk about the evangelies later, because in React
we have the Annabra Moff, but in Angular we have...
Raúl?
Really?
No.
Raúl?
No.
In Angular, which one is the evangelism of Angular?
What is the Annabra Moff of Angular?
Fygor Maynard, or Misco Hevery.
Yeah, OK.
No.
But they are the creators.
They are not...
It's not my personal choice, but I would say John Papa is one of the creators of this
Angular style, so how to do things on Angular.
Yeah, well, John Papa, you've created this Angular style guide.
Yeah.
Yeah, which is pretty similar to what...
There is something similar in React, which is from Airbnb.
Yes.
Which is the Airbnb React style guide.
So John Papa wrote something like that.
Yeah.
And a lot of people follow in it.
I like that the style guide.
I don't follow all the rules, but I think that it's good, yeah.
Yeah, it's a good starting point.
Yeah, for me, it's not the same, but this is why I'm talking about those guys, Danerof,
and this guy at the same time.
But John Papa hasn't done something like RIVAX.
Like Danerof did, and obviously Adan was hired by the Facebook React core team because of
obvious reasons.
But I put them on the same page, because it's the guy that you go to.
Because Danerof created RIVAX, but one of the most things you do, or you take from Danerof
is the style guide, and the patterns about the presentational, this famous article about
presentational containers versus presentational components versus container components,
and it's the same as John Papa.
This is why I talk about them today.
So it's kind of a style guide.
So yeah, I'm sorry, I was talking about that.
I would say, in terms of the choice, I think to wrap up, and maybe you see it differently,
but I think on one end of the spectrum, there's React, where it's Unix philosophy,
you choose the tools, you assemble, it's your job to figure out, which is hard, but can be rewarding.
I think the opposite side, it's Ember, where actually everything is chosen for you,
where you spend zero time choosing, if you want to switch something or change something.
I mean, it's like in Rails.
There's Rails way, and it's not, I mean, I think it's...
It's from Yehuda.
It's a frontend on Rails.
Yes, exactly.
They say it's a Ruby on Rails or frontend.
And I think Angular, maybe I'm mistaken, because I haven't worked much with it.
It's probably something in between, because I heard you can switch off the two-way binding,
you can use different state management tools, and so on.
It's a little bit like, you get everything included, but you can still,
if something is online, you can swap it out.
Yeah, you can change the two-way data binding to one-way data binding.
You can choose that, for example.
But it is basically a convention over configuration.
And...
It opens a door to configuration.
Yeah, yeah, you can tweak a few small things.
Not too much, but yeah, you can tweak a small thing.
I read, yesterday, I was googling React versus Angular, so...
I think we were all in the same thread, so...
And while Ember chooses everything for you,
I've actually read on the internet as well some guys that switched Ember data,
which is like the data flow library for Ember,
and they switched it to Redux, actually.
So, it's also possible, but I very much prefer my decisions made for me, yeah.
Because I'm not sure...
Oh my gosh, no, no, no, I don't know...
No, but I'm not sure if this should be part of the debate,
but if you ask me which single-page application...
Or do you want to build a single-page application,
or which front-end framework should you choose,
then I always say, should we use a front-end framework, really?
Should you use one?
No, seriously, because I know probably 10% of the people here
are maybe more, I don't know, they're developing an app
completely on Rails, server, rendered HTML,
it works completely fine, you're driving the business value, it's going great.
And then, all of a sudden, there's this crazy developer,
your team, he wants to start using React,
and I'm like, dude, why?
Like, why?
And I had the same thing when we started using Ember.
And I was like, why?
Really, I know your UX will be a lot better.
There are a lot of pros,
but do all applications really need a single-page app?
If I can.
Yeah, of course, of course.
I have to do as much as possible, okay?
Okay, that's good, because I like the mic.
Let's work as much as possible.
I'm here thinking here and that's it.
That's a really good point, and I agree with you,
although I've been, for the last six years,
I've been doing single-web applications,
so I failed to resist the temptation.
Like, recently, when starting a new company,
designing the stack, one of the things I also asked myself
is about mobile development,
and I think that's something we probably could touch
about the frameworks here present.
So, basically, when you start a small company,
if you have to decide to hire developers,
if you want to go three platforms,
which is web, Android, and iOS,
it can be really, really expensive.
So, one of the decisions for me to choose React also
was, like, eventually, when we wanted to launch
the mobile application,
will I be able to use the people that have the skills
for building the web application
to do the mobile application?
And that was a really big selling point for me,
because having, usually, in my experience,
iOS and Java, like, Java Android developers,
they are not so willing to change.
So, for me, like, having a core of JavaScript,
which was a point about Meteor,
about having them on the front end and the back end.
So, for me, it's like, to have the JavaScript developers
ruling the front ends, it was really important.
So, I don't know, how does Ember,
and Angular deal with mobile, if they do?
This is a question I have, because,
okay, I know one of the pros of React,
actually, it's not real itself, it's React Native,
which is, we have to know that it's a different thing, okay?
This is the first thing we have to know at first.
React is not the same as React Native,
but they follow the same basis.
So, but it's completely native, okay?
Finally, it renders to native thing.
So, for Ember, I didn't know about it,
I know about Angular.
There's nothing on Ember like that?
I think, I heard, there's a guy in Kipu
that told me something about mobile,
I don't know, I think there's something in Ember, no?
Ember desktop?
Ember desktop, it's for desktop applications,
but it's written in Ember.
I've never really found,
or actually, I've never really looked for it,
but there might be something,
but not as popular as React Native,
and one of my points,
well, in the next 10 minutes,
was gonna be, I think, React,
if you have to choose one winner,
I think it's gonna be React.
No.
Because it's, one, it's super hyped right now,
it reminds me a bit of Rails,
maybe 10 years ago or something, but also...
That's another discussion of hype.
No, no, no.
It attracts people, hype attracts people.
There are a lot of good things about React,
and I think the strongest thing is React Native.
Amazing job by Facebook, what they did.
I've never used it in production,
I've doubled a bit in it in React Native,
but I don't know of any alternative in Ember, really.
I told you the LinkedIn mobile website was in Ember,
but obviously that's not an app,
so I don't know.
React Native has a pretty strong advantage there,
in my opinion.
So, again, you can ensure that it's embedded.
I mean, it's something like Anonic, right?