2019 in Review
rauchg.com
rauchg.com
Think this is daft though:
> The word "native" has always bothered me. No one can seem to agree on a definition, but we all agree that "native apps" are always optimal.
> I propose the following alternative definition of native: an app that behaves to the quality standards of the platform it's deployed to.
> A well engineered Electron app will give you "native" platform fidelity, regardless of programming language.
These are simply things I disagree with, and I find it troubling to see them promoted, because I've heard them before, recently, in person, from colleague.
You can argue that 'native is better' or not, but really? Do we have to fuss around with wording and pretend there's some magical alternative definition of what native means, in order for us to cool and be writing 'native' apps?
If I define 'native' as, written using sql, can I run 'native' queries in my database?
I mean, I get it; the point is that native may not be best, for many reasons.
...but it bothers me that I've heard people talking about how to define native; imo if you've gone down the rabbit hole of 'define all your terms to mean custom things' so you can call whatever you're doing whatever you like, you've lost the plot, and you're deliberately deceiving people.
That's bad behaviour, and I don't respect it.
People who are passionate about something, be it computers or cars or food, tend to obsess over what their passion is built from and not purely on the end result. To laypeople, the end result is all that really matters. I've never once asked to tour a kitchen. But to the nerds, it's really important what their apps are made of, even if the end result is the same. So "native" becomes a contentious word. An insult, even, when the contrary is argued.
Now of course some people will exclaim that it's horribly clunky and slow the way some people exclaim that they need 120hz TVs because 60hz is awful. That's fine. But despite that, Vscode is fine.
The guy is running a business. The word native doesn't make him "feel cool", it's a valuable marketing term that means little more to consumers than "fast".
Do consumers care how fast apps are designed? Whether performance gains are thanks to the thought given to the content delivery and deployment vs the programming language it was written in? They couldn't care less!
Who are we protecting by steering clear of the "rabbit hole"?
I'll concede that terms like web native are clearer than using native as a catch-all term. But I cosign wholeheartedly on defining native as an app's proximity to the full power of its platform. Whether that's web, iOS, Android. etc. Put the focus on the platforms. When used to their full potential, how do they stack up on performance? Platforms that compete on improving user perceptions of app performance are healthy platforms.
This isn't bad behavior, it's an attempt to have a conversation that you are ending rather abruptly.
Don't get me wrong, I think there are plenty of reasons to hate Electron, but this shouldn't be one of them.
With languages that compile to other languages, toolkits that wrap or abstract other toolkits, it's not so cut and dried. It seems to me a bit like arguing over whether or not something is a scripting language. The specific characteristics of the technology matter, but which side of an imaginary line it falls on does not.
* In programming, it means compiled to CPU machine code ahead of execution. So C++ and Rust count, but interpreted languages like Python (on CPython) do not, and JIT-compiled languages like C#, Java, JavaScript and Python (on PyPy) do not. (An exception is Java on Android, which is compiled to machine code on installation so is actually native.)
* In GUIs, it means using the graphical widgets provided by the platform itself. This is the only way to really guarantee the widgets are consistent with other applications, including all the niggly features like hotkeys and accessibility. A key differentiator from using a toolkit that attempts to mimic the platform's native widgets is that if the platform changes appearance or behaviour in future (e.g. a new version of Windows changes the visual style of combo boxes) then your application changes appearance without requiring a new version to be downloaded.
I don't think Electron satisfies either of these.
Edit: If a platform ships without any native way to create widgets – if using a toolkit that draws them manually is your only choice – then even that doesn't invalidate the definition of native (in the GUI sense). It just means that, on that platform, the answer to "is this a native GUI?" is always "no, there's no such thing on this platform".
If native means "fast and matches the default look and feel", then to the extent that the user can tell the difference, anything that is not native is worse. But if the user can't tell the difference, then it doesn't really matter whether it is "truly" native or not.
I think most people saying that Electron gives you native-like performance or look-and-feel are kidding themselves, which may be a reasonable criticism of Electron apps, but let's criticize them on the user-visible characteristics, not on the technology used to get there.
According to your definition, would MS Office be a native Windows app? I think not, on at least two counts.
I never said that a user should care about whether a program is native, at least in the coding sense. The GP comment also never claimed that native is better, just that it's factually untrue about Electron. As an analogy, a user shouldn't care whether you used camel case or snake case for identifiers in your code, but that doesn't mean we should declare that "all code is written in camel case" just because you can't tell when you use the program.
In practice, of course, it's often the case that native code is faster and uses less memory than non-native code. (This is certainly obvious every time you use a JetBrains IDE, much as I love them, which are written in Java.) But if your app is non-native but still fast and low memory then just directly say that it's fast and low memory, don't pretend that it's native or even bring the subject up.
For native GUI widgets this does make a much more direct user impact. But if a toolkit has extremely high fidelity to the native controls then it's a true a user wouldn't care. Again, I'd say it's factually incorrect to describe that as native but saying it's indistinguishable from native widgets seems like a reasonable thing to say about an application.
As for MS Office, as I've already said it doesn't make any difference to me as user whether it's native code but as it happens I'm pretty sure it's mostly written in C++ (it certainly used to be). The ribbon is not a native control but a lot of the rest of the dialog boxes are - just look at the font or page layout dialogue in Word, and it certainly uses the native Windows file open/close dialogues once you dive deeply enough into its file menu/tab to open them. So I'd say even from the GUI perpespective it's mostly native with a few custom controls.
And I would say Office is native on Windows, I don't see how the flagship product written for that OS could be considered anything but. Even if they wrote the entire UI in an interpreted language and used all custom widgets, that would still be true according to my definition.
So if someone designs, for example, a window system with support for sound and vector graphics (these being the defining features of the system), a native application for this system would be one that uses the characteristic built-in features of the system to create windows, play sound and draw vector graphics, the expression of the application being shaped by the nuances of how these things work on this particular system. A non-native application would be one that abstracts windows, sound and graphics to work equally well on all kinds of systems and hides the peculiarities (or advantages) of this specific system.
Just wanted to say thanks. ZEIT's attention to developer experience has transformed the way I (and many others) create web applications.
Just a few years ago, I would have opted to use vanilla React with GitHub Pages. If I needed a server, maybe Flask deployed to Heroku. There's nothing wrong with this approach. However, I've never felt more productive with Next.js and zero-config deployments via Now.
The flexibility that Next.js offers (as touched on the review) continues to provide a platform for simple static sites to complex, typed web apps with API routes or even a custom server. The best part? Very minimal breaking changes.
Kudos to everyone at ZEIT and the Next.js contributors.
> Static is globally fast. When you deploy, we can hoist all your static assets to a global CDN network. By removing the server from the equation, we can also maximize availability by reducing and even altogether eliminating cache misses.
You don't "maximize availability" by shuffling from one server to another. You do it by shipping the assets as part of the app. That actually "removes the server from the equation."
> It [static] gives you "O(1) TTFB", which is a fancy way of saying you get stable and predictable latency to the first byte of the screen. Always, because no code, servers, sockets, or databases are involved.
Hosting any asset on any server means that code, servers, sockets, and probably databases are involved. "TTFB" is nonsense.
> I propose the following alternative definition of native: an app that behaves to the quality standards of the platform it's deployed to. This explains why Electron has been so successful in re-purporsing the web stack to the Desktop platform. A well engineered Electron app will give you "native" platform fidelity, regardless of programming language.
Indeed "native" is descriptive, not prescriptive. Any app which looks and feels native, is native! But Electron apps struggle to meet that bar. Electron is succeeding because it taps into a giant well of web developer expertise; software quality is secondary at best.
> This means it's only a matter of time before React Native (and similar technologies) replicate the success that Electron has had on desktop
"JS orchestrating native widgets" and "single-site-browsers-masquerading-as-desktop-apps" are very different futures.
> Electron app memory usage: 150 MB
> Native app memory usage: 0 MB (because you never ship it)
I agree the author has never shipped a native app.
Much of the reason that Electron has met with such success because it allows you to conveniently package what you already have or were already going to be making (your web app), and add small amounts of new desktop-like functionality around it. To be sure, there are Electron apps that have only ever been Electron apps, but I think it’s fair to say that most Electron projects have been more like “example.com, but as an app”.
React Native, on the other hand, is about providing a familiar language and framework (JavaScript and React) on which to build something entirely new. That’s quite a different proposition, and one that I don’t expect to ever achieve such success.
The rest of Ionic is somewhere in the middle.
TTFB means Time To First Byte, which is important in web since this is when anything meaningful can start to happen for the user. Having the markup as static on the edge means that you aren't hitting a db or a traditional server that will render your markup, allowing your users to gain the benefits of a CDN, including edge caching. This maximizes availability because your app is being served globally, and TTFB is predictable instead of chaotic during times of high load. This method transcends servers by making your app available from "every" edge server.
https://www.cloudflare.com/learning/cdn/glossary/edge-server...
Overall, the development experience should feel like a monolith. One command to do all your local dev, and deploy all at once.
I think Gatsby's GraphQL-first approach and emphasis on plugins makes the learning curve a lot higher than it is for Next. I have transitioned my personal projects from Gatsby to Next.
Frameworks like these need to balance the ease of getting started with giving users confidence that they're not going to end up in a jail where they can't get the functionality they need. The Next team have walked this line pretty well, and I hope they continue to focus on keeping things simple, but flexible enough for most use cases.