LinguaBrowse

My mistake, thank you for the correction! I've updated the article to avoid any future readers walking away with the wrong information.

As for JavaScript runtimes, having seen Lynx (and some of the internal work NativeScript is doing), I'd like to see more engine-agnostic runtimes rather than coupling each runtime to one engine.

As for writing, I'd like to stick to more manageable topics in future so that I can write as a hobby rather than as daunting work. My previous "Frontend predictions for 2024" (https://buttondown.com/whatever_jamie/archive/frontend-predi...) was similarly thorough and took an exhausting rush to write up. But simpler articles like "Staying productive with chronic pain" (https://buttondown.com/whatever_jamie/archive/staying-produc...) were all possible to finish in a weekend.

There's probably a good story in Node-API, but I think I'd rather take on a research-light topic for a break first!

Thank you very much!

I totally agree on reinventing the wheel. I think our biggest tool towards that will be Node-API, which is the one low-level building block that JavaScript runtimes seem to agree on (and heck, I'm sure non-JavaScript engines could implement a decent chunk of Node-API). The Hermes team are currently interested in it (https://github.com/facebook/hermes/pull/1377#issuecomment-29...) for implementing heavy chunks of the ECMAScript spec like Intl and Temporal as plug-in features.

It's interesting that you bring up tooling like npm and Cargo, I've never thought of sharing those. Although I'm no great shakes at Rust, I really, really liked how Cargo did things (e.g. optional dependencies and rigid library structure) and it'd be incredible to have that for the JavaScript ecosystem.

Also do keep hearing nothing but great things about Graal, I think it's being slept on.

My analysis on the polyglot runtimes was relatively shallow and I did anticipate I might disappoint, sorry! Thanks for the additions!

I did begin a section on WASM runtimes, so Pyodide would've been of interest, but I could see the scope was likely to grow too much if I got into WASM so I held back.

I had it in my head that quickjs-ng (https://github.com/quickjs-ng/quickjs) is now blessed as the official fork, with Bellard even making some contributions to it, but maybe I've got it wrong. Here's the latest (https://github.com/quickjs-ng/quickjs/discussions/258#discus...) clarifying the two forks, anyway.

Dang, I misunderstood that, thanks! Fixed.

Took me over a year to finish writing this monster of an article. 4,000+ words, 200+ links, and lots of research covering countless JavaScript runtimes and engines.

Please have a read! I guarantee you'll learn something new.

During my research internship, I met many PhD students whose labs simply ran out of funding. In some cases, they'd ended up having to scrap their PhD as the topic was too specialist to do anywhere else (e.g. requires a high level of biocontainment) and nobody wanted to fund it.

I think if you got three years into a PhD and were faced with the prospect of starting it all over again in another lab, it wouldn't take much to convince you to throw in the towel and do something else instead.

Was wondering how they got hold of "Powdered Milk from 1952 Korean War Rations", but they even answer that!

  > COLLECTION LOCATION:
  > eBay, sold by littlebitoeverythingjoe

Amazing how meticulous they've been, right down to recording the conditions that the package was shipped in:

  > SHIPPED IN:
  > Original packaging inside Ziploc bag
  > 
  > SHIPPING METHOD:
  > UPS Overnight

https://www.plasticlist.org/product/37

Could I search on language? Want to see what the Japanese options are.

I studied an BSc in genetics and none of our lectures or textbooks presented mitochondria any differently from the classic bean shape they introduce in school. This is surely old news to folks who specialise in mitochondria, but it's easy to miss out on these fundamentals even if you've studied in a relevant area at degree level, because there's just so much to know in biology.

In fact, it's one of those fields where the more you learn, the more you realise we'll never reach a satisfactory understanding in our lifetime. You could chuck an endless supply of PhD students at every constituent domain for generations and still feel like you've scarcely scratched the surface of the many things there are to question.

Thanks for sharing this. I’ll be checking its potential as a base element for something like NativeScript or Node.js.

Text is about the most complex UI element that a UI framework offers, and if you’ve got Flow Layout working, that’s very encouraging! Will be interested how far along things like gestures (particularly text highlighting) and IME integration are. In any case, kudos for opensourcing this!

I'll give you sticky headers on one axis, but am still waiting for the day that CSS supports them on both axes: https://github.com/w3c/csswg-drafts/issues/8286

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.

Likely referring to that, yeah. And yes, the metadata is fine - but it’s a joke that I can’t find any Japanese books I own on my file system because Calibre’s author has renamed them to something that makes sense neither in Japanese, nor English, nor even Chinese.

It’s particularly dumb as it will have taken even more work on his part to map the characters to pīnyīn than it would’ve to just preserve the actual titles.

Thank you very much!

In this issue of "Whatever, Jamie", I recap the last year of frontend – covering SSR, AI, JS runtimes, cross-platform dev, and more. I then make predictions regarding Apple, Vercel, Expo, React Native, Bun, HTMX, and the industry in general.

Ah, that explains it. I'd better give the whole thing a proper read once I'm free.

I am still a novice to grid - in the Assigning Children interactive demo, if you click-and-drag across a row or column, the .child style will always refer to fractions of 1, ⅓, ¼, and ⅕, despite being a 4×4 grid. Can someone confirm whether there's a bug? I'd expect it to rather be 1, ½, ⅓, and ¼.

My first time writing something personal (and, I guess, motivational). Got to head to bed now, but feel free to leave any thoughts and I'll be happy to get back to them. Will also be interested in what strategies you all use to stay on top of chronic pain.

React Native has been developing rapidly in the last two years, though an exact roadmap from here has not yet been spelled out. Here I try to join the dots and speculate where we might be headed, by analysing the activities of a few key stakeholders.

As the author, I'd be happy to expand on anything!

Any plans for Bun on mobile in future? If so, any idea around how big it might be (sub-megabyte, multi-megabyte)?

The documentation says it builds “truly native” apps, so I was expecting direct PHP bindings to native APIs and for the UI to be fully native (AppKit, GTK, etc.). On closer inspection, though, it’s just a PHP framework on top of Electron? A bit disingenuous.

Nope, React Native does support targeting Windows and macOS (and, though with less love, Linux) and even Web, tvOS, Android TV, and more. It’s just that iOS and Android are the only official Meta-maintained ones.

The macOS and Windows implementations are solid, being maintained by Microsoft, and are even used in small corners of Microsoft Word and other flagship apps.

Author here. Very confusing licence, is my main complaint (I speak also as the author of Svelte NodeGUI, which is built on top of Qt). The fact that there are hour-long seminars explaining the licencing (https://www.youtube.com/watch?v=m7etOQfrMiM) show that it's a real issue. I recall Qt for mobile has an even muddier story, with a different licencing/pricing model again.

Besides that, I also personally find it horrible to program with, because different elements have differents way of managing their child nodes (unlike HTML Elements, which have one consistent API). And of course I'm a JS dev, though NodeGUI does solve that. But maybe these aren't valid gripes.

I think the point is that the decisions on direction shouldn't be made behind entirely closed doors by insiders. Outside input should be taken seriously, with invitation to dialogue, rather than chasing some narrowly-supported vision.

As a web developer myself, I too am baffled by the folks who don't like the Web stack, but fine.

And good points, I guess I wasn't too concrete on "unify on one approach" vs. "consider all options". So to solidify my thoughts, I do think diversity in approaches is a good thing. It would just be great if any parts could be shared so that others could iterate on the same idea.

For an example of a missed opportunity for diversity, if only React Native had originally architected itself as Reactless Native + React, we could've had equivalents for each different renderer by now (e.g. Vue Native, Angular Native) based on that Reactless Native base.

For an example of the merits of unifying on one approach, see Yoga Layout. Flexbox has proven to be an agreeable layout model, and because it's so solid (apart from where it varies from the spec, which I do grumble about) various different cross-platform projects have benefitted from unifying around it as a reliable building block.

I guess my grumbles with Yoga's spec deviations echo your distaste for the "it's a solved problem" sentiment, too. Even established solutions should be open to improvement and evolution, and I had that partially in mind when talking about being open-minded.

I think there's potential in those ideas, if only they are not to the detriment of the Web (which is already working just fine).

As an alternative to iOS and Android development, I welcome ground-up solutions as long as they can get text editing right. However, I bring that up as I can't see anyone ever making a ground-up text view as reliable as a browser or native one (consider CJK, RTL, and vertical text, and IME input) without a dedicated team spending years of work and closely examining each platform's equivalent.

I like the idea of Ubuntu Touch (having worked with Ubuntu a lot), but even more so Firefox OS. As a web developer, the idea that "native" could simply mean "the Web platform" is really attractive.

This short essay is a lament about how close we are to creating really good cross-platform solutions, but how we always fall short because of closing off our ecosystems to each other. I hope to spark a bit of conversation with this about how we can do better moving forwards!

As the opening issue of my new newsletter "Whatever, Jamie" where Jamie talks about Whatever, I talk about my childhood dream of becoming a cartoonist and how it could maybe still come true.