Live data from Hacker News

Vue Native

vue-native.io

71–80 of 208 posts

Re: Vue Native

#71

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…

Web Components?

No, because web components assume you're using the DOM. Which we definitely do not want. I want to go lower level. Give me a hashmap of nodes currently on screen. Let me design how the nodes are arranged in a render tree. Let me design how the nodes are redrawn. Let me design how the nodes are styled. I shouldn't have to compile my styles to CSS. Make the browser a rendering slave with a small but effective layout engine + UI API.

Re: Vue Native

#72

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…

> The existence of React Native is a huge difference-maker for react. If you want to sell your team on react, the ability for a frontend developer to easily handle mobile application development is a strong selling point.

The reality is that while it may ease the transition a bit, your front-end developer will be having to dip into Swift/Obj-C often enough that eventually the supposed benefits here are moot.

Personally I think it's worth just taking the hit and learning the framework. A good book will have you productive within a week. The learning curve these days is easier with Swift and now that front-end developers are used to things like React, Flex Box, and so on, the concepts behind making iOS apps are not as different and alien as they once were.

Re: Vue Native

#73
post #67

This is the only missing piece that has held me back from jumping into Vue. I know its not the most advantageous aspect of the framework, but my personal favorite aspect of it is the single file components. Being able to create a complete logical unit of UI of in one file feels more natural and produtive. All the speed of inline styles without the guilt and shame.

FWIW, the next version of Ionic (in beta) decouples from Angular, so that people can use the tools and platform support of Ionic to build mobile apps with Vue, or whatever they prefer.

Thank god. Angular is just way too big now. There's way too many files and they try to push you into using typescript.

Re: Vue Native

#74
post #19

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 think it basically boils down to the prominence of what I call Universal User Experience, which is basically an attempt to give users a similar experience across different device and form factors. I believe this UUX is the powerhouse behind this second(?) weave of Write Once Run Anywhere and why we have so many libraries with web/html and iOS, Android, and various desktop frontends.

I've been down this road: it did not end well. Facebook also went down this road and seems to have realized something similar (and hence why they pulled back on HTML5 on mobile and have not attempted to make React Native fully cross platform).

The reason why is essentially every platform (iOS/Android/web) has its own characteristics, charms, quirks, habits, and behaviors. Trying to smush these all into one unified UX experience is producing something that feels and acts weird on every platform, and people notice. Trying to unify is a solution for a developer problem, not a solution for a user problem -- and thus it's not really a problem.

What this comes down to is focus. Developing across multiple platforms is a hard problem and requires a lot of work. It's really only suitable for larger teams. As a small team, it is better to focus on one platform, do really well, and then later when you can afford it, go to other platforms.

Re: Vue Native

#75

It's based on react-vue[1] and It is internally using react-native. 1. https://github.com/SmallComfort/react-vue Why but Why.

> Introduce react-vue-loader, which compiles the Vue component into a React component. As you might think, your previously written Vue components can run inside the React component, and your React components can also run inside the Vue component

How did it come to this?

Re: Vue Native

#76
post #70

Earlier quoted context omitted.

Christ, Electron would be truly terrible for mobile apps. All the excuses people have for its bloat ("we all have tons of RAM anyway!", "storage space is cheap!", etc) evaporate when you're running on an ARM processor with maybe 2GB of RAM and 32 to 64GB of onboard storage.

Electron for mobile is called Cordova and has been around for a long time.

Capacitor is the new Cordova. Check it out.

Re: Vue Native

#77
post #29

Earlier quoted context omitted.

It's normally in an attempt to "build once deploy everywhere" using tools first built as web technologies. The same selling point as the JVM for Java. In some ways Electron serves as a bit of a JVM for web, but then, that is also the utility of a browser. You can see it as an artifact of the web technology coming first and trying to port it backward to other devices. I wish we had ported some of the awesome GUI libra…

What is it about native ui technology that you think is better than web tech? In my experience, the singular advantage of native tech is performance. Am I missing something?

I would say taking 1/10th or 1/100th of resource is a pretty damn big advantage even if that's just one advantage. Modern browsers are probably the most inefficient mainstream computer technology ever regardless of how useful it might have been.

Re: Vue Native

#78
App stores should be abandoned, web app is the only thing you can 100% control.

If you can't publish critical update for your app in minutes, just because you use phone vendor's store, then that store is a huge priblem.

If store can just uninstall your app in any moment (without user's request) - it is a huge problem.

Re: Vue Native

#79

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.

Re: Vue Native

#80

Earlier quoted context omitted.

Web Components?

No, because web components assume you're using the DOM. Which we definitely do not want. I want to go lower level. Give me a hashmap of nodes currently on screen. Let me design how the nodes are arranged in a render tree. Let me design how the nodes are redrawn. Let me design how the nodes are styled. I shouldn't have to compile my styles to CSS. Make the browser a rendering slave with a small but effective layout en…

What about accessibility? Accessibility helpers would need semantic information about the UI to be of any use. And I doubt that many homegrown or halfbaked Ui libraries (which would certainly sprout like mushrooms on a platform like yours) would provide correct annotations through an accessibility API. Most developers wouldn't care.
Post reply on HN