Hacker News new | ask | show | jobs
by kschiffer 3558 days ago
I believe in the end it all boils down to the fact that JavaScript is a language that wasn't made for the needs of modern day (web) applications, but since it is still a standard, we need to force it into a form where we can have best control over its shortcomings. That's why things like Typescript, Flow and React exist in the first place. I know this article is about mobile app development, but I think JavaScript would not have the sort of widespread use today if it wasn't for the fact that we use it for website scripting.

So I guess that developers familiarity with the language is what makes it so popular (as in often-used) and is also why we suddenly start using it for arbitrary scripting and mobile app development. The obligatory use of JavaScript in web development led to a whole range of developers growing accustomed to it and now, in spite of its limitations, trying to transfer their ideas to other fields of development.

React Native is just a neat way for JavaScript (React) developers to be able to script UIs for mobile OS's without changing their toolset. And I think for that it's perfectly fine. Obviously if you've never been big into JavaScript I can totally see how cannot make much sense of it all and yeah a lot of the things pointed out are perfectly legitimate. Yet I still think the question whether it makes the language unusable for one scenario or the other is very very opinionated.

3 comments

Besides, while JS's problems are very real, they're quite exaggerated. It's still a perfectly usable language, even without TS and whatnot.

And unlike some languages used for app programming, an error doesn't have the potential to hand you a segfault.

> ...an error doesn't have the potential to hand you a segfault.

And that is a good thing why? So you don't realise there was an error and your app runs on in a corrupted state?

For starters, a huge set of security vulnerabilities are not possible. Ex: buffer overflow, double free, reading uninitialized memory.
Precisely. Don't write Application code in a systems language.
If you segfault, that's not because your state is corrupt. Not usually, anyways. Typically, you'll segfault from a use-after-free error or similar.
How else would you define corrupted state than “losing track of the objects in your app”? Not crashing as a consequence hardly makes it better.
It's worth noting, that given the early days of the web... It's just as likely we could have perl in the browsers, and I'm certain people would bemoan that as much or more.
What are the needs of modern day applications? How does (what it was designed for) differ from (what is desired of it)?