Next.js 7 | Hacker News Reader

Next.js 7

nextjs.org

200 pointslxe39 comments

Time and time again, the Next.js (and Zeit) team blow me away. The rate at which they release new, high-quality versions of their products is astounding, especially given how few people are working on this full time -- it's basically just Tim Neutkens, who's insane: he's constantly pushing updates, reviewing PRs, and finds time to be very active on the support channel.

We use a bunch of Zeit's tools (particularly Next.js and its static export feature) at Common (https://www.common.com -- we're hiring!), and they're consistently such good and reliable products (doesn't hurt that they have a sharp focus on developer experience).

Congrats to Tim and to the entire Zeit team!

> it's basically just Tim Neutkens, who's insane

Insane is an understatement. The dude has helped me on the support channel more times than I can count. Forever grateful.

Not to mention pkg is pretty awesome too from Zeit

> it's basically just Tim Neutkens, who's insane

when looking at tools to build a business on, that can be a liability no?

Fair, but my confidence in it stems from the giant community around Next.js. Zeit, a company with a good reputation among developers, works on it full time. It has contributions from other big-name OSS contributors and big companies (Netflix, Hulu, Nike, Ticketmaster, Jet, Auth0, Marvel, etc.). It's definitely a liability if it were truly just one individual developing it, but I suppose it's more that there's a small core of facilitators, with a giant OSS community around it.

As said elsewhere, I mostly act as a curator of a very large effort of hundreds of individuals. The project was actually co-created by several other people who work on infrastructure at ZEIT (e.g..: Naoyuki Kanezawa led all the initial releases, designed important parts of the framework, Arunoda Susiripala contributed the test harness and key build pipeline infrastructure, and so on).

Curious why you didn't mention Arunoda -- does he not work on it anymore. IIRC Arunoda started Next.js right after (perhaps because of) leaving Meteor ecosystem.

I don't think he created it, but he was there early on and works for Zeit. Still eternal grateful for him creating kadira.

Wow, TIL. Also a very nice display of Cunningham's law: "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."

I'm going to post the same answer I gave in another thread on the initial post:

Completely agree! I have used next.js in multiple projects now and have gotten very fast turnaround on any submitted issues. Love the product and the team!

Could anyone explain what Next.js is? I use React (using create-react-app), but I'm under impression that React is a JavaScript framework (like Spring is Java framework, or RoR is Ruby framework).

So Next.js is a framework for a framework?

React provides a way to build pages and components, Next.js provides the other pieces that make up a full-stack framework like routing, asset mgmt, and most importantly, server-side rendering. Getting SSR to work seamlessly with Webpack, Babel, and any other frontend tooling is a pain in the ass, Next.js makes it dead simple.

React is more of a library instead of a framework and it's just the view layer. Next.js is a framework(minimalist) for React.

https://github.com/zeit/next.js/

And what would be the "maximalist"/rich framework for React? (with lots of pre-made RAD components I guess).

React is nostly the view layer. Next provides everything else.

> Next.js is a minimalistic framework for server-rendered React applications.

https://github.com/zeit/next.js/

So a specialized framework based on another framework

React by itself isn't really a framework.

What's the closest framework for Vue.js and how close is it in terms of functionality?

Asking because Next.js has been one of the reasons I've become more interested in the React ecosystem.

Theres Nuxt.js. I haven't used it but it seems about on par with Next.js https://github.com/nuxt/nuxt.js

https://nuxtjs.org/

As others have mentioned, Nuxt.js is what you’re looking for. And, it’s pretty great to work with. Prior to using it, I just got “done” building out my significant project with vue, just plain vue. When I started this next one, I decided to give Nuxt a shot, and it has been like the missing piece I was looking for in the previous app.

It provides structure to you app, gives you everything you need to build out a front end out of the box (router, vuex, build system, etc). And deploying it is a breeze, giving you the option for static html builds, or a SPA, or you can go full blown SSR, with the best part being you can switch between them whenever seamlessly if your needs change. It provides enough opinion that your project has a consistent structure, but doesn’t get in the way if you need to so,etching outside of norm, extending and configuring it is a breeze. And to top it off, the docs are great.

Definitely would recommend it to anyone looking to build any sort of non trivial front end with Vue. I know my next few projects will certainly be using it.

How is Nuxt different from vue-cli? I thought the latter had all the features of the former and I was struggling to understand the difference when I researched both.

Thanks for sharing your experiences, could you recommend any resources for plugging data into Nuxt? This is what I've always been curious about coming from Meteor

I can’t think of any particularly good articles, or things of that nature. But, you’ll mostly be utilizing Vuex to store, mutate, & fetch data. If you aren’t already familiar with it, the docs are great [1]. It’s fairly simple to use, and as your app grows you’ll likely find yourself writing more and more boiler plate store code, but fortunately, there are a ton of really great plugins/utilities the community has built for Vuex that help eliminate a lot of that boiler plate, and make it easier to work with an ever growing store. The Awesome Vue repo [2] has a pretty comprehensive list, and you can probably get some ideas of how you’d like to work with it from seeing all the options, for example Vuex-persistedstate & vuejs-storage allow you to interface with localstorage, while Vuex-pathify provides a nice, less verbose interface for actually working with the data in the store, and then there are things like vuex-api and vuex-rest-api that eliminate a lot of boilerplates code for interacting with apis to fetch/update data.

[1] https://vuex.vuejs.org/

[2] https://github.com/vuejs/awesome-vue/blob/master/README.md#v...

Not clear to me from the release notes if there now is an easy way to proxy to a server in development (if you for instance have a Django driven API on port 8000). This is easily done with create-react-app by just adding a line in package.json.

In Next you've had to either set up and configure nginx locally or proxia via an Express server, both options that that are a bit of a hassle to set up for such a common case.

create-react-app is actually removing this feature in an upcoming release. We don't have plans to include it as a feature to Next.js as you can already implement it using a custom server. We do have an example for it: https://github.com/zeit/next.js/tree/canary/examples/with-cu...

Why is it being removed?

To let an external express server handle it. Which they think will be better than the current in house solution.

In a Next.js + Now context you'd use the path alias feature [1] of now in production, using a rules.json file to do the route mappings to other microservices or external URLs.

In development you'd use micro-proxy [2] and define a rules-dev.json with local mappings, and then have a package.json script to fire up that proxy for local testing.

[1] https://zeit.co/docs/features/path-aliases#path-alias

[2] https://github.com/zeit/micro-proxy

I have done it in the reverse way: have django act to proxy requests to the node server.

That way ypu can use django sessions, authentication, login, admin, etc.

The node server just does rendering, and creates client side JS based on data it is given by Django.

It took 25 lines of code, yes, but pretty much worth it if you have a long term project like a single app that your company is built around.

Setting up http-proxy-middleware via Express in a Next.js app is under 10 lines of code.

Which backend solution that isn't a service/CMS, but is more streamlined than Express or Koa would you recommend for solo devs going with Next.js? Is there something like a preferred full stack solution involving next.js on the frontend?

Next.js is not prescriptive about your backend stack, it gives you a way to fetch data using `getInitialProps`. At ZEIT most of our APIs are built using Micro: github.com/zeit/micro, which is a very lightweight way to build APIs.

I really like the styled-jsx changes. One major issue I had was the fact that it's been difficult to pass styles onto child components without leaking them through the entire application. I'm really glad to see that they fixed this issue. Great job, Next.js team! I'm really blown away by Zeit in general.

The speed improvements calculations seem weird to me. Shouldn't one build done in 178s instead of 304s be 70% faster instead of 42% faster? (you can do 1.7 of build using the old amount of time)

What you're saying is that comparing the existing build time to the new one, the existing one is about 70% slower. You can also phrase it as comparing the new build time to the existing one, it's about 42% faster.

Both are true statements, however people generally like to discuss how much improved the new releases are versus how much worse the old ones are.

Fun fact, it's important to understand that relationship in other areas as well like the stock market; if your holdings lose 50% of their value, they then need to increase by 100% for you to be back neutral :)

so with Next for SSR you use React as a templating engine and just send that back?

Sort of. Next expects to find a file structure of scripts in the /pages directory. On the initial load of say www.nextsite.com/about/location, Next will by default try to render the file /pages/about/location.js or /location/index.js.

You can add an asynchronous function called .getInitialProps, which should return some props that are required for the page. On the initial load, Next will first run through getInitialProps, then render the actual component with those props. From then on, assuming you're using 'next/link' for routing, everything should work like a single page app. All of the pages except for the initial one are rendered on the client.

Kind of.... Just it is easier comparing with other server side web application framework...

Reply on news.ycombinator.com