LinguaBrowse

Join me as we document in this newsletter the tragic efforts of a devoted group of developers ardently working to improve a framework, unwitting to the fact that it is already dead.

Similarly, to my understanding, some cameras are perfectly capable of taking video, but disable the feature altogether (or impose a 30-minute recording time limit) to be classified as a still camera rather than a video camera for tariff reasons.

What does this do that the Lexical playground as-is doesn’t? On the surface, it just seems to be that demo redistributed as a library.

This article makes no sense. ES6 allows you to express things more succinctly, but it's not a React killer. You'd still be missing a declarative UI renderer if you were starting out framework-free, armed only with ES6.

And it's not a killer of other frameworks, either. ES6 doesn't give me the wings I need to ditch Winston for logging or Redux for managing state. Not sure how this article got to the front page, but it certainly shouldn't stay here :P

Not clear from your wording, but Svelte Native incidentally does exist:

https://github.com/halfnelson/svelte-native

It's a Svelte renderer for NativeScript (a framework targeting iOS and Android), rather than being a port of React Native to Svelte.

Nice read!

Just to mention that Core Foundation includes tokenisers (CFStringTokenizer) and lemmatisers (NSLinguisticTagger) of its own in case you ever wanted to avoid the Python processing!

> Built with box2d-wasm's liquidfun release.

Very nice! How does this relate to the Google official release of Liquidfun, and the mainline release of Box2D?

Nice work!

What's the benefit of using WebGL compared to Canvas?

Does the WASM bring a performance improvement in practice, relative to the equivalent JS library?

Keep it up!

There are a few broken images there; could those be fixed?

Another commenter brought up the idea of porting it to Deno – I’m not sure how inter-compatible the two are, but it provides a hopeful future direction to facilitate sandboxing.

In terms of IDE support, VS Code with the Svelte extension is the best around!

A component library is a bit much to come until Svelte NodeGUI gets a bit more attention. Even Svelte web projects are underpopulated on component libraries, I believe. But it’s worth trying out the built-in primitives first!

Qt does have an implementation that targets mobile. I don’t know how the licensing works, but in theory there should be a way to rely on Qt for mobile to extend support to iOS and Android. Way out of my own expertise, though!

I’d need to pass that question on to Atul (who made the parent project, NodeGUI). As long as Deno supports the same native API bindings as Node does (does it?), I imagine that it wouldn’t be out of the question.

Yep, you could make an HTTP server using Express.js, and a minimal GUI to go with it!

Of course, it could run headless, too. But there is attraction in making it an app that opens like familiar executables.

React Native does extend from platform UI components such as UIView, so that one at least is uncontroversially “native”.

Some clarification on that from the maker of the parent project, NodeGUI, here: https://twitter.com/a7ulr/status/1225498258233053184?s=21

Atul is licensing NodeGUI as MIT, so I’m licensing Svelte NodeGUI as MIT accordingly.

Its UI runtime is Qt and its JS runtime is Node.js. No Chromium here :) it makes super-small, low-memory apps.

No plans, but what kind of integration would you have in mind?

I actually happen to be struggling to get React Native in the NativeScript runtime right now – running it in the Node.js runtime would be if anything even more challenging. But there are other ways to make the two work together.

The parent project, NodeGUI, has some Windows screenshots and examples – I’m not familiar enough with Fluent or WinUI, but basically the UI runtime is Qt5, so integrating it into genuine Windows apps is out of scope (but may well be possible with the right expertise). I assume it would involve some kind of Qt-hosting view. I’m unsure whether Qt5 can host Windows UI components.

Edit: NodeGUI here: https://github.com/nodegui/nodegui

That’s the case, yes – the UI runtime is Qt5 (which is rendered using low-level graphics APIs, so we class it as “native” – mostly in contrast to WebView-based UIs), and it’s the same API regardless of which platform you’re running on.

Maintainer here – Happy to answer any questions!

> What browser extensions other than content blockers exist, that have any significant user base and value, that isn’t already met by better and more capable native apps on macOS and iOS, and somehow could charge people money for the extension with their willing cooperation?

Language-learning extensions are reasonably popular, though most aren’t making the big bucks.

Grammarly is probably one winner of note.

Two

Thanks for these tips; really interesting. Getting a clearer understanding of the differences between types and interfaces, and got some confirmation of the merits of writing explicit return types.

I was wondering whether any more could be done to improve editing performance when large .d.ts files are included. This is a problem in particular for NativeScript, which has a vast set of large types files to include to express the entirety of the iOS and Android SDKs, e.g.: https://github.com/NativeScript/NativeScript/tree/master/pac...

In fact, the skipLibCheck flag was originally developed to improve NativeScript compile time: https://github.com/microsoft/TypeScript/issues/8521

Unfortunately, editing still feels slow to me when including NativeScript’s iOS/Android types (have to wait 1-2 seconds after any keystroke for any IntelliSense to appear); beyond including fewer of the types files, could editing performance be improved somehow?

Thanks!

> as I'm aware, the only "gotcha" of React.Component (vs other classes in JS) is that they shouldn't be extended.

Facebook recommend composition over inheritance, but you can totally extend React.Component and even get abstract classes involved. In my custom React renderer, all the components in the library are based off React.Component class inheritance.

https://github.com/shirakaba/react-nativescript

> If you are constantly passing large amounts of data between the JS thread and the Native thread or constantly changing the layout (which passes data between the threads) you are doing it wrong.

I’m working on an alternative to React Native that does exactly this, and it works absolutely fine: React NativeScript.

In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated.

https://github.com/shirakaba/react-nativescript

https://react-nativescript.netlify.com/

> I don't understand why the JS is run in a separate thread, rather than just using the UI thread for UI (as it's intended for). By making all the interaction with the native toolkit asynchronous, it adds extra latency and leads to unavoidable glitches in native widgets used as controlled components.

Totally agreed. I’m working on an alternative to React Native that addresses exactly this: React NativeScript.

In NativeScript (and thus also React NativeScript), the JS logic and the UI both execute on the UI thread. Furthermore, you can synchronously access any native API without needing to set up bridging code; bindings to the whole Obj-C/Java runtimes are ready-generated to begin with.

https://github.com/shirakaba/react-nativescript

https://react-nativescript.netlify.com/

This exists, albeit only for YouTube rather than Netflix: CaptionPop https://www.captionpop.com/

If they're having troubles with correct romaji transliteration (and even if not, to be honest), I don't see why they don't just transliterate it in furigana then. The source data of Tokeniser dictionaries such as NAIST JDIC isn't even in romaji, so if they are using a proper tokeniser, then they're actually doing an extra step and throwing away data to transform it into romaji form.

Thanks, Dan! The incessant console-flooding was actually one of the things that made me give up on React Native. Great to hear that this is being addressed.