7 ms·

2019 in Review

124 points by Rauchg 7y ago

leerob 7y ago
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.
jayd16 7y ago
A few nice links but pretty opinionated. We're all switching to static js and monoliths? No.
- Rauchg 7y ago
  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.
wokwokwok 7y ago
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.
- mpalmer 7y ago
  > 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? 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.
- Waterluvian 7y ago
  It's an attempt to rebrand because "native" = good. There are certainly Electron apps that you can't really tell are not "native". They work fine. 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.
  - arsenico 7y ago
    Can you give an example of such Electron apps, for which you can't tell they're not "native"? Not trying to nitpick or anything, just curious.
    - Waterluvian 7y ago
      Vscode comes to mind. 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.
siquick 7y ago
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.
millstone 7y ago
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 7y ago
  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.
samat 7y ago
Website design is so fucking amazing. Clean, blazing fast.
azangru 7y ago
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 7y ago
  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.
yodsanklai 7y ago
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 7y ago
  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.

2019 in Review

124 points by Rauchg 7y ago

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.

jayd16 7y ago

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

Rauchg 7y ago
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.

wokwokwok 7y ago

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.

mpalmer 7y ago
> 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? 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.
Waterluvian 7y ago
It's an attempt to rebrand because "native" = good. There are certainly Electron apps that you can't really tell are not "native". They work fine. 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.
- arsenico 7y ago
  Can you give an example of such Electron apps, for which you can't tell they're not "native"? Not trying to nitpick or anything, just curious.
  - Waterluvian 7y ago
    Vscode comes to mind. 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.

siquick 7y ago

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.

millstone 7y ago

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

samat 7y ago

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

azangru 7y ago

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

yodsanklai 7y ago

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