Expo comes with pre-installed native bindings. If you want to add native bindings to your expo app you need to eject. This means it does not use any native bindings not included in the Expo SDK.

Note that it already mostly works right now with v8.

I believe lumberyard also offers direct integration with AWS.

It looks really verbose only to render simple html.

I had one really bad experience with Scala.js. When I used it, I noticed Scala was just not designed for the web (front end) and it just didn't work well for things really simple in JS.

I'm going to go against the HN current opinion but I hate Scala. I worked for a few months on some Scala projects, the language is way too complex (the opposite of Go, they add whatever feature they think is cool) is poorly documented and readability is difficult as well. It looks like a mix of Perl and functional languages.

I hate it as well. I think it's a poorly designed language. The syntax is a mess (underscore...), the operator overloading make people overload silly operators which make code unreadable from an outside programmer. I could go on...

I prefer Kotlin which imho fix almost every bad design decisions from Scala.

If underscores and operator overloading are the biggest criticisms you have of Scala, then we're doing pretty well. For what it's worth, I think Scala has quite a large grammar that means it takes a while to learn, but once that's over it's not particularly difficult to read or to write.

Can you elaborate as to what Kotlin fixes compared to Scala?

Scala.js is not really designed for simple websites.

It's designed for bigger ones especially in which you want to share models and validations between front and back end.

Could you cite an example of how Scala is unsuitable for the web? Between Scala and JavaScript, I would pick Scala in a heartbeat for one reason alone - it's strongly typed. Both of them offer OO & FP.

Strongly typed was one of the problem I found. TypeScript offers a better alternative to typing on the web because it keeps the compatibility with javascript and also have a real any type when it's really necessary. Typescript now can import raw js without types definitions unlike Scala.

I believe Scala can use javascript libraries either dynamically or with type definitions in exactly the same way as TypeScript?

I tried to use TypeScript but the type system just wasn't good enough; when you've been working in a strongly-typed language like Scala for a while, a language without nominal types or HKT just isn't going to cut it.

Could you illustrate, preferably with an example, how weak type system would have worked better than a strongly typed system?

Maybe you don't want a good looking UI, but it's safe to say that at least 90% of users want a good looking UI.

Good looking UI is a major part of user experience.

I want a good looking UI, I just find that electron doesn't deliver this. A good looking UI is one that blends in with the rest of the system, electron apps look like their being run in an emulator from another OS.

Not saying I don't believe you, but do you have a source for that 90% claim?

It's a "random" guess. But in my experience, for a website, if it doesn't look good at first sight, a user might just leave instantly. As someone pointed out in the comments, just looking at sites like:

https://riverbankcomputing.com/software/pyqt/intro https://electronjs.org/

Your eye will probably be more attracted by the good design of the electron website.

I'm not saying an app should be only good looking, but it's clearly a major part.

I'm sure that's part of it, but the primary usability studies I'm aware of have all focused on speed/response. Whether this translates to "native" apps or not, I'm not sure, but certainly for the web, response times are king [1]. Curiously, this metric has been a stable predictor of retention for decades (see the sources in the link as it'd be redundant for me to post them here).

[1] http://ixd.prattsi.org/2015/04/response-time-is-speed-the-ul...

The history of fashion and marketing tell us that appearance matters.

It drives engineers batty, because it's often irrational.

Just because something is irrational doesn't mean it doesn't have a huge impact on something like adoption.

If we didn't care how things looked, we might all be wearing google glass.

To be annoying, and not to disagree with your comment in any real way at all, I’d argue it’s the engineers who are being irrational for choosing to ignore or not make the effort to understand human nature. I’m sure there are plenty of studies in psychology, social psychology, or anthropology explaining the rational basis behind why fashion/marketing has such a strong impact on human behavior. I’d also bet that the advertising industry is well aware of these studies ;).

There is no reason why. Thise study explain “how”. Only reason that marketing/fashion have an impact on human is nature. “How” is what they studied

I think Google pays Mozilla to have Google as default. https://techcrunch.com/2017/11/14/mozilla-terminates-its-dea...

They actually reverted aot by default on serve because for really large project it might slow down the reload time.

You can still use --no-aot (or something similar) in the meantime

They do actually use every number of semver in a meaninful way.

It isn't. A fresh 'ng serve --open' takes ~20 seconds to get to a ready page, and each reload is taking 10+ average. Every minor change.

I can personally stand it because I remember working on 2 million line C++ projects in the 90's. The millennials on my team, on the other hand, are going insane. I've recommend they disable live-reloading completely.