It's based on react-vue[1] and It is internally using react-native.
1. https://github.com/SmallComfort/react-vue
Why but Why.
1. https://github.com/SmallComfort/react-vue
Why but Why.
How did it come to this?
1) many people prefer Vue over React - you can google them and their reasons.
2) one of the great selling points in the React ecosystem is React-Native - you can write many parts of your code once and use both for web and native applications.
There are other solutions for this for Vue (Weex and NativeScript) but React Native has the mindshare. Perhaps there are other benefits - I don't work with apps so I don't have experience.
The layers of abstraction keep adding up.
Tortoises all the way down.
Next thing someone will incorporate jslinux into this mess
What it uses under the hood isn't really a concern for me as a Vue developer as long as I'm able to develop mobile apps with it.
> Why but Why.
Sorry, but this comment seems arrogant. As though just because it's out there on React, others aren't entitled to opine differently or use different frameworks?
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...
Wow, that's a pretty harsh claim. This was just released and you already think it's worse with no sort of data to back up your claims. Sorry, that's not a sound argument.
I haven't evaluated this, but having suffered many (similar in concept) React Native and Electron based apps as a user, I speak of my general experience with those bloated / uncanny valley monstrosities...
And the damage is done. This[0] comment by 'm_fayer elsewhere in the thread is quite chilling. Actual native toolkits are rotting, as big companies join the web-for-everything bandwagon. Not only delivering bloated applications with toy-like UIs becomes the norm, we're losing the ability to deliver fast, useful UIs!
--
What's worse is that actual native toolkits are rotting, while at the same time we never managed to produce a single, great native cross platform toolkit -- even less so a great cross platform one.
Not because it's impossible, but because no major player cares (they have their own platforms), and OSS attempts like Wx and GTK+ don't have the manpower.
Why can't the web+JS be that platform?
But even if we ask the more general question, why "web+js can't be the great cross platform toolkit", the answer IMHO is:
Web+JS are and will always be (due to the nature of the platform) inherently slower than optimal (even if "fast enough" for simple apps), use more memory, use more CPU, don't use the native facilities and so are foreign to every OS look and feel (from themes to usability features), and so on. And of course they're "bring your own theme" affairs, so no standard users can get used to, everybody does their own BS UI in SPAs and web-engine based apps (like Spotify and Atom).
Add the amateur hour development practices that they enable (where a company that would previously hire actual GUI programmers can now hire some web devs and let them loose to create its app) and the picture is not nice...
Is this due to the principle of getting to the market first and quick prototypes? I don’t see a quick way back.
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.
It's hard to think of it as an improvement
The idiocy is in the hundreds of engineering hours spent to build half baked solutions that never work as expected and never will
It's developers not wanting to adapt, while if they spent half of that effort on red or even visual basic 6 we would have end up with something better
Diversity is king, web everywhere for everything will impoverish the entire developer's community
There is a better solution. It's called native app development, without a hyphen of any sorts in front of "native". Different platforms have different quirks and there is no way to have the exact same UI/UX on all platforms.
The true challenge is to explain the executives, that hiring 2 developers will be much better in the long run, than 1 underpaid JS developer for all platforms.
Speaking from personal experience, I have found it vastly more productive to focus on the good than the bad. Yes, even in situations where the other person is literally [1] too dumb to put their underwear on correctly without assistance.
I don’t know how or why it works to do that, but it does, and the improvement from doing so is immense.
[1] Alzheimer’s.
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.
Now businesses do that just because they can.
- we haven't figured out how to make companies care about "delivering value" part of the "delivering value in exchange for money" work, and
- we allow them to dump externalities on users without consequences or compensation.
So the most cost-effective solution in this scheme will be a half-assed product that's barely good enough to be sellable, and which makes my computer use more electricity while being less capable of running software simultaneously.
I don't feel like this is a valid justification for being wasteful, though.
(Personally, I didn't even realize OnePlus phones still exist - I thought they died out somewhere around OnePlus 3.)
I do think though that we will only be seeing more and more of this, and very soon.
Cheapest to produce AND worst quality. In this case by bad performance and unneeded cellphone battery drain.
These products will be dominated by superior options eventually.
Would love that to happen, but all the other market sectors suggest otherwise. "Cheapest to produce and worst quality" seems to be all that's available to majority of the population.
Come on, the requirement has always been there. It is "Shit out that underbudgeted project in half the promised time". Those small frameworks where you can hire a cheap front-end guy and have him manage the entire project alone or in a small team are perfect to fill that niche.
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 to be stagnating.
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.
- how is it supposed to adapt to different resolutions?
- is an inner absolute component allowed to escape its container?
- how does it layer with other components?
The CSS required to position an element at an absolute location must take all of these into consideration, and I'm not sure how much better a native toolkit can make it.
It could be better, but it's even got a proper grid system now, close to wpf's. From what i remember though, wpf's styles also had some rough spots.
A good user interface will, among other things, be consistent with its environment, efficient wrt. to its purpose and performant.
Consistency with the environments using similar interface primitives to other applications at all levels - not just looking like other applications (to facilitate knowledge transfer/principle of least surprise), but also supporting universal idiosyncrasies - like the context menus in text field, copy-paste, integration with system-wide settings, etc. Looking the same is anathema to web designers, and reconstructing anything else than basic functionality of an UI component is something webdevs usually can't be bothered with.
UIs that are efficient for purpose happen on the web, as long as people do not follow popular UI/UX guidelines. Efficiency for purpose usually means denser interfaces, less bells and whistles, more data on screen, more features and functionality, and a bit of learning curve - all of these are actively hated in the current web ecosystem. All the efficient interfaces I see on the web these days are of those products that didn't get the "web 2.0" memo and are stuck in early 2000s.
Performance. They say V8 is heavily optimized and all, but for some reason the modern web is still fucking slow. Might have something to do with ads and tracking, but it also might have something to do with trying to be first-to-market, and putting in lots of pretty looking bells and whistles. The end result is that I say the data table might need to display 10 000 rows, and I see the UI team cringe at the thought of slowdown. Well, why on Earth would 10k rows in a 4-column table be a problem? Oh, you used lots of JS magic to make that table pretty and "reactive" and shits, that's why.
--
TL;DR: The web is the opposite of good UIs. I'm not really sure if the problem is technological - it seems to be almost entirely cultural.
- It's easily discoverable by the user - The web is typically horrible at this. Custom controls, look and feel's, and a severe lack of common UI patterns. Native app's have this in spades.
- It's performant - Native wins this hands down everytime. The web stack lacks threading and one of the major keys is to NOT do work on the main thread for a great UI. The vast majority of web dev's have never even thought about threading.
- The design puts features in a place the user can easily and quick get to. This has little to do with the technology platform.
Bottom line is the web stack is at a MAJOR disadvantage for building a UI. The only use for it on mobile is that developers refuse to put in the work to learn how to do the platform justice.
Getting crap done counts for a lot. Web, and hci in general, isnt figured out well at all, so we can spend a few decades pursuing an ideal we don't even have defined...or we can get stuff done.
If you are arguing for some specific non-"idiocy", please, explain why your version hasn't taken off.
Do you have a link about this latest rehash? I tried googling without success
Yeah you end up with crap.
I personally don't like it as I think it's wasteful and careless.
They're abundant for people who you only think about themselves. Who believe that their application will be the only one running on the machine. Which may be the case if you're developing software for touchscreens on a factory floor, but is definitely not true for end-user software, and doubly not true for anything on the web.
Semi-seriuos: I am afraid many honestly believe that JS is the best language and has the best ecosystem.
I consider myself lucky having learnt programming back when you had no choice but to use different tools/languages for different tasks. It provides with a luxury of being able to compare different approaches.