Live data from Hacker News

Vue Native

vue-native.io

141–150 of 208 posts

Re: Vue Native

#141
post #126

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…

It's funny because Netflix's Gibbon and YouTube's Cobalt already use some of those ideas. At least the latter is open source. Flutter is built with the same thinking. There will be some kind of convergence in the coming years.

What are Gibbon and Cobalt? I tried google but with no success. Do you have any link?

Re: Vue Native

#143

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.

Non-serious: maybe they have to spend so much time chasing the latest trends in JS frameworks that none is left to learn about alternatives.

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.

Re: Vue Native

#144
post #113

Earlier quoted context omitted.

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 p…

> Some solutions are worse than the original problem.

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.

Re: Vue Native

#145

Earlier quoted context omitted.

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.

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.

I'm sorry, but the way the web stack is typically is the opposite of good user interfaces. It's not that the web can't be used to create good UIs, it's just I've never seen it used in this way, and I find that the less of web technologies you use, the better.

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.

Re: Vue Native

#146

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…

The problem is: the platform owners (Apple and Google) have absolutely no incentive to make this see the day of light. They make money selling apps, and want to bind developers to their platform.

Re: Vue Native

#147
post #144

Earlier quoted context omitted.

> 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 p…

> Some solutions are worse than the original problem. 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.

Notice how I said "some", and not "this particular solution".

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...

Re: Vue Native

#148

Earlier quoted context omitted.

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…

it will get worse before it gets worser

Re: Vue Native

#149

Earlier quoted context omitted.

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. Now businesses do that just because they can.

They do it simply because it's the most cost effective solution overall.
Post reply on HN