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

Vue Native (2018)

vue-native.io

Post reply on HN
Print view View original

151–160 of 190 posts

Re: Vue Native (2018)

#151

Post by seanalltogether »

uryga wrote: post #65
seanalltogether wrote: post #21

Earlier quoted context omitted.

Additionally, html documents inside browser windows are naturally stateless content systems, but applications have never had this constraint. The design patterns that are successful on a browser are usually overkill in application development. Android has baked a few of these stateless design patterns into their core frameworks and then spent years coming up with various support libraries to overcome them.

> html documents inside browser windows are naturally stateless content systems what about inputs? or do you consider them stateless because their entire¹ "state" is reflected in the DOM, i.e. // *click* --- ¹ - well, except focus, open/closed for , and probably a bunch of other things

In this context stateless usually refers to access to the wider system. When an html page loads, it has no state it can access right away, it has only raw data in the url and cookies. You are constantly having to recreate the state of the system as a user moves from one page to another. Design patterns like react are a natural fit for this system, its turtles all the way down.

Applications on the other hand start their lifecycle as a singleton and because you can guarantee a parent child relationship from top to bottom it tends to facilitate design patterns with sharing of state more easily between pages.

Re: Vue Native (2018)

#152

Post by rkangel »

mumblemumble wrote: post #111
cphoover wrote: post #92

Earlier quoted context omitted.

> The problem is that it's bad. I say this as someone who comes from the outside, and isn't an expert ("barely competent" in HTML/CSS is probably accurate). Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes. There's a lot of history confusing the issue and three ways of doing each thing. How can you say this with a "barely competent" level of exp…

The last paragraph really hits the nail on the head. HTML+CSS+JavaScript is just so complex, with so many details to learn, and so many corner and edge cases to understand. Not necessarily inherently, more as a result of taking a set of tools that were originally designed for doing one thing - creating hypermedia documents - and repurposing it for creating rich application graphical user interfaces. Which is ultimate…

I did come to appreciate how much detail (and therefore) effort goes into a modern UI. I was building something that was effectively a messaging app for my startup. I was doing it in Flutter so progress was good and things generally behaved pretty well. But so many little things needed to be done to get e.g. the input box to behave intuitively (e.g. hide 'attach image' button when writing text). I was basically copying the standard approach from FB Messenger and WhatsApp. Apps at that level of polish have raise out expectation. That changes thing for developers - when it was "just add a button" everyone could pitch in, but now it can be full time work for several people.

Re: Vue Native (2018)

#153

Post by kall »

0df8dkdf wrote: post #75
ktpsns wrote: post #5

I love functional concepts such as stateless systems, but young folks should acknowledge that two way event binding is something graphical desktop toolkits are doing since decades. For instance, Qt signal-slot mechanism https://doc.qt.io/qt-5/signalsandslots.html or https://libsigcplusplus.github.io/libsigcplusplus Furthermore, MVC is , when done correctly, a sane two way data-GUI binding. However, I have never seen…

Yup thank you. Web is only now coming to terms with desktop application development world of doing things. While I support the movement, however there are too many legacy stuff in the web and how front end developer use JS like jquery type of thing to manage a document base page. Maybe there should be a mode like 'stric mode' to support two way data binding.

The problem, if there is one, with the web stuff discussed here is not that it is not strict enough to facilitate two way data binding but the opposite. Modern web frameworks use stricter one way data binding because they posit two way data binding is too dangerous / hard to reason about. It could easily be added and vue does in fact have some of it.

Re: Vue Native (2018)

#154

Post by kall »

vlz wrote: post #17

It should be noted that this is a wrapper around React Native.[1] I am a bit in doubt if one can use Vue Native knowing only Vue and never having to learn any React. [1]: https://github.com/GeekyAnts/vue-native-core says as much.

It is doubtful that you can use react native without also somewhat understanding the android/iOS layers below so adding another layer is not super appealing.

Re: Vue Native (2018)

#155

Post by deergomoo »

kall wrote: post #149
nolok wrote: post #93

Earlier quoted context omitted.

I just don't understand what happened to classical RAD from the late 90s early 00s. OK web was out of touch because no one really uses the "standard gui" anymore, even something as simple as a button has different look and behavior on every website. But mobile app should be prime targets for it, and theming is a well understood concept for it too. So why do we not have a proper rad tool (drag and drop my button where…

For iOS and macOS there is Interface Builder that is somewhat like that. It seems to have fallen out of favour. I‘m not really sure why but I know I prefer developing code based UI as well.

The issue most people seem to have with IB/Storyboards is that they're incredibly difficult for multiple people to work on. They're huge, dense XML files, so trying to solve a merge conflict is a challenge to say the least.

It's been a long while since I've done much iOS dev but I also recall when learning Storyboards that there were lots of things that just seemed half baked or poorly thought out.

For example, the only way to set a corner radius from the UI was to type the key-path of the layer property into a "Runtime Attributes" input, in a totally separate tab from the rest of the visual properties.

I also recall headaches over things like setting the colour of the status bar, or titles on Navigation controllers, where the runtime value would often be different to what IB showed for some reason.

Re: Vue Native (2018)

#156

Post by mmcnl »

jdjfktkrnj wrote: post #131
rkangel wrote: post #88

Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views? I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written…

I've used pretty much all GUI frameworks - raw Win32, MFC, WinForms, wxWindows, Qt, WPF, native Android and iPhone. HTML/CSS is vastly more powerful and productive, especially when using something like React/Vue. It's not because "web devs who don't know anything else". HTML/CSS is just a superior technology. No wonder that even traditional GUIs are moving this direction - Qt with QML, windows with their new Win10 fl…

Probably an unpopular opinion but I wholeheartedly agree. I think HTML/CSS is excellent.

Re: Vue Native (2018)

#157

Post by c-smile »

kall wrote: post #145
c-smile wrote: post #134

Earlier quoted context omitted.

> HTML/CSS is an inevitable part of the ecosystem because the web is an important target. You did confuse cause with effect. In the first place Web accepted HTML/CSS/JS for the good reason - as a classic implementation of "Separation of Concerns" principle. See: 1. HTML defines semantic structure of UI - DOM tree. 2. JS, as language-behind-the-UI, handles users events and updates DOM tree and its state. 3. CSS define…

I think they adopted them for good reason and they are good at what they are made for: web pages. It shines in situations where content, behaviour and presentation are seperate concerns. A good example is a CMS/wordpress (which as we know makes up a third of the internet or something): Editors are concerned with content, themes are concerned with presentation, plugins are concerned with behaviour. Applications, espec…

> Applications, especially desktop applications, are nothing like that. Seperations of concerns gains you very little there.

I think you are making critical mistake here.

IAccessible & Co. (https://docs.microsoft.com/en-us/windows/win32/api/oleacc/nn...) maps nearly directly onto HTML DOM tree. So no matter what CSS you have there your UI will accessible.

The thing is that accessibility works acceptable only on semantic DOM trees. HTML and its DOM was designed with that in mind. Flutter's DOM is not, it is not semantic - it is a Dart code that defines visual structure for particular screen layout.

Mobile applications are significantly less demanding (more simple in UI terms) - they have very reduced set of components and layouts. Essentially all mobile UIs are built with ,, and vocabulary.

The reason is simple: most of the time mobile apps are serving "reading user" role. While desktop is the place for "writing user"s (a.k.a "content generation" role). Desktop is the place where you must support different editing, object manipulation paradigms - UI on desktop is more rich. Just check apps on your mobile - 90% of them are very close UI-wise.

Re: Vue Native (2018)

#158

Post by kall »

mrtksn wrote: post #22

What are the trade offs/Adventages to use cross platform tools for app development in 2021? The advantages of native iOS development, off top of my head: 1) Swift is very pleasant to use and it is fast. 2) The UI libraries that I need to learn: UIKit and SwiftUI. SwiftUI is also very pleasant to use and it is getting there. 3) No hoops to jump for integrating API that makes an App do things that WebApp cannot do. 4)…

Cross platform is the obvious one. I think react native is "good enough" in app quality and tooling. I agree with most of your points. Developing a iOS only app is smoother sailing. The 10-50% more effort it takes to make a good RN app can easily be offset by a) getting 2+ plattforms b) if you have >10-50% more experience with JS and factor that into dev time/quality. The downsides and cross platform are covered, here‘s some other benefits:

- if you think swiftUI is better than AppKit you can use a mature framework in the same style and could have been doing so for years

- live feedback: SwiftUI previews and fast recompiles are garbage compared to React Fast Refresh which instantly updates the running app, on device, even preserving UI state half the time

- you can update the app outside of the app store, it may be against the rules or not but people do it all the time

- there are more medium quality but ready to go UI components out there. I was pretty shocked by that the last time I did iOS dev.

- Swift is a good language but Typescript is way more chill while still being a pretty good language

- personal opinion: simple animations in react native are not exactly perfect but coding custom CoreAnimation is way harder (for me)

- going from a random design that does not take iOS UI conventions or guidelines into account to an app that looks exactly the same is faster/easier. Is that good? Idk but it‘s something agencies need to do all the time.

Re: Vue Native (2018)

#159

Post by kgin »

rkangel wrote: post #88

Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views? I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written…

If you throw out everything except plain containers (DIVs) and standardized flexbox (like Yoga). It's great. It's 5000% better than iOS AutoLayout.

Re: Vue Native (2018)

#160

Post by kall »

c-smile wrote: post #157
kall wrote: post #145

Earlier quoted context omitted.

I think they adopted them for good reason and they are good at what they are made for: web pages. It shines in situations where content, behaviour and presentation are seperate concerns. A good example is a CMS/wordpress (which as we know makes up a third of the internet or something): Editors are concerned with content, themes are concerned with presentation, plugins are concerned with behaviour. Applications, espec…

> Applications, especially desktop applications, are nothing like that. Seperations of concerns gains you very little there. I think you are making critical mistake here. IAccessible & Co. ( https://docs.microsoft.com/en-us/windows/win32/api/oleacc/nn... ) maps nearly directly onto HTML DOM tree. So no matter what CSS you have there your UI will accessible. The thing is that accessibility works acceptable only on sem…

I agree that a UI is well expressed as a tree, for the sake of accessibility and other reasons. I don‘t see why there is any reason to seperate the declaration of that tree from the application code. The flutter approach is bad, but all established desktop and mobile UI frameworks provide accessibility support as good or better than HTML.

In fact, HTML is ill equipped to express capital A Applications in an accessible form and needs ARIA as a bandaid to make it work.

The application runtime knows about the UI tree by the time the app is running and can tell accessibility tools about it. Wether you write it down explicitly or not doesn‘t matter. It only matters for web "pages" which are original not something that is running at all.

Post reply on HN