Live data from Hacker News

Vue Native (2018)

vue-native.io

111–120 of 190 posts

Re: Vue Native (2018)

#111
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…

> 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 ultimately a very different problem space with different needs and design constraints.

I'm also struck by the total development effort required. Once upon a time, the GUI was something that the whole dev team pitched in on. Hopefully a designer was guiding the work. But all the programmers could easily pitch in on the actual implementation, with minimal up-front training. Nowadays, the work often goes to specialists, and "full stack" is actually a thing people highlight on their resumés, rather than something that goes without saying.

Perhaps that has nothing to do with the technology. Some of what's going on is undoubtedly just that all professions become more specialized as they mature. The bar for what counts as a good UI has also raised quite a bit over time. And the actual ask is quite a bit more impressive, too. A single GUI codebase that can dynamically adapt to everything from a smartphone screen to a large computer monitor, without looking janky at any point in between, is something that, to my knowledge, has never been asked of a Visual Basic application.

But still, even given all that, it's hard not to at least wonder if we could have ended up in a better place if we had been given a technology stack that had been designed from the ground up for the problem domain, rather than having to make do with something that was never meant for this problem domain, but has been adapted to it through the accretion of many layers of hacks.

Re: Vue Native (2018)

#112
post #90
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…

Just like JavaScript: it's bad but it is the only thing that works everywhere so it's won.

It's not the only thing that works everywhere anymore, other languages can be compiled to JS and WebAssembly.

Re: Vue Native (2018)

#113
post #106
post #95

Earlier quoted context omitted.

Is "editing things" (i.e. data) not central in the majority of apps?

Sure, but the text editor does have undo.

Text is important, but its datum is rarely independent. More undo is useful than the text in the current text control. Anything else requires (and rarely gets) more substantial command undo/redo. I'm not making a black&white point, I am honestly surprised it so easily became "non-essential without apology".

Re: Vue Native (2018)

#114
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)…

> What are the trade offs/Adventages to use cross platform tools for app development in 2021?

I use Xamarin for some projects and it's serviceable. Xamarin Forms is a decent toolkit for cross platform internal business apps. Personally I enjoy native iOS dev quite a bit more than cross-platform Xamarin dev, but depending on your use-case, Xamarin might be a better idea than writing separate native iOS and Android apps. Again, I believe for internal business apps that needs to be multi-platform and don't have to look very beautiful, in those cases Xamarin is an excellent choice.

So with that out of the way I want to compare each of your points with the Xamarin situation, from my point of view.

> 1) Swift is very pleasant to use and it is fast.

C# is very pleasant to use as well. It's quite modern and feature wise is pretty close with Swift. On iOS it's probably a little bit slower, but still good enough for most use-cases. I prefer Swift over C#, but C# is almost as nice to use in my opinion.

>2) The UI libraries that I need to learn: UIKit and SwiftUI. SwiftUI is also very pleasant to use and it is getting there.

UIKit and SwiftUI are available for Xamarin, however when developing with Xamarin Forms you will likely try to avoid using these libraries, since Xamarin Forms is meant to cover both iOS and Android UIs.

>3) No hoops to jump for integrating API that makes an App do things that WebApp cannot do.

Again, pretty much all native APIs are available from C# in Xamarin.

>4) Work environment setup is very easy, no scripts to run no tooling that breaks down. It's as simple as creating an new Word document and start doing actual work, not janitorial tasks.

Generally the same for Xamarin, though I guess there's some extra layer of tooling (from what I understand Xamarin translates the C# code to native code, probably Objective-C, maybe Swift).

>5) Despite its bugs, Xcode is a good IDE that natively understand all the tooling I use. Autocomplete might break down sometimes but it can handle project creation, asset management, project configurations and the distribution.

Xcode is leagues above Xamarin Studio. My main issue with Xamarin Studio is that the app just becomes dog-slow after some time. Interaction between Xamarin Studio and iOS Simulator is sometimes also a bit finicky.

>6) The only vendor that I rely on is Apple, as soon as they make something interesting it is available to me. The latest API is there right away.

In Xamarin usually new APIs are available pretty much as soon as Apple releases a new SDK. From what I understand Xamarin uses some automated tooling to generate the C# SDK based on Apple's header. Same stuff you can use to wrap third party libraries in a C# project (Objective Sharpie [0]). Objective Sharpie isn't trivial to use, but quite powerful.

>7) The apps look in place by default, you actually have to work to make UI unconventional and weird.

Xamarin uses the native UI components, regardless if you use Xamarin iOS, Xamarin Android or Xamarin Forms. However, Xamarin Forms is meant to encompass both iOS and Android and therefore is a bit less flexible.

---

[0]: https://docs.microsoft.com/en-us/xamarin/cross-platform/maci...

Re: Vue Native (2018)

#115
post #97
post #59

Flutter web is also becoming a viable option for web apps. I recently wrote a new app in Flutter and it works surprisingly well on the web, not just in native iOS and Android. It has some quirks though but I did not find anything serious.

Isn’t it still just a canvas with basically no accessibility, and all the negatives of a flash app?

The negatives of Flash are:

* closed source

* requires ag extra plugin to render

* slow

* fake sandbox that had too many bugs

Flutter has none of these.

Re: Vue Native (2018)

#116
post #100
post #91

Earlier quoted context omitted.

Just like C: it's bad but it is the only thing that works everywhere so it's won.

Thanks for pointing this out. I've made a respectable living off web technologies, and the products I've built create value for many people. Maybe it's not the sharpest knife in the kitchen and I'm not Gordon Ramsay, but the final consumer product is still pretty close to being regarded as Michelin Star quality, not as a boast but just a point of fact. Giving an flip "XYZ technology bad!" remark usually comes across…

Actually I see them as weight that prevents the industry to move forward.

Re: Vue Native (2018)

#117
post #90

Earlier quoted context omitted.

Just like JavaScript: it's bad but it is the only thing that works everywhere so it's won.

Modern JavaScript is pretty good.

And that's something a lot of JS haters have overlooked. I have purposely ignored it for the past few years and am just now getting back into it for doing CLI and back-end Node work... I find myself amazed at what's been added and improved since I was writing jQuery and AngularJS a few years back. I still have no interest in getting back into DOM work if I can avoid it but Node is kinda nice!

Re: Vue Native (2018)

#118
post #115
post #97

Earlier quoted context omitted.

Isn’t it still just a canvas with basically no accessibility, and all the negatives of a flash app?

The negatives of Flash are: * closed source * requires ag extra plugin to render * slow * fake sandbox that had too many bugs Flutter has none of these.

I meant it in terms of a widget with no notion of the DOM. You can’t really right click, select, only if the app creator overrides those events. Nothing native.

Also, what if the creator embeds an ad inside a canvas? You would need an AI to hide it from there. So, all in all a pretty terrible direction to go..

Re: Vue Native (2018)

#119
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…

Use what works for you. Why does it have to be the same way for everyone?

Re: Vue Native (2018)

#120
post #97
post #59

Flutter web is also becoming a viable option for web apps. I recently wrote a new app in Flutter and it works surprisingly well on the web, not just in native iOS and Android. It has some quirks though but I did not find anything serious.

Isn’t it still just a canvas with basically no accessibility, and all the negatives of a flash app?

It builds to HTML and JS using dartj2s. It chooses the canvas if on a desktop browser, and HTML on mobile. I chose to make the default HTML always, for predictability.
Post reply on HN