Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

License #16

Open
aehlke opened this issue Jun 28, 2023 · 4 comments
Open

License #16

aehlke opened this issue Jun 28, 2023 · 4 comments

Comments

@aehlke
Copy link

aehlke commented Jun 28, 2023

LGPL is workable but I would suggest also making this available as MIT or the like, thanks.

@danpalmer
Copy link

@aehlke (not the maintainer, but) do you have any specific use-cases for this that aren't allowed under the LGPL, but are under MIT? The licencing seems fine as is to me.

The only material difference, if I understand correctly, is that you are required to share modifications you make to JXKit itself, which is pretty much good open source practice anyway.

@aehlke
Copy link
Author

aehlke commented Jul 1, 2023

I think LGPL is questionable in App Store - there are requirements around users being able to swap out the LGPL module with another one. I'm not using this project anymore though as I realized JSContext is like 10-20x slower than WKEWebView JS execution/ Thanks

@marcprux
Copy link
Member

marcprux commented Jul 1, 2023

I think LGPL is questionable in App Store - there are requirements around users being able to swap out the LGPL module with another one.

JavaScriptCore itself is LGPL, so it only makes sense that JXKit use the same license. Millions of apps use JavaScriptCore directly, so clearly linking to an LGPL library does not present any issue for App Store apps. If you have any evidence to the contrary, please share.

I'm not using this project anymore though as I realized JSContext is like 10-20x slower than WKEWebView JS execution/ Thanks

That's a known shortcoming of any app that uses JavaScriptCore: as a matter of policy, apps are not permitted to perform Just-in-Time (JIT) compilation, which can be crippling to the performance of code that benefits from dynamic compilation.

While calling out to a WKWebView does indeed a workaround this contrived limitation – since it executed the JS in a separate (specially entitled) process – it has the downside that all communication needs to be async and you cannot share memory or bind function implementation between JS and Swift (which is JXKit's major value proposition). But if you have large chunks of JS that you can execute asynchronously and in isolation, WKWebView is a good (and potentially higher-performance) way to accomplish this.

@danpalmer
Copy link

@marcprux great points, thanks!

It should be noted that while WKWebView might be better for many apps on Apple platforms, it's not suitable for cross-platform code that needs to work on, say, Linux. I'm using JXKit for a Swift server as it can use the Linux version of JavaScriptCore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants