If you enjoyed 1Q84, and haven't yet read the Wind-up Bird Chronicle, there's a little bit of a connection you might enjoy.
The first Murakami book I read was Hard-boiled Wonderland and the End of the World, and it's still one of my favourites, with a new translation by Jay Rubin coming out later this year. The book of his that's always spoken to me the most is South of the Border, West of the Sun.
If you're ever in Tokyo, consider visiting the Murakami library at Waseda University. It's got a small cafe downstairs, sometimes with live music performances, and lots of nooks and corners for sitting and relaxing with a book. There are copies of all of his books, and tons of translated copies in many languages.
Wonderous is an app we've pointed people to in the past. I believe the current iOS release on the App Store uses the newer Impeller rendering engine instead of Skia, but I could be wrong.
This indeed runs much smoother than most Flutter apps I've used in the past!
If it was indeed all just due to the slow rendering engine, hopefully this will sift down to other apps.
In the end I really don't care what framework a mobile app is developed with, as long as apps don't feel janky and/or out of place as far as platform UI conventions are concerned. In that sense, me not noticing that an app is using Flutter, React Native, maybe even webviews etc. is probably the ideal :)
But my experience as a user of apps leveraging technologies like this has often shown that reinventing so many layers of the UI rendering stack inevitably leads to some form of "weirdness". Sometimes that's ok; sometimes the alternative would be even weirder, badly developed and maintained native apps. But I can't say I've ever loved using such an app for, and not despite, not being a native app. The React Native approach just seems like a better level to try platform abstraction at.
On the web, I still can't help but find "rendering text and UI elements to a canvas" incredibly weird. I could see that approach working for games, but for things that might as well be regular old web applications, there are just so many things that can go wrong... (Reader mode and password autofill come to mind, for example.)
I think that ultimately (and despite what they might claim) Flutter just isn't a web technology (it's not suitable for rendering to web). But that shouldn't necessarily take away from it as a technology for native app development. React Native is a little better at this (and actively on rendering better to the DOM), but it isn't great either.
I think that might have been true when the DOM was the only game in town. With the introduction of WebGPU support coming to the platform a lot of those arguments begin to fall apart pretty quickly.
> On the web, I still can't help but find "rendering text and UI elements to a canvas" incredibly weird.
Flutter's docs explicitly say [0] that it is not a tool for building websites, it's for web apps. If all you want is to render some text onto a canvas, look elsewhere.
In Japanese it’s called both 小型月着陸実証機 (roughly: small moon lander probe) pronounced “ko-gata tsuki chakuriku jisshōki” or スリム (SLIM). It’s not uncommon to have an English name alongside the Japanese one for some scientific projects but not always the case — e.g. I don’t recall hearing the Hayabusa probe referred to by any name other than Hayabusa (which means falcon) in the news.
Hayabusa was also called MUSES-C. This is not only an aerospace thing, Japanese government departments and political parties usually have an english name and abbreviation. Even if it's not commonly used in daily life you will see it used for URLS.
You might be the person to ask a question that my children asked years ago. In Japan, do Japanese cars have e.g. Toyota written on them in Japanese or English? How about the model names, especially for domestic-only models? Thank you!
To answer your example question directly: English. I don’t think Toyota would ever be written in Japanese on a car, but when talking about the company in writing it would usually be rendered in Japanese.
For model names, it’s more possible that it could be in Japanese, but even then I think it’s rare. Even outside of the realm of global industries like cars you’ll find English words and phrases being used to brand everyday local products all over the place. Japan is far more full of English writing than the Anglosphere is of Japanese…or any other language. When actually talking about these products, though, it’ll usually be written in Japanese (not least because most people in Japan aren’t confident enough in their English ability to use/remember those words and their often unpredictable spellings).
Badges are often in English for cool factors, and then often katakana transcribed on documents and brochures for readability, e.g. Camry -> カムリ(kamuri). China does that inventing vaguely close Chinese names thing, e.g. Nokia -> 诺基亚(nuòjīyà, pronounced "no, ghee-yer") but that's confusing and we don't do that.
> not using the card purchase UI at train stations is confusing.
Agreed that the UI for Japanese train ticket machines can be confusing for first-time users such as foreign visitors, but foreign visitors aren't the primary use case. These machines are designed to be familiar and fast for the bulk of their users: residents of Japan who know how the train system works. Stations need to move massive numbers of people through these machines quickly, and this layout is incredibly efficient for that.
Older terminals used a very similar layout of two groupings [1]:
1. physical pushbuttons with prices displayed using 7-segment LEDs
2. physical pushbuttons for most common multi-passenger sets
The touchscreen terminals provide this exact same layout, which provided continuity as the changeover happened, and kept the lines at the machines moving quickly. They're also freakin' brilliant when it comes to minimising the button-presses required to buy tickets. e.g. two parents and a kid going to a station that's 400-yen from here? Press the "two adults, one kid" button, then the fare. You're done. Fare zones are listed on a large train network map usually posted right above the machines with both adult/child prices [2], but locals almost always know where they're going and how much.
Given how heavily-trafficked Japanese stations are, it's way more critical to minimise the time required to use the machines and keep the lines flowing than it is to provide an easy experience for foreign visitors. Compare to e.g. Montréal where even users familiar with the metro can spend upwards of a minute to buy a ticket or recharge an Opus card.
Carryover old user interface (paper, button, board, etc) layout and flow on latest user interface is a phenomenon seen everywhere in Japan. Enterprises don't want to take risk to change interface much, or no ability to think that.
I know someone mentioned Lynx, another option is to set up your mailcap to view using w3m. For reference, see .config/mutt/{muttrc,mailcap} here: https://git.bracken.jp/dotfiles/files.html
Hey there - Flutter team member here. Support for integrating arbitrary non-flutter views/widgets (referred to as PlatformViews in Flutter terminology) is something we're actively working on at the moment, once we've got them landed, web views and video player support are top of our list in terms of views to add support for. We know people can't wait for this to land, and believe me, I can't wait for it to land either :)
PlatformView support is one of our top desktop priorities this year (along with multi-window support).
The process that caused the light we see as the CMB happened everywhere in the universe roughly all at once. At the time, from any given point, you'd just have seen blinding light but as things cooled, you'd see a sphere expanding around you where this light was dimming, as less and less, and finally none was being emitted around you, but due to the finite speed of light, light from outside that sphere would still continue arriving in your eyeballs. That's the situation we're in today; that sphere's just really big now.
During recombination epoch ~400,000 years after the Big Bang, this light would have been visible. Due to expansion, over time that light has stretched to longer and longer wavelengths, and we currently see it as microwaves.
Note: It's been ~30 years since I was actually studying physics & astronomy; others may be able to offer better explanations or correct me.
The conviction rate is 99.3%. By only stating this high conviction rate it is often misunderstood as too high—however, this high conviction rate drops significantly when accounting for the fact that Japanese prosecutors drop roughly half the cases they are given. If measured in the same way, the United States' conviction rate would be 99.8%.
If you take a look at how Flutter is implemented, you'll see that at the bottommost layer (dart:ui), it is imperative. On top of that, we built the rendering/painting layers (pretty imperative) and then the widgets layer (reactive).
Each of these layers is public API and follows the same breaking change process as any other part of Flutter's public API, so with a bit of effort an alternative imperative framework could conceivably be built built on top of what's there. The downside is that since the widgets layer is reactive, you'd be giving up all those shiny widgets that are part of the SDK and need to build your own (or find a way to wrap what's in the SDK).
TL;DR it's entirely possible to create an imperative framework on top of Flutter's lower layers, re-using a lot of our existing code, but (as far as I know) such a thing doesn't exist today.
The first Murakami book I read was Hard-boiled Wonderland and the End of the World, and it's still one of my favourites, with a new translation by Jay Rubin coming out later this year. The book of his that's always spoken to me the most is South of the Border, West of the Sun.
If you're ever in Tokyo, consider visiting the Murakami library at Waseda University. It's got a small cafe downstairs, sometimes with live music performances, and lots of nooks and corners for sitting and relaxing with a book. There are copies of all of his books, and tons of translated copies in many languages.
reply