Vue Native (2018)
vue-native.io
vue-native.io
Furthermore, MVC is, when done correctly, a sane two way data-GUI binding. However, I have never seen a sane implementation ;-)
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
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.
I'm honestly amazed some (especially undo!) were shrugged away so easily.
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?
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
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...
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.
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'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.
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.
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.
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.
ok I admit defeat on this. I can't barely believe I forgot that u_u;
Microsoft, FreeBSD, ARM collaboration on CHERI
https://msrc-blog.microsoft.com/2020/10/14/security-analysis...
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...
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.
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.
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.
It’s reaping so much benefit that these experts can easily make mobile apps without learning another way to describe UI.
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.
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.
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...
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.
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.
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.
It's not dead though - C# development still has Visual Studio and it can be pretty good.
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.
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, ...
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.
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.
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".
Much of this conversation seems to consist of "the popular solution to this insanely complex problem is hard! Why isn't it trivially easy!?"
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
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.
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?
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.
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.
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.
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.
[1]: https://github.com/GeekyAnts/vue-native-core says as much.
Pretty valuable actually.
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.
Performance is roughly the same and you have access to most of the platform features that most apps need.
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.
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.
RN, never again.
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.
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 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?
This seems like you have very low standards for what is good.
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?
For me, it's that you're talking about the flaws which means they're considerable.
You literally considered it while writing your list. Therefore literally considerable.
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.
I can build stuff the same way on a Thursday for mobile that I do on a Tuesday for web.
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 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.
"...my team is pioneering React Native development..."
React Native has been around for 5 or so years.
React DOM is very coupled with DOM elements, so React Native Web abstracts away web-specific things, so that code is more sharable.
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.
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.
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)
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...
- 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.
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.
* closed source
* requires ag extra plugin to render
* slow
* fake sandbox that had too many bugs
Flutter has none of these.
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..
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.
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?
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.
https://ionicframework.com/blog/announcing-ionic-vue/
Will give it another spin. Because UI wise, it was faster.
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.
Don't know now it compares to this though.
My understanding is that cross-platform tools have matured enough to be used as replacements to native implementations. Is that not the case?
If you are aiming for more than the basics, you'll run into trouble or impassable roadblocks.
The idea would be to let us write cross-platform business level code in any language targeting wasm, while using a native UI framework
Edit: Kotlin Multiplatform not Kotlin Native
Would have been easier to create two apps in their native platforms.
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.
thats what I've been doing to rapids app prototyping...
- "react": "^15.5.4",
- "react-dom": "^15.5.4"
as npm dependencies.
Dumb question - why does it need react as dependencies?