I understand why you feel this way. I really do. But if there's one thing I've learned, it's that using the best tool for the job pays off.
Platforms were built with certain languages, frameworks, and architectures in mind. And while you can build things with any number of transpiled or hybrid tools these days, you're going to have a better experience reading the vendor's documentation and writing with the libraries and languages that they build the platform with. This ultimately means the user is going to get an experience that is consistent, performant, and feels at home on their device and you're going to have a codebase that is maintainable by yourself and others into the future unlike fragile approaches to building with unsupported environments.
And "best tool for the job" isn't just a client thing. You can write a server with anything, in any number of languages, picking the frameworks around that language for the task at hand. Ask yourself: are you building a large server monolith or a small microservice? Do you need low level access to things for performance, or you just serving up some files? A language + framework that's the best tool for that job will show itself once you start talking it out. A Golang microservice would be very different than a Rails instance, for example. Would either work? Of course, but why not pick what makes the most sense instead of just picking the language that you're most familiar with?
What if somebody else joins the project and has to figure out your weird Python -> Javascript transpiler? Does anybody even want to work on that? When you go interview for a job and they say "So it says here you've been doing Android development" and you say "Yeah, but in Pearl and HTML5", they'll probably give you a pretty weird look. There's vibrant communities of whatever environment you can think of, and it's fun to be a part of those communities. You're opting out if you aren't building upon a common ground. Ask the RubyMotion people when they show up to WWDC.
And take it from me, if you're paving your own road and building with alternative tools, you'll be reinventing the wheel... a LOT. You won't be saving time, you'll be wasting it figuring out things that would be simple otherwise.
I've written about my thoughts on cross-platform development in clients on my blog, and explained why I feel the tech stack matters when building things. Feel free to give it a read: gabekangas.com/blog/2018/2/why-you...
Plus learning new things is a hell of a lot of fun and makes you a better developer, and maybe even a better person. Once you realize you're not restricted to the single language you're most comfortable with you realize there's nothing that you can't do. And that's pretty cool.
Thanks for your thoughts. As someone who's used at least a dozen languages, I know it's fun to learn new things.
I agree that what I'm talking about is not possible in all situations. It's more like (the beginnings of) a mission statement. It's intended to say that we should value certain things, even if they currently are not valued by the status quo. If people want what I'm talking about, they'll demand it from the developers of the software and platforms they use. If nobody wants it, then things will stay as they are.
While platforms often prefer certain languages, that's a choice that platform authors make, which they could have chosen otherwise. In your blog post, it was Apple who chose to exclude React and Xamarin developers, not something inherent to what iOS is. Netscape chose not to make a language-agnostic scripting environment the norm for the web.
Wheels often have to be reinvented when there's a new way of doing things. That's not necessarily a reason not to try.
Regarding hiring: React Native and Transcrypt are possible solutions when you already have front-end developers or Python developers respectively. React and Python are both already popular tools. In the case of React Native, I doubt hiring would be an issue. In the case of Transcrypt, I want to work on it, for one, and would be overjoyed if someone paid me to do that. I know lots of other people who like Python at least, and I bet some of them would work with Transcrypt if there were money involved.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I understand why you feel this way. I really do. But if there's one thing I've learned, it's that using the best tool for the job pays off.
Platforms were built with certain languages, frameworks, and architectures in mind. And while you can build things with any number of transpiled or hybrid tools these days, you're going to have a better experience reading the vendor's documentation and writing with the libraries and languages that they build the platform with. This ultimately means the user is going to get an experience that is consistent, performant, and feels at home on their device and you're going to have a codebase that is maintainable by yourself and others into the future unlike fragile approaches to building with unsupported environments.
And "best tool for the job" isn't just a client thing. You can write a server with anything, in any number of languages, picking the frameworks around that language for the task at hand. Ask yourself: are you building a large server monolith or a small microservice? Do you need low level access to things for performance, or you just serving up some files? A language + framework that's the best tool for that job will show itself once you start talking it out. A Golang microservice would be very different than a Rails instance, for example. Would either work? Of course, but why not pick what makes the most sense instead of just picking the language that you're most familiar with?
What if somebody else joins the project and has to figure out your weird Python -> Javascript transpiler? Does anybody even want to work on that? When you go interview for a job and they say "So it says here you've been doing Android development" and you say "Yeah, but in Pearl and HTML5", they'll probably give you a pretty weird look. There's vibrant communities of whatever environment you can think of, and it's fun to be a part of those communities. You're opting out if you aren't building upon a common ground. Ask the RubyMotion people when they show up to WWDC.
And take it from me, if you're paving your own road and building with alternative tools, you'll be reinventing the wheel... a LOT. You won't be saving time, you'll be wasting it figuring out things that would be simple otherwise.
I've written about my thoughts on cross-platform development in clients on my blog, and explained why I feel the tech stack matters when building things. Feel free to give it a read: gabekangas.com/blog/2018/2/why-you...
Plus learning new things is a hell of a lot of fun and makes you a better developer, and maybe even a better person. Once you realize you're not restricted to the single language you're most comfortable with you realize there's nothing that you can't do. And that's pretty cool.
Thanks for your thoughts. As someone who's used at least a dozen languages, I know it's fun to learn new things.
I agree that what I'm talking about is not possible in all situations. It's more like (the beginnings of) a mission statement. It's intended to say that we should value certain things, even if they currently are not valued by the status quo. If people want what I'm talking about, they'll demand it from the developers of the software and platforms they use. If nobody wants it, then things will stay as they are.
While platforms often prefer certain languages, that's a choice that platform authors make, which they could have chosen otherwise. In your blog post, it was Apple who chose to exclude React and Xamarin developers, not something inherent to what iOS is. Netscape chose not to make a language-agnostic scripting environment the norm for the web.
Wheels often have to be reinvented when there's a new way of doing things. That's not necessarily a reason not to try.
Regarding hiring: React Native and Transcrypt are possible solutions when you already have front-end developers or Python developers respectively. React and Python are both already popular tools. In the case of React Native, I doubt hiring would be an issue. In the case of Transcrypt, I want to work on it, for one, and would be overjoyed if someone paid me to do that. I know lots of other people who like Python at least, and I bet some of them would work with Transcrypt if there were money involved.