Svelte Native | Hacker News Reader

Svelte Native

svelte-native.technology

177 pointsthunderbong79 comments

Whatever the merits of this project -- and it does seem to be useful -- they should be a little clearer about the fact that it's not actually part of the "official" svelte framework.

I'm sure they consider it a tribute but it fees a little deceptive that they're cloning the svelte docs look and feel without any kind of "who we are" statement.

Back when Svelte Native was created it was pretty much endores by the maintainers, there's even a channel for it on the official Svelte Discord :)

Moreover, it was made by one of the folks who brought TypeScript support to Svelte (https://github.com/halfnelson/svelte2tsx), so although it may not be explicitly pushed by the core team, it was still made by a significant core contributor.

I'll note that React is the only web renderer that gives official blessing to a native framework, and that's because it's also the only web renderer that built one themselves rather than leaving it to the community.

100% agree

Not sure if this is new but the docs start with a pretty strong disclaimer: https://svelte-native.technology/docs#important-note

I’ve done a couple React Native apps and never again. They’re fine at first but if you let one sit for a few months there is a combinatorial explosion of complexity among shifting incompatibilities of different versions of javascript libraries, the framework, android/iOS versions, build systems, etc. it becomes a nightmare. I’d much rather just learn Kotlin/Swift and have only one ecosystem to maintain.

At the time I used it, it was almost worth it just to use RN for Android even if you did iOS in Swift, just because styling on Android was so hellish ("There must be some non-crazy way to set a default typeface for my app. Right?" LOL wrong; "setting this color on this Material input field must be easy" LOL nope, welcome to Java metaprogramming just to set a goddamn color), the documentation-suggested way to structure apps was so bad that you'd be reaching for other solutions anyway if you valued your sanity (I wanna say Square was at the forefront, here? It was some company like that. Like your best bet was just to find their libraries and blog posts and do exactly what they did, ignore the official docs), and in some cases the native libraries for Google APIs were less-capable than the Javascript ones anyway (Maps was one, I remember—god, what a surprise that was to find out).

But that was like 5 years ago so maybe it's gotten better.

I agree with you. RN still sucks on some aspects, but it's quite an amazing technology and I'm grateful it exists.

Nah, among cross-platform, RN has stagnated while Flutter has sped past.

The key issue I see these days is that it's just not worth it to build a mobile app these days unless your payment flow happens outside of the app.

I had bad experiences with it 7 years ago, but really good experiences with it recently. If you stick to native modules managed by expo you'll be in a great place! You can run into dependency hell if you use a random react-native npm module that was last updated 5 years ago.

I think most users would prefer an RN app over a Flutter app, especially on iOS, because the RN app will feel much more native because it renders using native views, instead of a Skia framebuffer.

> it's just not worth it to build a mobile app these days unless your payment flow happens outside of the app

not true at all, 85% of something is better than 100% of nothing. This is coming from someone who hates mobile apps and apple's grip on them

Although I haven't used it, Jetpack Compose exists now, so that and SwiftUI are pretty similar. On a previous project I was contracting on, the CTO managed to bash out a basic Android version of the iOS app I was working on without any Kotlin experience by going through the SwiftUI views one by one and implementing them in Jetpack Compose.

We recently threw out our React Native app and have gone all in on PWAs.

TWA as well? Because I find, the app stores are good for discovery.

People should just use Ionic & Capacitor.

You can still use your React knowledge with it.

Capcitor with solid or marko would be better, more lightweight.

This is a very weird thing to say when expo is literally one line installation and it does not require you anything to be installed (even XCode) on machine for most projects. It is literally 10x times easier than just writing in Swift.

If you want to submit it to the app store you'll need to install XCode anyway to build it and submit it. Might as well just start there and have it configured right from the beginning.

No, you do not, you can use a free service by expo that would build in the cloud. Literally requires zero setup. Local build is needed only if you are sensitive to security, but many banks started to use it. Also native plugins became so easy to use it is a joke how simple it is comparing to cocoapods and some cryptic libraries.

Expo's workflow is so perfect comparing to pure native, it is not even comparable. To do iOS development you need: Swift Packages, Cocoapods and XCode at least. Whils in general it is simple, but cocoapods constantly fights with apple and xcode to not crash anything. While expo also uses cocoapods, it is much more stable because you can always just delete a native project and regenerate it from scratch and it will work.

I am not even starting to discuss how complicated is development for Android - literally everything now have 5+ different APIs for a simple things like "please encrypt this string" or "take a photo". React Native and Expo has perfect packages that solves real problems and work with a few keystrokes.

I'm glad it works for you. One thing I've learned from bitter experience is "don't swim upstream". Meaning, you're likely to have problems when you're using tech outside the way it was intended. Apple intends apps to be developed in Swift with XCode, so that's what they support and when they develop new features that's what they have in mind. They don't care about Expo and if they do something that breaks Expo or Flutter or any other third-party service, that's not their problem and they aren't going to do anything about it. Expo et al are always going to be second class citizens to Apple.

Cocoapods are on their way out. I use Swift Package Manager on new projects and it's literally a couple clicks to install whatever package you want. Haven't had any problems yet.

> It is literally 10x times easier than just writing in Swift.

I feel Swift as a language is a lot more productive than TS/JS personally. I've found things like React Native and Expo etc. more of a liability than a help for businesses that are heavily reliant on mobile.

If you don't need any native plugins other than those provided by Expo Go, then yes.

If you do need other libraries, or add native code yourself, the package system becomes a nightmare. It is NPM packages on top of Cocoapods on top of a XCode/Swift/Objective-C compile process. Only slightly better on Android.

Want to make a change to a library? Good luck getting linking working on your local setup.

Cordova had exactly the same issues. I'm not sure if Ionic Capacitor is better, but this is one area where Flutter is miles ahead.

in 2023 it is a one liner to add native modules, very easy to link via normal cocoapods or gradle, then almost zero configuration.

Flutter is a joke because it reimplements literally what apple intended to perfect - rendering pipeline, a lot of things impossible to make good without using native api.

When it works it's that simple. When it doesn't - perhaps because of some incompatibility between the native model and a recent Expo update, it's hours of debugging through the different layers to figure out what's going on. That's my experience starting a React Native project in 2023.

Flutter has issues with not using native UI, but I've found the package system with native modules to be way simpler and less issues. Unfortunately you're still stuck with Coacoapods though.

Really important to note, this isn’t react native, its NativeScript.

The two have some fundamental differences — React Native is complex because the React ecosystem is full of complexity. NativeScripts biggest problem is more ecosystem size.

Maybe it got better but when I was using RN, it felt fine at the first 3 months; then we found out that it is a hell to work with JS and React Native dependency. To the point we needed to forked multiple project to make it worked. And in the end, we still need a considerable native code for our app. It might just be better to start from scratch with native iOS/Android.

Writing a Windows app, MacOS app, Linux app, iOS app and Android app is a nightmare because of the insanity and divergence of the SDKs.

They could all have a common API with OS-specific extensions - but instead of that, everyone is trying to make their own API. As a result, developers just write everything in electron/WebKit/WebView.

I wish there was an open standard API for writing native desktop/mobile apps that OSes could adhere to (that the EU forces them to adhere to, haha).

I've seen Dart filling this gap for many apps lately

Yeah they did that multiple times already. One of them was Java/JVM. That was exactly how they pitched it in 1998

I suppose it's the execution that is important.

Given that GUI applications share a lot of aspects between platforms, I'd love to see an open "Vulcan"-like standard that defines a GUI API for native platforms.

OSes can interpret calls to that API such that the result looks congruent with the platform's design language - while the application code itself remains portable between platforms.

It's really not that hard to define, there's just no willingness to do so from OS vendors as it would erode their efforts to build walls around their platforms

POSIX became a standard because the US government needed software interoperability with their hardware. It wasn't enforced, but you'd miss out on the government contract lottery if you didn't adhere.

If we value competition in the OS space, it would be wise to support an initiative that would make the OS itself unimportant

I have a mobile app sitting around. Wrote it in 2020ish, Corona year. The mobile app is written in flutter and the server is in Go, you probably know by now where I'm heading with this.

I cannot even express how hellish and nightmare that whole flutter thing is: I'm worried about the engine itself (there were breaking changes in the typing system itself that I'd need to worry about), the libraries and packages to update. And not to even stop at the building (signing) stage with the whole ruby shenanigans that needs to match and work well with xcode.

Now compare that to go.

While I'm a huge Svelte fan, this project hasn't really gotten very much care and attention over the last few years.

Which is honestly fine. React and React Native I think do a much better job of filling the niche of people who want to build native apps with web tech.

That being said, I think with the progress that Safari has made in implementing PWA support, the increased hostility of Apple toward native developers, and browser improvements like WebGPU coming out soon, I really hope that we no longer have to build native apps for like 95% of use cases. The only major hurdle to this is Apple continuing to treat web apps as second class citizens on iOS and only begrudgingly adding APIs to Safari to make good native experiences.

> The only major hurdle to this is Apple continuing to treat web apps as second class citizens on iOS

If you add a site to iOS' homescreen it automatically becomes a PWA. The best example I found of a site fully leveraging this feature is Cryptee[0]. They talk about the PWA thing here: https://crypt.ee/download

[0] https://crypt.ee/

The whole add to home screen process is needlessly convoluted. It would be nice if there was something similar to Smart Banners for PWAs: https://developer.apple.com/documentation/webkit/promoting_a...

You just click "Share -> Add To Home Screen." I understand that that's technically more clicks than a smart banner but hardly "convoluted"

I think it's convoluted relative to a Smart Banner. Smart Banners give users a clear call to action, and they're not buried in a menu somewhere.

It's hard to make this point without linking to a screenshot, but the share menu is incredibly bloated. To get to the add to home screen button a user has to know it's in the share menu (which is just an unlabeled icon), and then scroll past the following menu items:

- An options button (which leads to another menu)

- Air Drop

- Share via text message (with several different contacts listed individually to share with)

- Copy

- Add to Reading List

- Add Bookmark

- Add to Favorites

- Add to Quick Note

- Find on Page

Adding to your own home screen under a "share" menu is something probably 90% of users would never think of.

Fastmail does this too, and it works extremely well.

I agree it's MUCH better than it used to be (and huge credit to Jen Simmons and her team for making this possible). However Safari APIs are still WAY behind Chrome/Android and I think this is probably intentional to push developers into using the App Store so Apple can collect their 30% tax

https://fugu-tracker.web.app/

It's absolutely intentional, but going to slowly get better even as they drag their feet

i wonder when someone is going to sue apple over this absurd limit. There's 0 justification for it, it's almost the definition of racket.

We've been working with Capacitor recently which is the current iteration of webview-to-native. Basically you just build a website and run it through a compile step to output iOS and Android. The ergonomics of the build process and integration with native features is definitely a bit lumpy, but we've been very successful at building an all-in-one codebase that will power web, ios and android with minimal drift.

Not sure what you built but for anyone interested in going down this venue there's a blog post by a Svelte Ambassador that you can read here: https://khromov.se/how-i-published-a-gratitude-journaling-ap...

Capacitor is great! Did Svelte + Capacitor for my last app. Highly recommend.

> increased hostility of Apple toward native developers

Chortle.

My company tried using this a few years ago to build a cross platform app (and hopefully share a lot of code with our svelte web interface). We made a lot of progress in 3-4 months of trying, but we ended up running into too many odd bugs and edge cases that were difficult to debug. We eventually switched to Flutter for the mobile codebase.

No doubt this and nativescript have improved since then, but from my early impressions, I wouldn't have recommended nativescript for anything other than the simplest of interface needs.

This is the story I’ve heard about almost every react native project.

Get to proof of concept 10x faster. Spend 10x more time in the weeds on weird bugs.

NativeScript is not react-native

Also the old Cordova equivalent and Kivy. Take mobile development and try to shoehorn a browser-based solution (they don't want) into it. Now you've got two problems and not enough expertise available to help.

Did they have JS _AND_ React experience beforehand? Or did they just pick RN because it was the cool thing on the block?

I foundered on my first attempt at an React app (side project) coming from a C,C++,Java and non-React JS background, but the second one(professionally) after I've had exposure to some React got released and an fork of it is still in use today. And the company I work with has 2-5 other apps out for customers using RN/Expo (thanks to the positive experience I had).

We're also strict about using TypeScript though so we're not chasing basic type bugs (since debugging is a tad weaker with RN/Expo even if it's usable if shit the fan only occasionally) and we have plenty of React experience outside of it, biggest "quirks" are often RN/Expo upgrades if we haven't maintained things in a while (the oldest app used a relatively early version of Expo though) or platform specific notification crap (that I've heard is painful regardless of Expo/RN).

How has Flutter compared in your experience?

This is not so much the Svelte equivalent of React Native as it is just one of the wrappers for NativeScript (https://nativescript.org).

Hell no. It’s better to stick with RN if you want cross platform. Writing an app in Kotlin and Swift is easier compared to this contraption.

Native is such an abused word.

True. I think the intent here is "we translate your stuff into non-webviews" which is... pretty much what native means in a mobile context.

They're making native calls.. Either through message passing, or through creating stubs.

You can literally use all of the iOS SDK directly.

Not sure why I'm downvoted.. https://old.nativescript.org/native-api-access/

It's the basis of their entire product. On top of that they've built cross-platform wrapper for many UI things. And on top of that, they've integrated several toolkits.

They just market it the other way around, which i.m.o. is not helping them with traction. Right now they're always competing with many other products (react native for example), even though they have a very unique product.

The example app is 5 years old. Is anybody using this?

It's being used here: https://github.com/Akylas/OSS-DocumentScanner

I have built many mobile apps in the last years. I always used web technologies rendered inside webviews, using tools like capacitorjs.

Since I am very concerned with user experience, I always considered the perceivable UI rendering performance as highly important. For contemporary smartphones I cannot see any benefit in using tools like react native, flutter, nativescript in contrast to rendering inside a webview.

I think UI libraries like ionic are indistinguishable from native UI components. At least, to the best of my knowledge, there is no real user study, which proves the contrary. So why should one use such cross-platform tools and not use svelte directly with a webview?

Have you experienced slow scrolling issues?

https://github.com/ionic-team/capacitor/issues/4187

I very much doubt Ionic is visually indistinguishable from native UI components, but I'd love to try if you have a good demo link.

My guess is it crosses a "good-enough" threshold for usability, and it feels objective, ex. maybe scroll performance is the same.

I strongly believe users notice things feeling "off" in a way that's either subconcious or hard to communicate, and that's why it matters.

The reason why I use Flutter instead of JS is for a number of reasons beyond perf / native controls. The shortest version is iOS / Safari makes web apps extremely obviously a worse version of a native app.

But I'm picky.

I just upgraded macOS and got a "you must accept new T&C" dialog. Accidentally scrolled on it vertically. It did the rubberband effect showing a white background, and I said to myself: "lo, how the mighty Apple has fallen!"

Super, I love Svelte and I hope its unique component model fits well for the native mobile app development.

Is the tool chain very different from React native?

It is. This is mostly a Svelte wrapper around NativeScript so it's really not equivalent

Why does NativeScript seem so much worse than React Native?

Funding? Plugin ecosystem like Expo modules? Or maybe use both?

https://blog.nativescript.org/nativescript-with-react-native...

https://twitter.com/wwwalkerrun/status/1700719038392078607

Then throw in some SwiftUI too

https://twitter.com/NativeScript/status/1624895622540328961

Because they run JS on main thread while react native tries to minimise it at all costs (only keeping rendering and animations, but not layouts for example).

I think if you're starting today you'd be better off with Tauri (and Svelte as the framework)?

Tauri Mobile seems far from production-ready, but more importantly, the reason to use something like Svelte Native instead of Tauri Mobile is to avoid web views in favor of a platform-native experience.

I would rather stick to either pure mobile Web, or native views + C++, but that is me.

No added tooling, only the SDKs from each platform, no late nights debugging integration layers, lack of support on IDEs,...

SDKs for 4+ platforms is added tooling...

It is when it represents debugging the same code 4+ times.

That is the fallacy of all these leaky abstractions, the need to actually know the native APIs from each platform doesn't go away.

Someone needs to take care of integration problems.

Yes. Want to ship on N platforms, with the cross platform lib now you need to know N+1 platforms.

An alternative I’ve been enjoying is @tommertom’s Ionic port (+ Capacitor) for native integration: https://github.com/Tommertom/svelte-ionic-app

Is the goal here to reach a minimum subset of basic Android UI functionality? I don't see any push to try and replicate a MD3 feature-set here for example.

Yuck nativescript

Docs returned 404

Reply on news.ycombinator.com