Vue Native (2018)(vue-native.io)
vue-native.io
Vue Native (2018)
https://vue-native.io/
189 comments
Hopefully one day we can get to where Visual Basic was in the 90's.
I keep vainly hoping for undo/redo, configurable keyboard shortcuts, cross-app files, app help, you know... the wins of the Windows 3.x 90s.
I'm honestly amazed some (especially undo!) were shrugged away so easily.
I'm honestly amazed some (especially undo!) were shrugged away so easily.
Can you elaborate? Undo/redo in what contexts? What applications had undo/redo besides for editing things?
Is "editing things" (i.e. data) not central in the majority of apps?
I'm asking for specifics because I actually can't think of any apps where "undo" would make sense, but is missing. I'm probably not creative enough. But that's why I asked for examples. These are the things I thought of:
Text editor? Those have undo.
Image editor? Also have undo.
Video Games? Depends. Should you be allowed to "undo" in a game of minesweeper? Probably not- it kind of ruins the game. Should you be allowed to "undo" in Chess? Probably not. Should you be allowed to undo in Solitaire? Maybe.
Chat client? What would you undo? Can't unsend a message.
Web Browsers have back buttons, to the extent that those can undo.
I could see file managers maybe having undo. I honestly don't know if the popular ones today do or not.
What apps are missing undo functionality for you?
Text editor? Those have undo.
Image editor? Also have undo.
Video Games? Depends. Should you be allowed to "undo" in a game of minesweeper? Probably not- it kind of ruins the game. Should you be allowed to "undo" in Chess? Probably not. Should you be allowed to undo in Solitaire? Maybe.
Chat client? What would you undo? Can't unsend a message.
Web Browsers have back buttons, to the extent that those can undo.
I could see file managers maybe having undo. I honestly don't know if the popular ones today do or not.
What apps are missing undo functionality for you?
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".
I regret Delphi is a niche product now as it's quite powerful now, with native apps also for mobile platforms. Pity that the Community Edition doesn't support Linux.
Worth a mention that https://www.lazarus-ide.org/ is aiming to replace Delphi, and runs on Linux.
They also seem to support app development for Android: https://wiki.lazarus.freepascal.org/Portal:Android and iOS: https://wiki.lazarus.freepascal.org/Portal:iOS
They also seem to support app development for Android: https://wiki.lazarus.freepascal.org/Portal:Android and iOS: https://wiki.lazarus.freepascal.org/Portal:iOS
Do native Delphi applications use native controls (when available)? Do they feel native, or are they their own thing? I'm thinking specifically of Java Swing applications that never felt native.
The traditional, standard, component library was built around the native Win32 controls[1].
Some time ago they acquired a cross-platform component library, FireMonkey[2], which does not use native controls.
[1]: https://docs.microsoft.com/en-us/windows/win32/controls/indi...
[2]: http://docwiki.embarcadero.com/RADStudio/Sydney/en/FireMonke...
Some time ago they acquired a cross-platform component library, FireMonkey[2], which does not use native controls.
[1]: https://docs.microsoft.com/en-us/windows/win32/controls/indi...
[2]: http://docwiki.embarcadero.com/RADStudio/Sydney/en/FireMonke...
Delphi is definitely 100% native. I'm not sure about Free Pascal's Lazarus; it looks native when I've used it, but I'd need to break out Spy++ or WinObj or something to actually poke at what's going on.
[deleted]
The BFF pattern[1] may be more useful today to many, due to various types and sizes of devices and different sorts of integrations.
MVC can be used in its place, but it would often introduce unnecessary complexity, e.g. additional controllers.
MVC works for contextually equivalent interaction, which is still very useful, too.
Mostly just do what makes sense.
The challenge is, as it has been, how to be flexible, smart, and forward-looking, but developing quickly for what’s needed now.
But whether you’re coding a quick prototype or designing a large project (which is risky because a feedback loop from all users may be longer), focusing too much on the how and specifics instead of the overall experience may get you into trouble later.
For example, you could have what sounds ideal: microservices, individual teams each working on them focused on their own goals, powering a site with the latest, well-used JS framework, able to deploy quickly and developing quickly with a lot of fun-but-professional-looking communication, and end up with a slow, broken application.
[1]- https://samnewman.io/patterns/architectural/bff/
MVC can be used in its place, but it would often introduce unnecessary complexity, e.g. additional controllers.
MVC works for contextually equivalent interaction, which is still very useful, too.
Mostly just do what makes sense.
The challenge is, as it has been, how to be flexible, smart, and forward-looking, but developing quickly for what’s needed now.
But whether you’re coding a quick prototype or designing a large project (which is risky because a feedback loop from all users may be longer), focusing too much on the how and specifics instead of the overall experience may get you into trouble later.
For example, you could have what sounds ideal: microservices, individual teams each working on them focused on their own goals, powering a site with the latest, well-used JS framework, able to deploy quickly and developing quickly with a lot of fun-but-professional-looking communication, and end up with a slow, broken application.
[1]- https://samnewman.io/patterns/architectural/bff/
The problem with two way data binding is it assumes a function call is free. Two way data binding breaks when a function call is many orders of magnitude slower, like over the web. You end up with classic ASP.NET.
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.
¹ - well, except focus, open/closed for <select>, and probably a bunch of other things
what about inputs? or do you consider them stateless because their entire¹ "state" is reflected in the DOM, i.e.
<input type="checkbox"/>
// *click*
<input type="checkbox" checked=""/>
¹ - well, except focus, open/closed for <select>, 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.
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.
ah gotcha! for some reason i thought you were talking at the component level, not app level.
The sanest MVC implementation is AppKit and classic UIKit.
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.
You might not like Svelte.
There's a big difference between something being new vs being new to a developer that I try to see if a developer understands.
Yes and yes. And I think that as a whole the industry moved towards MVVM which is a lot more achievable than MVC for the better.
[deleted]
I wish I could figure out the openwrt MVC gui stuff
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 for the web platform that you want to re-use. This means that HTML/CSS gives you a head-start due to existing skillsets. It's familiar for some people and they can get going.
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.
Coming at it fresh, it's a lot to learn to build a desktop/mobile UI. Flutter (for example) has its issues, but getting things to lay out correctly did not take a lot of learning. Once you've got the basics (3 days to a week for me, including learning Dart) things behaved predictably - it seems to take a lot of HTML/CSS knowledge before that is the case.
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 for the web platform that you want to re-use. This means that HTML/CSS gives you a head-start due to existing skillsets. It's familiar for some people and they can get going.
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.
Coming at it fresh, it's a lot to learn to build a desktop/mobile UI. Flutter (for example) has its issues, but getting things to lay out correctly did not take a lot of learning. Once you've got the basics (3 days to a week for me, including learning Dart) things behaved predictably - it seems to take a lot of HTML/CSS knowledge before that is the case.
> 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 expertise? I would rather hear a well reasoned argument from someone who knows the ecosystem and its trade-offs.
How can you say this with a "barely competent" level of expertise? I would rather hear a well reasoned argument from someone who knows the ecosystem and its trade-offs.
> How can you say this with a "barely competent" level of expertise?
I get that, and that's why I declared it. I have two reasons why I think the opinion is still valid:
I'm not completely incompetent. I have produced useful web frontend work. After having spent more time on web technologies than a lot of others I still find it to be slower and harder. This point is about learning - I have done some learning in both and I can compare. It's a small sample size, but seems to agree with the experience of other people.
The other point is that most people talking about this are already experts in HTML/CSS. That learning is a sunk cost for them so they're not making fair comparisons. I also sometimes feel like there's a little 'Stockholm syndrome' - they've invested time and effort in learning the techniques and tools required to produce good quality web UI, and now that they can they overlook the effort required to get to that point and proclaim the wonderful nature of what they're using.
The sunk cost thing is the important aspect. I'm not even saying that it's wrong that it's become the standard UI description language - it as at least an open specified standard. I'm just saying that not enough attention is paid to the downsides.
I get that, and that's why I declared it. I have two reasons why I think the opinion is still valid:
I'm not completely incompetent. I have produced useful web frontend work. After having spent more time on web technologies than a lot of others I still find it to be slower and harder. This point is about learning - I have done some learning in both and I can compare. It's a small sample size, but seems to agree with the experience of other people.
The other point is that most people talking about this are already experts in HTML/CSS. That learning is a sunk cost for them so they're not making fair comparisons. I also sometimes feel like there's a little 'Stockholm syndrome' - they've invested time and effort in learning the techniques and tools required to produce good quality web UI, and now that they can they overlook the effort required to get to that point and proclaim the wonderful nature of what they're using.
The sunk cost thing is the important aspect. I'm not even saying that it's wrong that it's become the standard UI description language - it as at least an open specified standard. I'm just saying that not enough attention is paid to the downsides.
Super valid point. I've been a frontend dev for a while and I'm comfortable with HTML and CSS but I can definitely imagine switching to something else. The sunk-cost fallacy thing is real, though.
But the complexity arises from wanting to make apps with something meant for simple documents. That being said, even building the simplest website nowadays requires a mind-boggling knowledge of the idiosyncrasies of the "languages".
I want to lose my job; I want the next best thing to be completely different but still allow for creativity and productivity.
But the complexity arises from wanting to make apps with something meant for simple documents. That being said, even building the simplest website nowadays requires a mind-boggling knowledge of the idiosyncrasies of the "languages".
I want to lose my job; I want the next best thing to be completely different but still allow for creativity and productivity.
I have a hard time understanding why the cost of learning web dev (CSS/html) is a sunk cost.
It’s reaping so much benefit that these experts can easily make mobile apps without learning another way to describe UI.
It’s reaping so much benefit that these experts can easily make mobile apps without learning another way to describe UI.
I'm agree with you but I gotta say, I have yet to find the perfect tutorial that say "follow these N steps and you'll always get what you expect".
For me, the common places things break are, setting up a flexbox and not having the content scale to fit.
Trying to make an app like layout (so the page itself doesn't scroll though some content in various areas might) and again, trying to get various flexbox areas to either fit their content or get the content to fit its area without expanding the page past the window size (note: if you use overflow: hidden you failed)
In any case I'm not a UI/UX designer so I don't do it daily, therefore when I do need to do it it's always a bunch of frustrating trial and error.
That said, I do think there are a class of designers that also don't know these answers. They just know a few frameworks that handle all of this for them.
For me, the common places things break are, setting up a flexbox and not having the content scale to fit.
Trying to make an app like layout (so the page itself doesn't scroll though some content in various areas might) and again, trying to get various flexbox areas to either fit their content or get the content to fit its area without expanding the page past the window size (note: if you use overflow: hidden you failed)
In any case I'm not a UI/UX designer so I don't do it daily, therefore when I do need to do it it's always a bunch of frustrating trial and error.
That said, I do think there are a class of designers that also don't know these answers. They just know a few frameworks that handle all of this for them.
It is a sunk cost for them. They literally cannot get it back. But for somebody new why should they have to pay this cost if there are many less expensive ways to describe a UI. The lowest common denominator is now invading everything including native. This often happens but it is regrettable.
Because of backwards compatibility, HTML+CSS makes it cumbersome to use the simplest ways to layout things. And it's also confusing because the oldest ways are still very much valid. You have to make divs (or semantic equivalents that I'm not sure are used anymore), and then mark them as different kinds of displays using CSS, with multiple sublanguages for multiple properties.
Compare that to QML Quick Layouts[1], GTK containers [2] or winui controls [3] where you just instantiate whatever kind of display with the container you want in a single model using qml/GTK Builder XML/XAML and be done with it.
[1] https://doc.qt.io/qt-5/qtquicklayouts-index.html
[2] https://developer.gnome.org/gtk3/stable/GtkContainer.html#Gt...
[3] https://docs.microsoft.com/en-us/windows/winui/api/microsoft...
Compare that to QML Quick Layouts[1], GTK containers [2] or winui controls [3] where you just instantiate whatever kind of display with the container you want in a single model using qml/GTK Builder XML/XAML and be done with it.
[1] https://doc.qt.io/qt-5/qtquicklayouts-index.html
[2] https://developer.gnome.org/gtk3/stable/GtkContainer.html#Gt...
[3] https://docs.microsoft.com/en-us/windows/winui/api/microsoft...
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.
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.
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.
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 flat design API (forgot its name)
> Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes.
It's still easier to solve these problems than in a traditional GUI, which if you noticed tend to have a mostly fixed layout, exactly because dynamic layout is so difficult to get right in them.
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 flat design API (forgot its name)
> Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes.
It's still easier to solve these problems than in a traditional GUI, which if you noticed tend to have a mostly fixed layout, exactly because dynamic layout is so difficult to get right in them.
So glad to hear this sentiment. It's frustrating that so many people don't seem to acknowledge how flexible HTML/Javascript is. It's not perfect, it's probably not the most efficient possible set of APIs, but it has to deal with a whole lot of legacy, just like most programming languages/platforms/frameworks.
Much of this conversation seems to consist of "the popular solution to this insanely complex problem is hard! Why isn't it trivially easy!?"
Much of this conversation seems to consist of "the popular solution to this insanely complex problem is hard! Why isn't it trivially easy!?"
> No wonder that even traditional GUIs are moving this direction - Qt with QML,
QML (march 2009) is older than angular, react, vue which are all post-2010. And still they are all more complicated to use as a language
QML (march 2009) is older than angular, react, vue which are all post-2010. And still they are all more complicated to use as a language
Probably an unpopular opinion but I wholeheartedly agree. I think HTML/CSS is excellent.
Have the same feelings about HTML/CSS and even similar towards JS.
I believe that if one gets a grasp of it, then CSS is extremely easy now, compared to like 5-6 years ago, where on top of CSS itself, you had to be good with all the quirks for IE and other browsers.
If today someone tells that CSS is hard, I honestly get stunned. I wonder if the idea of "everyone can code" might be root cause of current state. I mean - if after some time you cannot get intermediate CSS skills, then I'd say that web programming (and maybe any other) is not for you.
It was with the boom of Tailwind CSS when I started to see a lot of comments like "OMG this framework is great - CSS was always hard for me, now I can do much more".
If today someone tells that CSS is hard, I honestly get stunned. I wonder if the idea of "everyone can code" might be root cause of current state. I mean - if after some time you cannot get intermediate CSS skills, then I'd say that web programming (and maybe any other) is not for you.
It was with the boom of Tailwind CSS when I started to see a lot of comments like "OMG this framework is great - CSS was always hard for me, now I can do much more".
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 I want it, see the list of events, double clic onclic to edit code to run on clic event, customize onrender if I want some magic look or draw on a canvas,...).
It has got to be better than this html/js horror show.
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 I want it, see the list of events, double clic onclic to edit code to run on clic event, customize onrender if I want some magic look or draw on a canvas,...).
It has got to be better than this html/js horror show.
> classical RAD from the late 90s early 00s.
RAD, a.k.a. UI-nailed-down-to-pixel-grid approach, has died immediately after we've switched from 640x480 pixel screens to variety of display and devices.
If in doubts think about Adaptive and Responsive Designs ( https://en.wikipedia.org/wiki/Responsive_web_design ) in regards of RAD.
RAD, a.k.a. UI-nailed-down-to-pixel-grid approach, has died immediately after we've switched from 640x480 pixel screens to variety of display and devices.
If in doubts think about Adaptive and Responsive Designs ( https://en.wikipedia.org/wiki/Responsive_web_design ) in regards of RAD.
But that's not a limitation of RAD. Delphi 4 and Visual Basic both had "align and/or resize proportionally" on all axis.
Making an UI that adapted in size from 640 to 1280 was a 4 clicks matter.
Having COMPLETLY SEPARATE UI for different form factor like we need on the web sure, but that shouldn't be an issue on mobile just pack X version of your UI like you end up doing with all your resources anyway.
> RAD, a.k.a. UI-nailed-down-to-pixel-grid approach
That's really not what RAD was about.
RAD was about "every single component you use is generic, you don't care how it works, you only want to say where it is, what event you listen to, and optionally do some custom rendering".
As said above, positionning could be non-fixed, auto-adapted to the view, ...
Making an UI that adapted in size from 640 to 1280 was a 4 clicks matter.
Having COMPLETLY SEPARATE UI for different form factor like we need on the web sure, but that shouldn't be an issue on mobile just pack X version of your UI like you end up doing with all your resources anyway.
> RAD, a.k.a. UI-nailed-down-to-pixel-grid approach
That's really not what RAD was about.
RAD was about "every single component you use is generic, you don't care how it works, you only want to say where it is, what event you listen to, and optionally do some custom rendering".
As said above, positionning could be non-fixed, auto-adapted to the view, ...
Only for the clueless developers that never bothered to learn how to use layout managers.
Delphi is still around and they do let you drag and drop a mobile layout and target ios and android. I don't know anyone using it though.
Delphi scene is still quite active in Germany, enough to keep getting articles on the Windows and .NET developer related magazines, and a yearly conference.
Delphi suffers from the mismanagement from all its owners, and given its target market, you will usually see it being used across corporations that don't think twice about paying for SAP and Oracle licenses.
Delphi suffers from the mismanagement from all its owners, and given its target market, you will usually see it being used across corporations that don't think twice about paying for SAP and Oracle licenses.
its a real shame too because the pascal langauge is quite nice and would hold its own against zig or c++. I would even learn the free version and potentially invest in the paid version if it ran on osx or linux. Anything thats windows only is a hard no for me.
You can still help improve and contribute to FreePascal and Lazarus on that case.
One problem is that in larger teams, text descriptions that play nicely with version control are much easier to manage. You can review changes, you can share code etc.
It's not dead though - C# development still has Visual Studio and it can be pretty good.
It's not dead though - C# development still has Visual Studio and it can be pretty good.
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.
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.
As someone who is currently making a living as a frontend dev I feel you - however for anything more visually advanced and everything less standard (and I understand that it is debatable whether that should be done in the first place) it's often quite difficult to achieve a certain visual effect in all the other gui toolkits I have tried (QT, PyGtk). Often image-blending modes, configurable shadows, animations (especially on those properties) and dynamical effects either are not available at all or not as simple to set up as I am used to. Nevertheless I'd like to be educated which framework would be a good fit for building your typical animation rich dribbble/behance design with glassmorphism shadow magic and whatnot without writing custom shaders. Maybe Flutter?
Just like JavaScript: it's bad but it is the only thing that works everywhere so it's won.
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 as a meme or as uninformed and snobbish. The fact is these "bad" technologies do a whole lot of good.
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 as a meme or as uninformed and snobbish. The fact is these "bad" technologies do a whole lot of good.
Actually I see them as weight that prevents the industry to move forward.
Isn't C a sweet spot of portability and minimalism ? no matter the defects .. the previous qualities seemed to matter more. I mean there were attempts at replacing C but nothing came close to remove it right ?
C only got there, because UNIX just like the Browser did to JavaScript, has placed it everywhere.
This happened only because Bell Labs/AT&T were forbidden to sell UNIX, hence its source code spread across the industry, with a symbolic price that made it by comparison with other OS vendors feel almost as quite cheap beer.
During the 80's and early 90's, C only mattered in universities and companies that had access to some kind of UNIX flavour.
Everywhere else we had Assembly, Modula-2, Pascal and Basic flavours, BLISS and some PL/I variants like PL/M on CP/M.
So when you happen to have UNIX, and a C compiler around, trying to bring people to use something else, it is the same as trying to replace JavaScript on the browser.
So we come up with our CoffeScript and Typescript likes for systems programming, but C (even in C++, Objective-C) is always there.
This happened only because Bell Labs/AT&T were forbidden to sell UNIX, hence its source code spread across the industry, with a symbolic price that made it by comparison with other OS vendors feel almost as quite cheap beer.
During the 80's and early 90's, C only mattered in universities and companies that had access to some kind of UNIX flavour.
Everywhere else we had Assembly, Modula-2, Pascal and Basic flavours, BLISS and some PL/I variants like PL/M on CP/M.
So when you happen to have UNIX, and a C compiler around, trying to bring people to use something else, it is the same as trying to replace JavaScript on the browser.
So we come up with our CoffeScript and Typescript likes for systems programming, but C (even in C++, Objective-C) is always there.
We're all well aware of the unix/c coupling. What I'm saying is that for low level memory mangling and primitive operations over the set of register based machines.. you don't get any benefits from using another language it seems. I.. just a dude but some people doing HPC said that you can even reach FORTRAN speed on numerics if you fiddle with the right keywords to avoid aliasing.
Again I'm not a C fan.. but what would pascal or basic give you that is a critical factor in making a better system with it ? modula I can't say. Asm is too coupled to the underlying cpu it's out of the window already.
Again I'm not a C fan.. but what would pascal or basic give you that is a critical factor in making a better system with it ? modula I can't say. Asm is too coupled to the underlying cpu it's out of the window already.
Safer with less memory corruption exploits to start with.
Fixing C is so beyond hope that Apple, Oracle, Google, Microsoft, ARM are all driving hardware based solutions for memory tagging and pointer validation, while at the same time reducing the use cases for it across their OS stacks.
Fixing C is so beyond hope that Apple, Oracle, Google, Microsoft, ARM are all driving hardware based solutions for memory tagging and pointer validation, while at the same time reducing the use cases for it across their OS stacks.
> Safer with less memory corruption exploits to start with.
ok I admit defeat on this. I can't barely believe I forgot that u_u;
ok I admit defeat on this. I can't barely believe I forgot that u_u;
Here some updates on hardware memory tagging from Google regarding future Android hardware.
https://youtu.be/zkoOD4hmiGE
Microsoft, FreeBSD, ARM collaboration on CHERI
https://msrc-blog.microsoft.com/2020/10/14/security-analysis...
https://youtu.be/yrk5FfjHDCo
Oracle with ADI
https://docs.oracle.com/cd/E37838_01/html/E61059/gqajs.html
Apple with pointer authentication,
https://developer.apple.com/documentation/security/preparing...
https://youtu.be/zkoOD4hmiGE
Microsoft, FreeBSD, ARM collaboration on CHERI
https://msrc-blog.microsoft.com/2020/10/14/security-analysis...
https://youtu.be/yrk5FfjHDCo
Oracle with ADI
https://docs.oracle.com/cd/E37838_01/html/E61059/gqajs.html
Apple with pointer authentication,
https://developer.apple.com/documentation/security/preparing...
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!
Don’t even tell them.
The modern JavaScript/TypeScript is so amazing and probably the best language I have used.
I have extensive programming experience in other languages like Java, Scala, Python, Ruby, C, Lisp. But JavaScript definitely wins.
The modern JavaScript/TypeScript is so amazing and probably the best language I have used.
I have extensive programming experience in other languages like Java, Scala, Python, Ruby, C, Lisp. But JavaScript definitely wins.
i'm not a js hater but i'd be curious to hear what you think is so great about ts
It is pretty damn powerful and quite elegant. What do you find bad about it?
Not a lot is bad in the language since es6 (I don't know if they kept hoisting or not) but in any case I don't find any reason to put it that high above the rest :) but I was curious about your reasons mostly.
It's not the only thing that works everywhere anymore, other languages can be compiled to JS and WebAssembly.
If you throw out everything except plain containers (DIVs) and standardized flexbox (like Yoga). It's great. It's 5000% better than iOS AutoLayout.
> 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 defines how that DOM tree is presented to the user in its current state.
These three tasks are so distinct that require their own languages that are optimal for the task.
That split has a lot of sense. For example, HTML and abstract DOM tree alone enables accessible access (a.k.a. Section 508). And so on.
There were, are and will be all-in-one approaches to UI, like Flutter or WPF for example. They will never be universal UI solutions for reasons outlined above, especially on desktop UI.
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 defines how that DOM tree is presented to the user in its current state.
These three tasks are so distinct that require their own languages that are optimal for the task.
That split has a lot of sense. For example, HTML and abstract DOM tree alone enables accessible access (a.k.a. Section 508). And so on.
There were, are and will be all-in-one approaches to UI, like Flutter or WPF for example. They will never be universal UI solutions for reasons outlined above, especially on desktop UI.
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, especially desktop applications, are nothing like that. Seperations of concerns gains you very little there. If it does, its a different separation like M-V-C. I think all the successful user interface things introduced in the last few years are going for an all in one code approach for good reason: SwiftUI, Flutter, Jetpack Compose, React Native... I may be a little mobile focused?
The options that ios/mac os/android offered for a while to create UI structure seperate from code where not very popular with developers which often preferred to construct and modify the entire UI tree with code "manually".
What‘s the state of the art in windows and linux UI programming?
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, especially desktop applications, are nothing like that. Seperations of concerns gains you very little there. If it does, its a different separation like M-V-C. I think all the successful user interface things introduced in the last few years are going for an all in one code approach for good reason: SwiftUI, Flutter, Jetpack Compose, React Native... I may be a little mobile focused?
The options that ios/mac os/android offered for a while to create UI structure seperate from code where not very popular with developers which often preferred to construct and modify the entire UI tree with code "manually".
What‘s the state of the art in windows and linux UI programming?
> 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 <radio>,<checkbox>,<button> and <list> 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.
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 <radio>,<checkbox>,<button> and <list> 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.
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.
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.
> HTML defines semantic structure of UI
The problem I have with HTML is that it's only really any good at defining the semantic structure of a document, particularly the type of thing you might produce with a word processor. Half the stuff on a modern webpage—even those you'd still call documents rather than apps—can only really convey meaning via visual layout, and so break down when divorced from CSS/JS.
For example: I'm a big fan of reader mode in browsers, but so often they're tripped up by basic UI affordances like menus and image galleries. The renderer has to guess at what's content and what isn't, so half the time any sort of "widget" is rendered as a crappy-looking vertical list. Sure, that's technically what a menu or gallery is at its most basic level, but surely we can do better?
There probably are sensible defaults you can already follow—representing a menu as a <nav> containing <li>s, say. But it would be much easier if there was a <nav-item> tag. A <nav-item> inside a <nav> would semantically be a menu in the same way that <li> inside <ol> is semantically an ordered list—you don't need any CSS to render that in a sensible way.
Same goes for galleries; if we had a <gallery> tag that could contain <main-image> and <thumbnail>s, you'd still be able to do custom layout with CSS if you needed to, but at the base level you could sensibly render it with just the markup itself.
I dunno, I just find it weird that we added all these new tags for HTML5 years ago then just stopped bothering. I mean when was the last time a HTML element with behaviour was added?
In an ideal world a reader mode could be expanded to a "reader-friendly page mode" wherein the page still looked approximately like the normal webpage, just without all the user-hostile shit. Of course, that's usually diametrically opposed to the financial incentives of running a website, but it's nice to think about.
The problem I have with HTML is that it's only really any good at defining the semantic structure of a document, particularly the type of thing you might produce with a word processor. Half the stuff on a modern webpage—even those you'd still call documents rather than apps—can only really convey meaning via visual layout, and so break down when divorced from CSS/JS.
For example: I'm a big fan of reader mode in browsers, but so often they're tripped up by basic UI affordances like menus and image galleries. The renderer has to guess at what's content and what isn't, so half the time any sort of "widget" is rendered as a crappy-looking vertical list. Sure, that's technically what a menu or gallery is at its most basic level, but surely we can do better?
There probably are sensible defaults you can already follow—representing a menu as a <nav> containing <li>s, say. But it would be much easier if there was a <nav-item> tag. A <nav-item> inside a <nav> would semantically be a menu in the same way that <li> inside <ol> is semantically an ordered list—you don't need any CSS to render that in a sensible way.
Same goes for galleries; if we had a <gallery> tag that could contain <main-image> and <thumbnail>s, you'd still be able to do custom layout with CSS if you needed to, but at the base level you could sensibly render it with just the markup itself.
I dunno, I just find it weird that we added all these new tags for HTML5 years ago then just stopped bothering. I mean when was the last time a HTML element with behaviour was added?
In an ideal world a reader mode could be expanded to a "reader-friendly page mode" wherein the page still looked approximately like the normal webpage, just without all the user-hostile shit. Of course, that's usually diametrically opposed to the financial incentives of running a website, but it's nice to think about.
> Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes.
I've been manually crafting HTML/CSS websites since 2001. Since the arrival CSS flexbox/grid, I don't know anything easier to build layouts than HTML/CSS.
I like what Fluter offers but HTML/CSS is far cleaner/easier to read and simpler.
I've been manually crafting HTML/CSS websites since 2001. Since the arrival CSS flexbox/grid, I don't know anything easier to build layouts than HTML/CSS.
I like what Fluter offers but HTML/CSS is far cleaner/easier to read and simpler.
I’m sad at CSS but not HTML. If you look at other front end approaches by other communities they will have something similar to reusable components which can be nested as a DAG with some technique to pass state around, but which community is inspired by CSS?
Its probably because the best guis are written by JS devs, so the end stack becomes the way they're used to seeing it.
Yes, we need GUI abstractions that compile to HTML/CSS and native platforms, not doing it the other way around.
Just in case: Sciter (https://sciter.com) and Sciter.JS (https://github.com/c-smile/sciter-js-sdk) allow to build native UI applications with HTML/CSS extended by native languages (C, C++, Rust, Go, etc.)
Use what works for you. Why does it have to be the same way for everyone?
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.
[1]: https://github.com/GeekyAnts/vue-native-core says as much.
That's a dealbreaker for me. Not only you need to deal with quirks, bugs and feature-parity with lates OSes of Vue Native, now you also need to deal with the same for React Native. This is a bit too much for me, it's nice when it works but sucks when it stops to work and you spend the whole day to nail down some framework-specific issues.
I just saw this as well. I realize that some people might be more familiar with Vue than React, but wrapping RN seems overly complicated and adds yet another layer of abstraction.
this is super neat that this works but also if someone actually wants to build an app I'd never recommend this. but yeah super cool
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.
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) 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.
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.
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.
7) The apps look in place by default, you actually have to work to make UI unconventional and weird.
I would imagine that on the Android side of things are also not that different.
Edit: I see that you don't like the question being asked and other perspectives being presented but I think it's a fair question and I would like to know if I am missing out on something.
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) 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.
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.
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.
7) The apps look in place by default, you actually have to work to make UI unconventional and weird.
I would imagine that on the Android side of things are also not that different.
Edit: I see that you don't like the question being asked and other perspectives being presented but I think it's a fair question and I would like to know if I am missing out on something.
It depends on what your goals are.
If you are looking to develop for iOS (or any single environment) only, then all the points you make are great, and you should absolutely stick to native development for that environment.
However, if you are looking to target multiple platforms (and by that I don't just mean mobile, but potentially also web, desktop, and more), then some of these frameworks start looking a lot more interesting.
React Native has split the UI from the rendering, and as such now has render targets for much more than just iOS and Android.
And while you can't share 100% of your code, you can develop a shared component library that can all feed into various native shells as needed. That shell can handle your environment-specific bindings and integrations, while your shared components provide your application's UI and interactions.
Of course it all depends on what you are building, and not all apps would be a fit for this approach.
If you are looking to develop for iOS (or any single environment) only, then all the points you make are great, and you should absolutely stick to native development for that environment.
However, if you are looking to target multiple platforms (and by that I don't just mean mobile, but potentially also web, desktop, and more), then some of these frameworks start looking a lot more interesting.
React Native has split the UI from the rendering, and as such now has render targets for much more than just iOS and Android.
And while you can't share 100% of your code, you can develop a shared component library that can all feed into various native shells as needed. That shell can handle your environment-specific bindings and integrations, while your shared components provide your application's UI and interactions.
Of course it all depends on what you are building, and not all apps would be a fit for this approach.
The advantage is that you can access ~100% of the mobile market with a single codebase for about 10% extra work compared to native on a single platform.
Performance is roughly the same and you have access to most of the platform features that most apps need.
Performance is roughly the same and you have access to most of the platform features that most apps need.
That's the obvious value proposition but There's a reason why sporks did not make spoons and forks obsolete.
I messed around with a few cross platform tools a bit and my impression is that if you want to make something that is better than a WebApp you actually have to learn a lot more tools and frameworks and everything feels like falling apart and you are depended on multiple vendors to upkeep the tooling.
The moment you say that your app is more than an UI to access a database, native on multiple platforms is actually easier.
I messed around with a few cross platform tools a bit and my impression is that if you want to make something that is better than a WebApp you actually have to learn a lot more tools and frameworks and everything feels like falling apart and you are depended on multiple vendors to upkeep the tooling.
The moment you say that your app is more than an UI to access a database, native on multiple platforms is actually easier.
I work on React Native projects for a living and what you're saying is true. You need to use both Xcode with ObjC/Swift and Android Studio with Java to get the most out of React Native. That comes with the additional complexity of also needing to learn how Xcode builds projects and how Gradle works.
That's a lot of extra complexity, but it's also no less than if you had built two native apps. You're now just expecting a single team to manage it.
My background is in "real" native development (both Android and iOS) so I get on fairly well with this, however, for people coming to React Native from the web side of things, it's a lot to take in.
Overall, I still recommend to 90% of my clients that React Native is a good way to go if they have limited time and budget. For larger companies, they might have the budget to build and maintain two apps.
Also, most apps really are just UIs on top of a REST API. And even if you do want to make something more custom, you can always create a native component or module yourself for each platform and wrap it to use it with the rest of your React Native app. That way the "boring bits" like the account management, data handling, etc can all still be shared.
It's a trade off, but just about works out for me.
That's a lot of extra complexity, but it's also no less than if you had built two native apps. You're now just expecting a single team to manage it.
My background is in "real" native development (both Android and iOS) so I get on fairly well with this, however, for people coming to React Native from the web side of things, it's a lot to take in.
Overall, I still recommend to 90% of my clients that React Native is a good way to go if they have limited time and budget. For larger companies, they might have the budget to build and maintain two apps.
Also, most apps really are just UIs on top of a REST API. And even if you do want to make something more custom, you can always create a native component or module yourself for each platform and wrap it to use it with the rest of your React Native app. That way the "boring bits" like the account management, data handling, etc can all still be shared.
It's a trade off, but just about works out for me.
I like that analogy!
10%? Try at least 50%. If you wanna do anything complicated you have to drop down to native, which is made more confusing because of the layers of abstraction.
RN, never again.
RN, never again.
Would you mind sharing more about your experience? I'm curious what you were trying to build that was too much for RN.
At my work, my team is pioneering React Native development so I've got a couple of thoughts.
The main benefits for us come down to the fact that we have a large existing JS web application that would take a lot of energy to port to both native platforms (we know from experience, we tried it before). Using React Native, we can share a significant amount of the data and controller layers between web and native. This also means that when a feature gets written for the web, most of the work is already done on mobile (if it was written correctly).
The other key difference is the sheer numbers of each different type of devs we have. At work we have ~400 JS devs and ~30 each of iOS and Android devs. It's just not reasonable to expect the native engineers to be able to keep up. Exploring React Native lets us distribute the load of app development off of the native engineers and put it into some of the web developers. Arguably, an alternate solution would have been to just hire more native devs and I gave that suggestion to management, but that wasn't the direction they wanted to take.
The main benefits for us come down to the fact that we have a large existing JS web application that would take a lot of energy to port to both native platforms (we know from experience, we tried it before). Using React Native, we can share a significant amount of the data and controller layers between web and native. This also means that when a feature gets written for the web, most of the work is already done on mobile (if it was written correctly).
The other key difference is the sheer numbers of each different type of devs we have. At work we have ~400 JS devs and ~30 each of iOS and Android devs. It's just not reasonable to expect the native engineers to be able to keep up. Exploring React Native lets us distribute the load of app development off of the native engineers and put it into some of the web developers. Arguably, an alternate solution would have been to just hire more native devs and I gave that suggestion to management, but that wasn't the direction they wanted to take.
React Native Web (https://github.com/necolas/react-native-web) is a nice solution for better cross-compatibility between React Native and React DOM.
React DOM is very coupled with DOM elements, so React Native Web abstracts away web-specific things, so that code is more sharable.
React DOM is very coupled with DOM elements, so React Native Web abstracts away web-specific things, so that code is more sharable.
I'm curious what this means:
"...my team is pioneering React Native development..."
React Native has been around for 5 or so years.
"...my team is pioneering React Native development..."
React Native has been around for 5 or so years.
Presumably pioneering it for their specific organisation.
Ah. I've never heard it put like that.
but GP's team has just recently started using it
I would imagine that on the Android side of things are also not that different.
The simple fact that there even _is_ an iOS side and an Android side is a large part of what makes cross-platform development appealing.
The simple fact that there even _is_ an iOS side and an Android side is a large part of what makes cross-platform development appealing.
>but I think it's a fair question and I would like to know if I am missing out on something.
You asked why you would want to go cross-platform, and then listed a bunch of things you like about iOS development.
The fact that you aren't even sure what the Android tooling looks like answers your question, doesn't it?
You asked why you would want to go cross-platform, and then listed a bunch of things you like about iOS development.
The fact that you aren't even sure what the Android tooling looks like answers your question, doesn't it?
I haven't asked why I would want a cross platform development. I asked how it looks compared to developing natively on the platforms you want to support.
I know very well why I would want cross platform development, it doesn't take a genius to figure it out.
The benefit is simple, write once run it everywhere. Oh wait, is that trademarked by Java? Or is their slogan Write Once, Debug Everywhere?
I know very well why I would want cross platform development, it doesn't take a genius to figure it out.
The benefit is simple, write once run it everywhere. Oh wait, is that trademarked by Java? Or is their slogan Write Once, Debug Everywhere?
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.
- 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.
> I would imagine that on the Android side of things are also not that different.
You would indeed imagine that, but the reality is less rosy.
1) Android is stuck on an off-brand Java stack that makes desktop Java seem pleasant by comparison. They are finally starting to make headway on replacing this with Kotlin, but most shops are still heavily invested in Java.
2) Android's UI framework is a weird hybrid of legacy and modern controls, and it only fairly recently that it has been capable of accomplishing things like a long scrolling list without memory/performance headaches. Before that everyone had to use 3rd party controls for complex or performance critical apps.
4) A lot of time spent setting up toolchains, SDKs, etc. God forbid your project incorporates C++ dependencies.
6) Google may provide Android itself, but each chip vendor then layers on their own special sauce, and finally each handset vendor layers on ever more special sauce. Add to that the historically abysmal adoption rate of new versions of android (and many vendors not providing upgraded OS versions for their older hardware), and the odds of being able to use a newly-released Google feaure/API are... not good.
You would indeed imagine that, but the reality is less rosy.
1) Android is stuck on an off-brand Java stack that makes desktop Java seem pleasant by comparison. They are finally starting to make headway on replacing this with Kotlin, but most shops are still heavily invested in Java.
2) Android's UI framework is a weird hybrid of legacy and modern controls, and it only fairly recently that it has been capable of accomplishing things like a long scrolling list without memory/performance headaches. Before that everyone had to use 3rd party controls for complex or performance critical apps.
4) A lot of time spent setting up toolchains, SDKs, etc. God forbid your project incorporates C++ dependencies.
6) Google may provide Android itself, but each chip vendor then layers on their own special sauce, and finally each handset vendor layers on ever more special sauce. Add to that the historically abysmal adoption rate of new versions of android (and many vendors not providing upgraded OS versions for their older hardware), and the odds of being able to use a newly-released Google feaure/API are... not good.
As other people say, something like 10% more effort to reach 2 platforms rather than a single one.
But _also_ (and that's no small deal), these cross platform framework often benefit from a huge skill transferability from web development, eg React Native or Vue Native. This is a massive deal, it means you can get a web dev to be productive on a mobile app pretty much immediately (and potentially you use the same technology as for your web app, which itself is also a big deal)
But _also_ (and that's no small deal), these cross platform framework often benefit from a huge skill transferability from web development, eg React Native or Vue Native. This is a massive deal, it means you can get a web dev to be productive on a mobile app pretty much immediately (and potentially you use the same technology as for your web app, which itself is also a big deal)
In theory just just write code once and have the app ran on both platforms. In practice it's much more complicated, and whenever you need to do more than the framework offers your situation is much more complicated than in the case of native development. Also some features are implemented in different ways on both platforms and you need to get into details anyway. So being familiar with native APIs is a great advantage even if you use the cross-platform approach.
Depending on what the app does, developing a single native app is probably faster, more performant and easier than going with something like Xamarin, React Native, or a browser-based application wrapped in a native app.
That said, browser based apps make a lot of sense when your app is client-server application and don't need a lot of device-level functionality. This is especially true if your app needs to be a web app, mobile app and desktop app.
That said, browser based apps make a lot of sense when your app is client-server application and don't need a lot of device-level functionality. This is especially true if your app needs to be a web app, mobile app and desktop app.
Swift has the slowest compiler I have ever had the misfortune of using. The dev iteration cycle was unbearable for me in a Swift project the I inherited.
SwiftUI and Previews sort-of address this now but it's not really ready yet, Swift compiler is still slow as molasses though and SwiftUI itself seems to bring the compiler to it's knees sometimes (on a brand new M1 Mini). It will flat out stop type checking anything that it deems to complex so you end changing code to appeal the compiler sometimes.
I like not having to learn Swift or dust off my 15-years-ago Java.
I can build stuff the same way on a Thursday for mobile that I do on a Tuesday for web.
I can build stuff the same way on a Thursday for mobile that I do on a Tuesday for web.
> 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.
This seems like you have very low standards for what is good.
This seems like you have very low standards for what is good.
Please educate me, what is good? What I am missing out on?
I'm no stranger to Web tech, including JS on the browser and on the server side. It's hell compared to native App development using the native technologies.
I mean, it's so bad that the tutorials explaining the project setup phase can be hours long to follow. Scripts running in the background just to keep you in check and let you write more readable code that is no where as good as Swift(linter, transcompilers, packers oh god >:( ).
When Xcode misbehaves, I would clean the build folder or restart it and everything is back to normal.
It has been a few years since I did something for the web but please let me know if you have a magical IDE or a script or something that lets you do work on you actual code with no janitorial work. Did JS world become considerably better in the last years? Did npm swamp dried out?
I'm no stranger to Web tech, including JS on the browser and on the server side. It's hell compared to native App development using the native technologies.
I mean, it's so bad that the tutorials explaining the project setup phase can be hours long to follow. Scripts running in the background just to keep you in check and let you write more readable code that is no where as good as Swift(linter, transcompilers, packers oh god >:( ).
When Xcode misbehaves, I would clean the build folder or restart it and everything is back to normal.
It has been a few years since I did something for the web but please let me know if you have a magical IDE or a script or something that lets you do work on you actual code with no janitorial work. Did JS world become considerably better in the last years? Did npm swamp dried out?
>I'm no stranger to Web tech, including JS on the browser and on the server side. It's hell compared to native App development using the native technologies.
As a front-end developer, it's clear to me that you only think that because you are familiar with it, same for me with js - all you need to start developing is npx create-react-app appname or npx create-next-app appname. I toyed around with react native too, and expo is godsend. On the other hand when I tried to use swift/xcode I quickly discovered that official docs are just trash for people unfamiliar with it and community is so much smaller (I was only looking at swiftui FWIW). You have to configure things like dependencies with xcode ui while in js it's all code. Needless to say I didn't go through with it and will go react native next time without a second thought.
As a front-end developer, it's clear to me that you only think that because you are familiar with it, same for me with js - all you need to start developing is npx create-react-app appname or npx create-next-app appname. I toyed around with react native too, and expo is godsend. On the other hand when I tried to use swift/xcode I quickly discovered that official docs are just trash for people unfamiliar with it and community is so much smaller (I was only looking at swiftui FWIW). You have to configure things like dependencies with xcode ui while in js it's all code. Needless to say I didn't go through with it and will go react native next time without a second thought.
> Please educate me, what is good? What I am missing out on?
For me, it's that you're talking about the flaws which means they're considerable.
For me, it's that you're talking about the flaws which means they're considerable.
Considerable? I don’t know, every few days I would need to restart Xcode. No big deal, really. It’s two clicks to close the app, one to launch it again but it’s annoying nevertheless.
> Considerable? I don’t know, every few days I would need to restart Xcode. No big deal, really. It’s two clicks to close the app, one to launch it again but it’s annoying nevertheless.
You literally considered it while writing your list. Therefore literally considerable.
You literally considered it while writing your list. Therefore literally considerable.
> 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...
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...
Looks like the project is seeing very little in terms of contributions of late: https://github.com/GeekyAnts/vue-native-core/graphs/contribu...
Definitely slow
Just did a deep dive with a group of devs with vue native, nativescript, ionic and more for building a mobile app in vue.
We all enjoy building in vue and we're looking to extend that to mobile. However in almost all cases, there were shortcomings and a lack of maturity in support compared to react or angular. A lot of time wasted.
Generally, Vue is not a first class citizen in these environments. Yet.
Vue Native began with a lot of promise and excitement. Documentation is ultimately sparse and examples either don't exist or are out of date. Compiling the same code on Mac or windows yielded inconsistent build results. Debugging doesn't have much research that is possible. Sometimes you have to compile 4 or 5 times. Still seems early.. Or not developing as quickly as other options. Doesn't seem updated often.
Nativescript was next, looked very inviting and welcoming, but trying to reproduce the same resulted in a fair number of issues. It seems nativescript has less of a history with vue than react. Noted the documentation is deeper for other frameworks. Seems to be evolving for vue. Pass for now and check again in 6 to 12 months for progress.
Last, but not least, ionic. Right off the bat likely the deepest documentation. It had 2 approaches.. Package a vue.js app for mobile, or use capacitor to try and build more of a native experience. Capacitor is relatively new for vue.js and still maturing. Ran into similar issues as the others. Didn't seem ready for production than using angular or react with ionic or capacitor. Vue supports in ionic are thinner than angular for sure and seemingly react.
For now, it was possible to build a vue web app to do what's needed and add ionic to simply package it. No capacitor.
It pains a little to say this, but if we were building a more complex app, the react native tooling is what we'd have to consider. It's far more mature and nearly every problem we encountered had a result of how to resolve it in react native.
We all enjoy building in vue and we're looking to extend that to mobile. However in almost all cases, there were shortcomings and a lack of maturity in support compared to react or angular. A lot of time wasted.
Generally, Vue is not a first class citizen in these environments. Yet.
Vue Native began with a lot of promise and excitement. Documentation is ultimately sparse and examples either don't exist or are out of date. Compiling the same code on Mac or windows yielded inconsistent build results. Debugging doesn't have much research that is possible. Sometimes you have to compile 4 or 5 times. Still seems early.. Or not developing as quickly as other options. Doesn't seem updated often.
Nativescript was next, looked very inviting and welcoming, but trying to reproduce the same resulted in a fair number of issues. It seems nativescript has less of a history with vue than react. Noted the documentation is deeper for other frameworks. Seems to be evolving for vue. Pass for now and check again in 6 to 12 months for progress.
Last, but not least, ionic. Right off the bat likely the deepest documentation. It had 2 approaches.. Package a vue.js app for mobile, or use capacitor to try and build more of a native experience. Capacitor is relatively new for vue.js and still maturing. Ran into similar issues as the others. Didn't seem ready for production than using angular or react with ionic or capacitor. Vue supports in ionic are thinner than angular for sure and seemingly react.
For now, it was possible to build a vue web app to do what's needed and add ionic to simply package it. No capacitor.
It pains a little to say this, but if we were building a more complex app, the react native tooling is what we'd have to consider. It's far more mature and nearly every problem we encountered had a result of how to resolve it in react native.
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.
I have a large Flutter codebase and I don't have the same opinion, Flutter web is still an alpha quality and it would take way too much work to make my codebase work with the web version. For desktop though, it's pretty good.
I've built a new Flutter web app this week and I've hit some gotchas like improper rendering of text form fields (SVG flags were incorrectly set when displaying on the web, regardless of HTML or Canvas rendering it seems). However, Google engineers are actively working on problems like these and it seems like the dev branch is fairly stable and usable as of right now. I'd say 30 days ago it would not have been the case.
Have you by any chance also evaluated / considered https://platform.uno/ ? If so, I am interested in your take on it versus Flutter.
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.
* 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..
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..
If the creator wants an ad there, let him put an ad there or just simply stop using the app.
Ok, what about the vision impaired? Or any other point I mentioned?
I didn't know about this. Is Flutter web ignoring accessibility when rendering to HTML? If so that is a no no.
Last time they rendered everything into a canvas. The initial plan was to render DOM elements on the web (the other platforms are essentially canvases, so it was the easiest to implement).
I don’t know the current state of Flutter, please don’t judge it based on my comment alone! But do look out for it, and perhaps also cross-browser usability. Yet again, I write about an older version, but under Firefox the demo Flutter apps were insanely slow (much more than under chrome)
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.
I was using Cordova with VUE.js and had fantastic results in both iOs and Android, using "Buefy" as my UI framework.
I started with Nativescript and ended up in building a WebView which I then simply included.
I haven't tested Vue Native yet but wanted to know why Cordova seems to be on the decrease :( I feel like I have to develop in Vue Native or Nativescript soon to not lose track. However, I always liked the Cordova/Vue combination and I could realise fantastic apps with it.
I started with Nativescript and ended up in building a WebView which I then simply included.
I haven't tested Vue Native yet but wanted to know why Cordova seems to be on the decrease :( I feel like I have to develop in Vue Native or Nativescript soon to not lose track. However, I always liked the Cordova/Vue combination and I could realise fantastic apps with it.
honestly, not sure about this either. Cordova works great without having to support two separate codebases for your views, which is what we all want. Vue Native, while sporting a nice HTML syntax, is just wrapping native components, which means you have to write your app specifically for native.
I’ve been putting off switching my native apps to cross-platform simply because I’m too busy to learn react, so it’s great to see that vue is finally an option.
Of course it’s probably a little too soon to completely switch live apps to this, at least until it stabilizes a little bit.
Edit: never realized this existed for the past two years and is simply a wrapper for react native.. any reason it’s being posted now?
Of course it’s probably a little too soon to completely switch live apps to this, at least until it stabilizes a little bit.
Edit: never realized this existed for the past two years and is simply a wrapper for react native.. any reason it’s being posted now?
Ionic and quasar already allow you to make Vue on smartphones
Shoutout for Framework7. I built a test app in both Ionic and Framework7 and vastly enjoyed the experience of F7 over Ionic.
For Ionic Vue is still in beta, poorly documented and had some vague errors with obtuse solutions. It didn't have all the components you might want in an app either, so less boiler plate.
Framework7 has full Vue documentation, and the handful of components that aren't Vueified (Calendar, Toasts) are easily integrated using native JS and the this.$f7 helper.
Their creator is highly active and responds to almost all (non-idiot) questions on their forum.
Downsides of F7: no SCSS but CSS variables which clutters the inspector, a lot. You can always overwrite these with a scss file but the variables are always there.
For Ionic Vue is still in beta, poorly documented and had some vague errors with obtuse solutions. It didn't have all the components you might want in an app either, so less boiler plate.
Framework7 has full Vue documentation, and the handful of components that aren't Vueified (Calendar, Toasts) are easily integrated using native JS and the this.$f7 helper.
Their creator is highly active and responds to almost all (non-idiot) questions on their forum.
Downsides of F7: no SCSS but CSS variables which clutters the inspector, a lot. You can always overwrite these with a scss file but the variables are always there.
Ionic vue is no longer in beta, though it will take ~a year before it reach full parity support vs other VDOMs
I stand corrected, thank you :)
https://ionicframework.com/blog/announcing-ionic-vue/
Will give it another spin. Because UI wise, it was faster.
https://ionicframework.com/blog/announcing-ionic-vue/
Will give it another spin. Because UI wise, it was faster.
Quasar and Ionic aren’t native though. They give you the JS app in a browser packaged into an app. React/Vue native give you a real native byte code app.
Ionic capacitor seamlessly integrate with native plugins and you can write your own.
Btw the react native js engine is much slower than the one on Ionic, at least on IOS.
Ionic screwed me like a deck screw with their update path being more of a secret way into Mordor. Perfectly good app that can’t be compiled anymore without a full rewrite in what is effectively a completely different framework.
You had to upgrade from which version to which one?
I initially used it with version 1/Angular 1.x. Then when Angular 2 was basically a complete rewrite from scratch Ionic did the same. For a little bit I was still able to compile the code but quickly their tools became unavailable and unusable.
You were very early in the history of Ionic, I understand you :( but such breaking change should not happen anymore at this scale
It's true. But also I consider Angular 2+ to be inferior to other similar frameworks. It was overengineered to no end had as much to do with Angular 1.x as a space shuttle has to do with a horse buggy. I remember looking at how they proposed to specify templates via `` template strings as part of the JS code, making their template language completely unreadable and thinking how that's such a step back in usability compared to how Angular 1.x did it, which was basically what Vue.js does.
And I do still have some scars that haven't fully healed from that transition. Look at Vue's evolution from 1.x to 2.x to 3.x. The new way to create components in Vue 3 is what Douglas Crockford proposed way back in like 2008. Except it's reasonably worse for code readability compared to Vue 2.x because it is completely unstructured. And at one point the Vue team was talking about taking out half the features that I routinely use in Vue 2.x such as $emit()/$on(), watchers, etc.
I don't have as much experience with React, but from what I understand they break compatibility much more frequently than Vue does. Plus, JSX is a very polarizing tech and I am firmly on the side that dislikes it.
Compare all of the above with a project like Django where backwards compatibility is maintained for years and developers consider it a big cost to break features. It's a much more carefully developed project and it makes running the code much easier. The template syntax has not changed in what, 10 years at least? In the meantime how many JS frameworks have we seen rise and fall? As far as I am concerned, every time a framework or library update breaks my application, the framework is imposing a cost on me. Adding new features and refining existing features? Fine. Breaking the world because someone didn't like how $emit()/$on() worked? That's like if the Linux kernel decided tomorrow to switch to using Windows syscalls because they got a Windows developer on the team.
And I do still have some scars that haven't fully healed from that transition. Look at Vue's evolution from 1.x to 2.x to 3.x. The new way to create components in Vue 3 is what Douglas Crockford proposed way back in like 2008. Except it's reasonably worse for code readability compared to Vue 2.x because it is completely unstructured. And at one point the Vue team was talking about taking out half the features that I routinely use in Vue 2.x such as $emit()/$on(), watchers, etc.
I don't have as much experience with React, but from what I understand they break compatibility much more frequently than Vue does. Plus, JSX is a very polarizing tech and I am firmly on the side that dislikes it.
Compare all of the above with a project like Django where backwards compatibility is maintained for years and developers consider it a big cost to break features. It's a much more carefully developed project and it makes running the code much easier. The template syntax has not changed in what, 10 years at least? In the meantime how many JS frameworks have we seen rise and fall? As far as I am concerned, every time a framework or library update breaks my application, the framework is imposing a cost on me. Adding new features and refining existing features? Fine. Breaking the world because someone didn't like how $emit()/$on() worked? That's like if the Linux kernel decided tomorrow to switch to using Windows syscalls because they got a Windows developer on the team.
FYI - NativeScript has had Vue support for a few years now and is production ready (in my limited experience).
Don't know now it compares to this though.
Don't know now it compares to this though.
NativeScript unfortunately just can't compare with React Native in my experience. I've been a Vue dev/consultant for several years, I wanted to love NativeScript, but every single time I try to build something with it (last attempt was about 2 weeks ago) I come across a missing feature and end up begrudgingly switching to React Native.
Could you give a couple examples of such missing features?
If your goal is to actually put out high-quality apps, do not switch away from doing them natively. No cross-platform kit can compete. You are making sacrifices, sometimes big ones, in order to get the cross-platformness.
I've thought a lot about this. My biggest problem is that I'm the only one maintaining the project, and using something like vue + cross-platform would make things a lot easier than maintaining 3 different code bases (ios, android, web).
My understanding is that cross-platform tools have matured enough to be used as replacements to native implementations. Is that not the case?
My understanding is that cross-platform tools have matured enough to be used as replacements to native implementations. Is that not the case?
From the (limited) work I've done building React Native app's.. In most cases, the user is not going to be able to tell any difference from a native app.
For simple apps, you can get away with it.
If you are aiming for more than the basics, you'll run into trouble or impassable roadblocks.
If you are aiming for more than the basics, you'll run into trouble or impassable roadblocks.
is there any project that would us the same js - native bridge as react native, except with wasm.
The idea would be to let us write cross-platform business level code in any language targeting wasm, while using a native UI framework
The idea would be to let us write cross-platform business level code in any language targeting wasm, while using a native UI framework
Not exactly the implementation you described but Kotlin Multiplatform is targeting this workflow. Shared business logic in Kotlin and Native UI on each platform. You can currently compile to iOS/Android/Web and Desktops. I imagine the could support wasm at some point too.
Edit: Kotlin Multiplatform not Kotlin Native
Edit: Kotlin Multiplatform not Kotlin Native
I think you meant Kotlin Multiplatform: https://kotlinlang.org/docs/reference/mpp-intro.html. Kotlin/Native is a LLVM-based backend which is used in case of Kotlin Multiplatform for iOS part.
I absolutely did! thanks. Regarding OPs point I just double checked and it does indeed support WASM as a target now.
kotlin multiplatform looks nice, but my idea of using wasm is to support any PL able to target wasm (and the number seems to grow every day)
Two way data binding tends to obscure the rendering process and add a lot of "black box" side effects, which in browser based applications leads to serious performance issues that bog things down at scale. I would like to know how they're going to avoid this.
While this is nice, for mobile -- and even desktop -- apps I find hybrid/electron to be a far more compelling use case. On mobile, if you're stuck in a situation where you need the full power and speed of vendor native then, if you're using Ionic Capacitor, you can spin up an Activity/UIView and code that part in Java or Kotlin for Android and Swift or Obj-C for iOS (or C++ for both if you really want to). Do everything in HTML,CSS,JS that you can and only use the heavy duty tools where absolutely necessary... and the truth is, they aren't nearly as necessary as they used to be.
To be honest, I don't see any reason not to use Flutter if you want to make a cross-platform app these days. Any other cross-platform framework I tried seemed somehow lacking, slow, unpleasant to use etc.
I use to frown upon cross-platform js solutions until I built a cross platform app. While the initial app building part was no problem, packaging them for various platforms (macos, windows) was pure h*l.
I would honestly throw entire salary on this if its built in the direction it claims. Only downside for Vue Developers would be to switch between frameworks(React Native) to develop a native app.
React native is a fantastic project. I wonder if they could make it framework agnostic, so other js frameworks can use it directly
Archive updated today:
http://web.archive.org/web/20210127141756/https://vue-native...
(If you also get error visiting the page now)
Yeah I dunno, react native is a neat idea, in practice it was all pain all the time. Updating, debugging, building, ensuring it worked on all devices, then add in something like Bluetooth LE and the pain grew even more.
Would have been easier to create two apps in their native platforms.
Would have been easier to create two apps in their native platforms.
[svelte-native ain't far?]
Svelte compilations work in Sciter.JS ( https://github.com/c-smile/sciter-js-sdk ) as they are.
And Sciter.JS is an embeddable UI engine for native applications so you probably don't need dedicated svelte-native at all.
For that matter Sciter.JS already allows to build native Mithril.JS and PReact.JS applications too.
And Sciter.JS is an embeddable UI engine for native applications so you probably don't need dedicated svelte-native at all.
For that matter Sciter.JS already allows to build native Mithril.JS and PReact.JS applications too.
This is what I am interested in. Looking forward to it
Lots of comments on HTML/CSS being hard or non optimal but learning to use things like grid (grid template areas plus designing first for mobile) and flex together really allow all sorts of layouts one would create.
Maybe I just wasnt giving it my full devotion but I spent a day or two just trying to get Vue Native up and running late last year and no success. Maybe if I had more Reactive Native knowledge it would have been easier.
whats the down side of plopping your vue app into a webview then making interfaces to call kotlin code from vuejs?
thats what I've been doing to rapids app prototyping...
thats what I've been doing to rapids app prototyping...
Currently down due to hug of Death HN (Error 522 Ray ID: 6182f97eb9cb3bfb • 2021-01-27 13:56:00 UTC
Connection timed out)
I see:
- "react": "^15.5.4",
- "react-dom": "^15.5.4"
as npm dependencies.
Dumb question - why does it need react as dependencies?
- "react": "^15.5.4",
- "react-dom": "^15.5.4"
as npm dependencies.
Dumb question - why does it need react as dependencies?
2018 should be in the title
[deleted]
Furthermore, MVC is, when done correctly, a sane two way data-GUI binding. However, I have never seen a sane implementation ;-)