Here are few resources I can think of off the top of my head.

For Responsive Design:

• CSS Media Queries
• Bootstrap
• Style Elements for Elm.

For developing native apps using web technology:

• React Native
• Turbolinks

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.

There's a critical flaw in trying to erase boundaries here. The differences between mobile, tablet, desktop, etc. are not about screen size - that matters, but people resize a browser window, too. Make your stuff so it'll show on as wide a span of sizes as possible, and you'e golden.

No, it's mainly about input methods. Touch screen input is and will remain very distinct from mouse input, and a physical keyboard is a far different affair than a software keyboard on a touch screen. Touch screen input means no hovering, no cursor hinting, and far less precision in put, meaning far larger inputs are required - which will irritate a mouse user! No hardware keyboard means no key short cuts, no tab completion, none of the features we routinely use keys for - but software keyboards usually have predictive text, with varying accuracy, and built-in emoji capability, both of which their uses will expect to be able to use.

Then there's browsers and OS'es response to custom input types - looking at HTML inputs, the 'date' and 'time' inputs come to mind a great deal here. On Android, for instance, tapping an input field of type 'time' gives you a fancy clockface style dialog where you select a time. On a desktop Chrome, however, you just have an up and a down button to increment or decrement time. Meanwhile, 'date' inputs show, respectively, a nice calendar picker, and an ugly box that looked like it fell out of a 1990's accounting system. Consistency is, apparently, for chumps? But that's our problem now, as the developers.

From a UX perspective, there are huge differences between touchscreen devices and desktop devices. And I thank my lucky stars that the Windows 8 era hybrid devices haven't taken off more than they have, TBH.

Actually the real barrier is UX, not language. You have to design for each platform so that the app provides same user friendliness in all platforms. So platform here is mobile, VR, desktop, laptop...etc; not iOS, Android, Windows. This is exactly why new Windows start screen failed. There is no shared experience between a tablet and desktop. What is shared are just the information and actions (ex: my email content and an action that shows me the inbox).

Since this mostly means re-writing at least the experience of the app from scratch, it can be better to do it using platform tools. You can still use a common engine for the logic, which is especially easier if your app depends mostly on a back-end. For example in my opinion it is better to design a webpage separately for mobile and desktop than use a responsive design. It is not just touch vs mouse, your website should be able-to-be-used-while-walking, or while in toilet..etc

At this point I feel pretty sympathetic to Flutter where you design for mobile but not for iOS or Android, while still using their native interfaces. It is not surprising such a new language emerges while we start discussing similar topics. Also as a game developer I like how cross platgorm game engines work where experience matters more than the platform. I think every front-end developer and UX designer should do some games to get an idea of some hardcore experience designing.