TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

2019 in Review

124 点作者 Rauchg超过 5 年前

8 条评论

wokwokwok超过 5 年前
Nice write up; agree with some thoughts, disagree with others.<p>Think this is daft though:<p>&gt; The word &quot;native&quot; has always bothered me. No one can seem to agree on a definition, but we all agree that &quot;native apps&quot; are always optimal.<p>&gt; I propose the following alternative definition of native: an app that behaves to the quality standards of the platform it&#x27;s deployed to.<p>&gt; A well engineered Electron app will give you &quot;native&quot; platform fidelity, regardless of programming language.<p>These are simply things I disagree with, and I find it troubling to see them promoted, because I&#x27;ve heard them before, recently, in person, from colleague.<p>You can argue that &#x27;native is better&#x27; or not, but really? Do we have to fuss around with wording and pretend there&#x27;s some magical alternative definition of what native means, in order for us to cool and be writing &#x27;native&#x27; apps?<p>If I define &#x27;native&#x27; as, written using sql, can I run &#x27;native&#x27; queries in my database?<p>I mean, I get it; the point is that native may not be best, for many reasons.<p>...but it bothers <i>me</i> that I&#x27;ve heard people talking about how to define native; imo if you&#x27;ve gone down the rabbit hole of &#x27;define all your terms to mean custom things&#x27; so you can call whatever you&#x27;re doing whatever you like, you&#x27;ve lost the plot, and you&#x27;re <i>deliberately deceiving people</i>.<p>That&#x27;s bad behaviour, and I don&#x27;t respect it.
评论 #21966325 未加载
评论 #21966398 未加载
评论 #21966370 未加载
leerob超过 5 年前
Excellent review.<p>Just wanted to say thanks. ZEIT&#x27;s attention to developer experience has transformed the way I (and many others) create web applications.<p>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&#x27;s nothing wrong with this approach. However, I&#x27;ve never felt more productive with Next.js and zero-config deployments via Now.<p>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.<p>Kudos to everyone at ZEIT and the Next.js contributors.
millstone超过 5 年前
The author has an unshakeable web-centric perspective, and it make for a bizarre, alien, and insulting read. Here&#x27;s my kindest take as not-a-web-dev:<p>&gt; 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.<p>You don&#x27;t &quot;maximize availability&quot; by shuffling from one server to another. You do it by shipping the assets as part of the app. That actually &quot;removes the server from the equation.&quot;<p>&gt; It [static] gives you &quot;O(1) TTFB&quot;, 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.<p>Hosting any asset on any server means that code, servers, sockets, and probably databases are involved. &quot;TTFB&quot; is nonsense.<p>&gt; I propose the following alternative definition of native: an app that behaves to the quality standards of the platform it&#x27;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 &quot;native&quot; platform fidelity, regardless of programming language.<p>Indeed &quot;native&quot; 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.<p>&gt; This means it&#x27;s only a matter of time before React Native (and similar technologies) replicate the success that Electron has had on desktop<p>&quot;JS orchestrating native widgets&quot; and &quot;single-site-browsers-masquerading-as-desktop-apps&quot; are very different futures.<p>&gt; Electron app memory usage: 150 MB<p>&gt; Native app memory usage: 0 MB (because you never ship it)<p>I agree the author has never shipped a native app.
评论 #21968409 未加载
评论 #21976655 未加载
siquick超过 5 年前
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超过 5 年前
So many buzzwords and technologies... It&#x27;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.
评论 #21982430 未加载
jayd16超过 5 年前
A few nice links but pretty opinionated. We&#x27;re all switching to static js and monoliths? No.
评论 #21966018 未加载
azangru超过 5 年前
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.
评论 #21967636 未加载
samat超过 5 年前
Website design is so fucking amazing. Clean, blazing fast.