Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue Native

vue-native.io

Post reply on HN
Print view View original

101–110 of 208 posts

Re: Vue Native

#101

Post by danpalmer »

lwansbrough wrote: post #66

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…

While I admire your hopefulness that this could solve the problems, I don’t think it will for two reasons.

1. This is what the DOM is, to some extent. All those components on the page are “native” components, we have declarative markup for them (HTML) and we can script them. They are “rendered” by native code in browsers which are some of the most highly optimised codebases around.

2. The API design for JS and for higher performance systems is quite different. Take UITableViewDataSource for example, it does view prefetching, caching, object reuse, etc. As of iOS 12, this also feeds into the CPU throttling control to ensure enough compute is available on a cell fetch that it will meet the 8-16ms deadline so that no frames are dropped. This is just a totally different way of thinking about APIs and performance that the JS ecosystem is not designed to work with.

It’s possible that a total rewrite of that stack could provide significant benefits, but I think that would be more from removing legacy cruft in the DOM, than from it being a paradigm shift.

Re: Vue Native

#102

Post by ehnto »

BjoernKW wrote: post #62
mirkules wrote: post #49

Earlier quoted context omitted.

And yet not a single valid reason is given. "Because it's the old way of doing things" is completely inadequate as a technical reason to not use a technology.

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.

Re: Vue Native

#103

Post by sireat »

re-actor wrote: post #97
securityfreak wrote: post #79

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.

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 to be stagnating.

Re: Vue Native

#105

Post by ergothus »

securityfreak wrote: post #79
codesternews wrote: post #58

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.

I find it entertaining that you post this a within 24 hours of the linus/tanenbaum rehash.

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.

Re: Vue Native

#106

Post by lwansbrough »

danpalmer wrote: post #101
lwansbrough wrote: post #66

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…

While I admire your hopefulness that this could solve the problems, I don’t think it will for two reasons. 1. This is what the DOM is, to some extent. All those components on the page are “native” components, we have declarative markup for them (HTML) and we can script them. They are “rendered” by native code in browsers which are some of the most highly optimised codebases around. 2. The API design for JS and for hi…

Your UITableViewDataSource is a common problem with big JS applications, and has been solved to some extent with the same optimizations you've mentioned. However because JS and HTML is what it is, it has to be solved on a per-library basis (React Virtualized List, Vue Virtualized List, etc.) The problem remains that the JS renderer does not have access to those low level draw calls to optimize performance further.

As for the DOM, again I think that while it's true that native HTML elements are highly optimized, many applications have much larger performance goals in mind and HTML/DOM has proven to be an ineffective system when trying to do very specific performance optimizations. Check out flipboard.com on your phone for an example of how much smoother a web app can feel when you bypass the DOM and let React take over the draw calls.

Re: Vue Native

#108

Post by securityfreak »

matthewmacleod wrote: post #85
securityfreak wrote: post #79

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.

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 engineer with fundamentals of computer science. After a few years these developers feel so confident, they decide to launch their own perfect new framework/library to solve all the problems they experienced!

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.

Re: Vue Native

#109

Post by neya »

esfandia wrote: post #64
neya wrote: post #33

Earlier quoted context omitted.

This page is a good start, it discusses the differences in detail: https://vuejs.org/v2/guide/comparison.html My personal experience wasn't that positive with React and then, the whole treatment of JSX as a first class citizen isn't really my style (although you're allowed to use React without involving JSX). Vue just feels more mature (personal opinion) and much, much easier to reason your code about, down the line…

Is your course online? If so, do you mind sharing a link?

Oh, actually, it's offline, but I plan to put them all in one place online on Medium. I've already started writing a piece about writing an E-Commerce engine:

https://medium.com/build-ideas/my-journey-of-writing-an-e-co...

Re: Vue Native

#110

Post by neya »

spicyj wrote: post #47
neya wrote: post #33

Earlier quoted context omitted.

This page is a good start, it discusses the differences in detail: https://vuejs.org/v2/guide/comparison.html My personal experience wasn't that positive with React and then, the whole treatment of JSX as a first class citizen isn't really my style (although you're allowed to use React without involving JSX). Vue just feels more mature (personal opinion) and much, much easier to reason your code about, down the line…

> I re-wrote my entire teaching syllabus for my programming course to use Vue instead of React, simply because it's much better to maintain Vue apps rather than React apps after 6 months, which is the most important value add for me in any framework. Why do you find it harder to maintain React apps after 6 months?

One of the main reasons - JSX. Contrary to popular belief, JSX is all cool until you're in a situation where you need to maintain the app you wrote.

I know React can be written without JSX as well, but frustratingly most documents/resources online are all examples with JSX.

And then, this:

https://twitter.com/thomasfuchs/status/810885087214637057

Post reply on HN