191–200 of 208 posts
I prefer NativeScript[0] & it's vue-specific extension NativesScript Vue[1] due to NativeScript's ability to work with more than one paradigm/framework. NativeScript enables any Javascript application to become a mobile app (along with ones built in Angular and Vue) and I think that's pretty great. [0]: https://www.nativescript.org/ [1]: https://nativescript-vue.org/
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.
I prefer NativeScript[0] & it's vue-specific extension NativesScript Vue[1] due to NativeScript's ability to work with more than one paradigm/framework. NativeScript enables any Javascript application to become a mobile app (along with ones built in Angular and Vue) and I think that's pretty great. [0]: https://www.nativescript.org/ [1]: https://nativescript-vue.org/
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.
Yes! :) I've been using VueJS for awhile and my next step was to create a mobile app - either via RN or even Flutter. But, hello vue-native!
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…
For one, there's a lot to be learned from immediate-mode UIs (I'm thinking Dear IMGUI, not Unity3D's GUI); ie state inside components generates complexity, which is a bad thing. Your views should be nothing more than a pure FSM transforming app state to UI directives. IMGUIs have a ton of tricks to simplify UI development. With these in mind, FP becomes a much more interesting paradigm than OOP for this. The same logic applies whether you render the entire UI 60 times a second or you cache the previous render to only do the minimum amount of updates.
A good abstraction is one where features can emerge from its design. For example you rarely have to test your views when they're just a simple pure transform. You don't need an entire framework and command-patterns to implement undo when your app state is immutable and modelled as a sequence of actions. With each emergent feature you remove the need for tons of code and tooling; that yields agility.
I still believe most web application are much more complex than they should be, especially on the UI level, regardless of the framework used. And until we solve that problem, I don't think the web stack is the way to go for native. We're just replacing one set of problems for another one.
I strongly believe we shouldn't make things easier, but simpler.
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…
A hashmap of nodes on screen is still very high level; you're basically replacing the DOM with data, yet keeping the exact same structure. But now you lose static types and everything is slower.
Redrawing doesn't happen at the node level either; that would be terribly inefficient. Things are instead batched together.
You don't have to compile your styles to CSS currently; just write them as JS objects and call the CSS constructors yourself from code. You'll quickly find its not productive for most styling.
I simply don't believe the vast majority of developers to be able to properly handle rendering at that level. No offence but all your points about low-level rendering is not how it actually works. Its incredibly easy to fool yourself into thinking you wrote a well-designed, efficient piece of code and learn years later every single piece of it was far from optimal.
Thats why we have layers of abstractions.
Considering there is already Weex and NativeScript with Vue, what does this add? Personally I think Flutter will become the dominant cross platform solution in 2020 or so. ReactNative has always seemed like a hack to me.
What about it seems like a hack? Why do you think Flutter will become dominant?
ReactNative is basically giving tons of instructions from the JS engine to the OS. Sure the performance of the OS is great, but this has limitations and many moving pieces.
For example animations used to be a problem in RN because someone thought it was a good idea to send instructions on every frame from the JS engine to the OS. Of course many devices can't keep up with this, and I imagine Facebook solved this by creating an animation engine on the native side of things and JS only passing start/end states and such.
Earlier quoted context omitted.
The OPO 6 is out now with 8GB RAM, so no not in two years, let alone 7.
That's an outlier, pretty niche one at that. (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.
Earlier quoted context omitted.
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…
AFAIK all virtual lists break native searching in the browser, so sadly the problem is far from solved
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…
This assumes the web rendering context is the proper abstraction to build application UIs. Its not. Its too complex and object-oriented to be efficient. It was intended for documents and is a general pain to work with for applications. For one, there's a lot to be learned from immediate-mode UIs (I'm thinking Dear IMGUI, not Unity3D's GUI); ie state inside components generates complexity, which is a bad thing. Your v…
So you believe such a UI API should be immutable (whatever that means in this context), and modelled as a sequence of actions? I think that's fine, but probably not practical in reality. I don't see the point of having a debate about the merits of functional programming vs. OOP in the middle of your post. People are going to build tools around the API that will abstract away whatever semantics you feel are best in order to fit their own needs. So the goal is to build an API that's simple at it's core to implement and use.
Inevitably someone actually has to go and code the adapter layer between the protocol receiver and the actual low level rendering layer (be it OpenGL, UIKit, etc.) and unless you build a system that's easy to understand on that end as well, you're gonna end up with an API no one actually likes or wants to use.
I don't think it's unreasonable to expect that the low-level rendering engine (ie. an implementation in UIKit) maintains some level of UI state. That is - after all - where most of the optimizations will come from. And that's how UIKit, OpenGL and most other rendering systems work. Things generally aren't immutable because it's a.) not efficient, and b.) a nightmare to work with at the lowest levels. It seems to me the appropriate abstraction is build the protocol around a UI state tree, because that's what everyone else is already working with. This is incredibly easy to maintain on either end, and higher level libraries can easily remove the pain of UI state management (a la React, Vue, etc.)