Having to worry about all these different screen sizes, devices, browsers and OS is a completely valid reason for not using a Windows 95 era form builder anymore.
No one is talking about using form builders instead of react. They are talking about using modern, competent application frameworks that power some of the most powerful applications in use today. Almost everything in the web stack is an adaptation of a native technology.
The basic metaphors are still the same because we're still using mouses on the desktop. With mobile devices these metaphors break down fairly quickly, though.
HTML-based applications however also introduced a number of new metaphors and patterns such as the page paradigm that, while originally reminiscent of printed pages, is different from anything both in the physical world and within native desktop applications.
Typography and information hierarchy are other aspects that usually can't be implemented as easily or as flexibly with native UI kits as with HTML-based approaches.
We are in the odd position where HTML + JS + UI framework (Vue/React) is just by far the best way to create good user interfaces. The performance hit is not going to stop anyone from using or developing software like this. There is NO good alternative.
For certain values of good user interfaces perhaps. There has got to be a better way forward for mobile UI. For desktop creating UI on something like QT designer or XAML on WPF is way more pleasant than HTML+JS+UI framework . Even Actionscript was less convoluted that this mess. I love writing React code but these abstractions are getting too elaborate. I had high hopes for WebComponents but support for those seems t…
Xaml and Wpf? Qt? I am honestly asking you, have you worked with React before? XAML has a learning curve of 2 years and more to get to expert level. I developed with it for more or less 5 years and i still have nightmares. Qt and the others are all imperative layout inflaters. React was a revolution, maybe the first cross platform paradigm that actually made sense. A learning curve that doesn't span more than a day. In all my years as a frontend developer i haven't seen a simpler way to create user interfaces. And sure as hell i would prefer React on the desktop or mobile over aged native toolkits that still struggle with obsolete oop-mvc-templating semantics, especially wpf and xaml, which in my opinion where the sole reason why i started hating my job.
Pardon my ignorance on the matter, and I’m truly sincere when I ask, but why does there need to be a *-native library for “each” different JavaScript framework? Why this instead of say Electron or something that seems, to me, to be more general purpose and thereby useful[1] (I’m not coupling my mobile apps to a single JavaScript framework). ... I suppose “React” is more of an API now-a-days, and so it may not be so b…
I'll try and boil it down to some points that hopefully build on each other: - In the mobile development there are a few approaches, including but not limited to: full-native, near-native, and webview (these aren't official terms, I just made them up) - "full-native" is using Java on Android, Swift/ObjC on iOS, generally implying using all the tooling/patterns/etc that come. This is the hardest in terms of learning c…
Good summary, one addition to the corrections others already made:
Android Instant Apps are not web apps. They are normal native apps, but limited in size (4MB), can be launched from a weblink and don’t get installed permanently on the device.
I honestly do not understand how did a large part of the software engineering community get to this point of idiocy. Is this due to the principle of getting to the market first and quick prototypes? I don’t see a quick way back.
Frankly I find your view pretty offputting. I’m not really that into the idea of JS-as-a-platform, but it obviously emerged because it fulfilled certain requirements that weren’t covered elsewhere. The “way back” from this is for people like yourself to stop dismissing others’ work as “idiocy” and start building better solutions to these problems as you see them.
>I’m not really that into the idea of JS-as-a-platform, but it obviously emerged because it fulfilled certain requirements that weren’t covered elsewhere.
Maybe they weren't covered for a reason?
The ability to have your web team churn out lowest common denominator bloated JS based mobile/desktop apps was not a real requirement, more like a wish of some.
It's based on react-vue[1] and It is internally using react-native. 1. https://github.com/SmallComfort/react-vue Why but Why.
Because, it solves a problem. I'm sorry, but, outside of the "let's use react for everything" bubble, people believe in different ideologies and use different frameworks to accomplish similar tasks. One of them is using Vue for web applications, and now thanks to this new project, the same Vue developers can also make use of Vue to build their mobile apps. What it uses under the hood isn't really a concern for me as…
>Because, it solves a problem
Some solutions are worse than the original problem.
Besides, not everything qualifies as a problem.
"I want to build a good mobile app" is a problem.
"I like to use Vue and want to use it specifically to quickly build an app no matter how slow / bloated the result will be" is not exactly a problem. More like a capricious wish that was granted...
It's like how "I want to eat" defines a problem, but "I want to eat McDonalds every day" is more like a bad judgement...
Here's my pitch for a better ecosystem: we develop an intermediate standard for fundamental UI building blocks (divs/blocks/layers, images, video, etc.) + a layout engine, sort of like the DOM. Shells (browsers, native platforms like React Native but without the React requirement, etc.) would give JS renderers access to the lowest level painting calls available (ie. "repaint this node") along with programmatic access…
> we develop an intermediate standard for fundamental UI building blocks (divs/blocks/layers, images, video, etc.) + a layout engine, sort of like the DOM
It's based on react-vue[1] and It is internally using react-native. 1. https://github.com/SmallComfort/react-vue Why but Why.
I honestly do not understand how did a large part of the software engineering community get to this point of idiocy. Is this due to the principle of getting to the market first and quick prototypes? I don’t see a quick way back.
It's all about developer productivity and nothing else. Well, maybe a healthy dose of cargo cutting. But anyway, no care is really given anymore about resource usage, etc because all of that is abundant.
I personally don't like it as I think it's wasteful and careless.
We are in the odd position where HTML + JS + UI framework (Vue/React) is just by far the best way to create good user interfaces. The performance hit is not going to stop anyone from using or developing software like this. There is NO good alternative.
For certain values of good user interfaces perhaps. There has got to be a better way forward for mobile UI. For desktop creating UI on something like QT designer or XAML on WPF is way more pleasant than HTML+JS+UI framework . Even Actionscript was less convoluted that this mess. I love writing React code but these abstractions are getting too elaborate. I had high hopes for WebComponents but support for those seems t…
Compared to vue, qt and all its reincarnations are a nightmare to work with.
For certain values of good user interfaces perhaps. There has got to be a better way forward for mobile UI. For desktop creating UI on something like QT designer or XAML on WPF is way more pleasant than HTML+JS+UI framework . Even Actionscript was less convoluted that this mess. I love writing React code but these abstractions are getting too elaborate. I had high hopes for WebComponents but support for those seems t…
Xaml and Wpf? Qt? I am honestly asking you, have you worked with React before? XAML has a learning curve of 2 years and more to get to expert level. I developed with it for more or less 5 years and i still have nightmares. Qt and the others are all imperative layout inflaters. React was a revolution, maybe the first cross platform paradigm that actually made sense. A learning curve that doesn't span more than a day.…
I love writing React code and it is easy to get up to speed there.
I abhor the mix of HTML/CSS for UI design. I'd rather code UIs in Actionscript.
The web browser as an abstraction for general use UIs is just not ideal.
XAML might be a company induced mess underneath but my point is that you don't have to be XAML expert to make nice interfaces. I made CRUD apps on WPF and rarely did I have to touch XAML directly. I had a big thick book on XAML and it sat unopened on my shelf.
I am forced to do front-end webdev work and I hate it. I need to worry about UI breaking instead of worrying about business logic.
Let's say client needs a dropdown menu added at a certain location. On desktop this is cake on most toolkits.
On web the problem is that there is no certain location, there is no absolute. You have to delve deep into CSS abyss to figure out how the component will behave.
Frankly I find your view pretty offputting. I’m not really that into the idea of JS-as-a-platform, but it obviously emerged because it fulfilled certain requirements that weren’t covered elsewhere. The “way back” from this is for people like yourself to stop dismissing others’ work as “idiocy” and start building better solutions to these problems as you see them.
Maybe "idiocy" is unnecessarily strong, but I certainly don't have to praise all emerging experiments just to sound polite, do I? The emerging of all these stacks is because of approachability. Everyone has a browser. Anyone who wants to create their first website can do so, by opening up e.g. notepad. By this approach you get low-quality, self-taught JS "experts" who are much cheaper to hire than a proper software e…
I used to agree with you. But over the last few years, in their own ways, Apple and Microsoft have dropped the ball on their native desktop UI toolkits. So, whereas the argument for native used to be "rewrite your client once per platform, and you get a better language, better performance, better usability, and a better development experience", now it's "rewrite your client once per platform and you may get a better language, depending on your taste, probably better performance, an aging closed-source toolchain, an outdated development paradigm, outdated APIs covered in legacy-barnacles, debugging-resistant performance pitfalls, and decent usability if you're ok with a generic one-size-fits-all look (and you're on your own if you're not.)" In other words, the argument for native, and native development itself, is not aging well.