Issues with development speed

tgoldenberg commented 7 years ago

So while I love how Next is trying to solve some really important problems, I'm surprised that I couldn't find any closed / open issues related to development speed. As I'm using this over the last 2 days, I notice a huge drop in development speed when compared to using create-react-app.

For example, I notice that when I make changes, the app recompiles and then the screen refreshes. I was under the assumption that hot loading was offered out of the box, meaning that any saved changes load instantly. I am counting at least 10 seconds between saved change and seeing it on the screen for a pretty simple application (a marketing website).

Now, the answer could, of course, be, "well, why don't you use create-react-app?" I see huge benefits with Next in terms of SSR. I want to use it, but I don't want to lose the development speed I have with create-react-app. What can I expect in terms of these issues being addressed, or maybe I am not leveraging something that is already available?

Thank you, and great work so far!

arunoda commented 7 years ago

@tgoldenberg is it possible to have the app you are working with. I'd like to see why it gets slower. (Specially since you compared it with CRA)

Also, let us know the system info. (OS, Laptop Brand/Version, etc)

nkzawa commented 7 years ago

How big is your app actually ? It's around 2 seconds to seeing change of hot loading on a simple application for me.

Btw, one of the reasons it's slower than CRA is we make sourcemaps enabled on webpack. I think you should be able to disable it by custom webpack config.

tgoldenberg commented 7 years ago

@arunoda I can't share the actual app but I could make a copy that is similar and share that. (will take a little time)

System is MacOS Sierra v 10.12, MacBook Pro (Retina, 13-ince, late 2013), using latest Chrome.

tgoldenberg commented 7 years ago

Also, @nkzawa, can you provide an example of disabling sourcemaps with Webpack? Still learning Webpack...

arunoda commented 7 years ago

@tgoldenberg thanks. May be try to add the NPM package and create some dummy pages. This will be super useful for us.

I think @nkzawa has a point with source maps. We should do a section on the README on how to improve the development speed.

nkzawa commented 7 years ago

@tgoldenberg I didn't test it but something like the following.

// next.config.js
module.exports = {
  webpack: (config, { dev }) => {
    // disable sourcemaps of webpack
    config.devtool = false

    // disable soucemaps of babel-loader
    for (const r of config.module.rules) {
      if (r.loader === 'babel-loader') {
        r.options.sourceMaps = false
      }
    }

    return config
  }
}

tgoldenberg commented 7 years ago

Here's a sample repo: https://github.com/tgoldenberg/next-sample

tgoldenberg commented 7 years ago

@arunoda documentation on speeding up refreshes would be really helpful. Also, am I wrong that hot loading means updating the UI without a refresh? I know this was a source of confusion in Meteor with hot loading / hot module replacement. Are no-refresh updates coming to Next.js? This is less an issue than a query, but it's nonetheless a big factor in choosing a framework. One of the reasons I (and several others) left Meteor was the long refresh times during development. I know create-react-app offers no-refresh updates on .css files only and not for .js files, though I am aware it is possible with Webpack.

arunoda commented 7 years ago

In next, we've hot loading (no refresh) for .js as well. But for some cases, we need to do a full reload. I'll check why this is slow?

tgoldenberg commented 7 years ago

So, I find that every change is causing a complete refresh (in sample repo). Is this because of the way that Provider and MuiThemeProvider are nested, causing everything to refresh, or maybe if I isolate smaller components it would help? Really want to understand how to take advantage of the hot loading. Would be great to explain in the docs when it gives a full refresh vs. hot loading.

arunoda commented 7 years ago

@tgoldenberg I can reproduce the issue. It's not refreshing for changes(I simply changing the LandingPageContent) but takes ~8 secs to re-compile.

Here's some of my suggestions:

Use 2.0.0-beta^ for the next version in your package.json
Your use of styled-jsx is incorrect. Here you are simply using style tags. So remove the jsx attribute from style tags (or use styled-jsx) properly.
Use this suggestion to remove the source maps support.
If you use an alternative for material-ui/svg-icons you could make this faster dramatically. Basically, try to load those SVGs from our static directory. That'll save space from the download bundle as well.

tgoldenberg commented 7 years ago

@arunoda, thank you for the response! I will close this for now and try all of the suggestions. The SVG icon issue is not something I thought of but makes perfect sense. I think we should compile these suggestions into a development performance section in the README. Would be glad to contribute in that direction as well :)

tgoldenberg commented 7 years ago

@arunoda only thing is, I'm not clear why the style-jsx is wrong. I thought I followed the README as per its implementation. Can you point me towards an example with Next.js? Thanks.

arunoda commented 7 years ago

@tgoldenberg check this for styled-jsx example: https://github.com/zeit/next.js/tree/master/examples/basic-css

I think most of the examples in the examples directory uses styled-jsx. Anyway, this is a real issue and I'm working on a proper fix: https://github.com/zeit/next.js/issues/608#issuecomment-275995640

vercel / next.js

Issues with development speed #918