
2019 in Review - Rauchg
https://rauchg.com/2020/2019-in-review
======
wokwokwok
Nice write up; agree with some thoughts, disagree with others.

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.

~~~
inimino
OK, I'll bite. What's your definition of "native" that conforms to your
intuition and works equally well for all platforms (iOS, Android, Windows,
Mac, Linux, ...)?

Don't get me wrong, I think there are plenty of reasons to hate Electron, but
this shouldn't be one of them.

~~~
quietbritishjim
I suppose "native" has at least two different meanings:

* 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".

~~~
inimino
Fair enough. At that point, the term excludes so much that I don't think it
really has much value. At least, I don't think it's easy to argue that
"compiled to machine code ahead of execution" is something that a user would
care about. If you define the things the user actually does care about (fast
start up time, fast response to input) then you're back to defining things
that are user-visible rather than things that are not.

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.

~~~
quietbritishjim
> I don't think it's easy to argue that "compiled to machine code ahead of
> execution" is something that a user would care about.

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.

~~~
inimino
It's a reasonable perspective, but I think it's also reasonable to point out
that "native" is not just used as a technical term but also used a shorthand
for all those benefits that the user really does care about. So "fast,
standard widgets, and conforms to UI conventions of the environment" is a
useful enough group of characteristics that I think it's natural that people
are going to use the term to describe them. It's precisely because non-native
apps are generally worse on all counts, so if you can go to the trouble of
making something that is just as good, people are going to want to label it
that way, and if the technology used doesn't affect the user experience in any
way, it doesn't need to be mentioned.

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.

------
leerob
Excellent review.

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.

------
millstone
The author has an unshakeable web-centric perspective, and it make for a
bizarre, alien, and insulting read. Here's my kindest take as not-a-web-dev:

> 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.

~~~
chrismorgan
To elaborate on your React Native point, which exact conclusion I came to
before reading your comment:

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_rationalist
What about Ionic then?

~~~
WorldMaker
Ionic, or more specifically Ionic Capacitor, _is_ Electron on desktop today at
least, so a lot of the same caveats apply to anything else mentioned about it.
On mobile it is a successor to PhoneGap/Apache Cordova, and there does at
least use "native" web views rather than bundling its own like on desktop.

The rest of Ionic is somewhere in the middle.

------
siquick
Absolutely love Next.js (and Nuxt for Vue which was inspired by it), just for
the routing alone which makes React routing feel so clunky.

------
yodsanklai
So many buzzwords and technologies... It's pretty scary. As someone who is not
into web-development, it seems it would take months to be familiar with
everything mentioned in this post.

~~~
tim-phillips
Then you'd be a senior web dev and get paid the big bucks. As a beginner, just
use Next.js and don't worry about this stuff until later.

------
jayd16
A few nice links but pretty opinionated. We're all switching to static js and
monoliths? No.

~~~
Rauchg
To be clear, not monoliths but 'monolithic functions'. e.g.: each function
defined in the pages/api/ directory of your Next.js app gets bundled together
with all its dependencies at deployment time.

Overall, the development experience _should feel like a monolith_. One command
to do all your local dev, and deploy all at once.

------
azangru
There used to be a time when Next.js focused on server-side rendering of
dynamic React apps, and Gatsby focused on generating React-based static sites.
Now that Next has forayed into the static-site generators world, I wonder
whether it is about to displace Gatsby.

~~~
vosper
I think Next is in the sweet spot by making things static when it can, and
server-rendered when needed. It's been a real pleasure for me to work with so
far (though, prior to version 9 I found it not quite flexible enough,
especially wrt routing).

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.

------
samat
Website design is so fucking amazing. Clean, blazing fast.

