17 ms·

Next.js 2.0

627 points by tbassetto 10y ago

iamleppert 10y ago
Crazy to me how people rebuild a simple HTML page and "navigate around" it as a passable performance test. What is going wrong with web development? Why, god, why?
- adgasf 10y ago
  It has live updates and page pre-fetching.
- mateuszf 10y ago
  How many other web frameworks with support for "automatic code splitting, routing, hot code reloading and universal (server-side and client-side) rendering" do you know?
  - megous 10y ago
    All sound like solutions to self-created problems.
    - 0x142857 10y ago
      programming itself is a problem.
    - watty 10y ago
      There are tasks that can be completed quicker with web frameworks and tasks that can be completed quicker without them. They aren't a solution for every task. I'm not sure why people struggle so much and fight abstractions so much but I guess that's a sign a techie is getting "old".
      - megous 10y ago
        Struggle and fight abstractions? Some abstractions cause more trouble than they solve, and then create solutions to their own problems on top. That's the point. Older techie might have seen more abstractions, and choose more wisely the lesser complicated one for the job.
      - pg314 10y ago
        > a sign a techie is getting "old". Some of those "older" techies have gotten a wisdom that only comes with experience.
      - K0SM0S 10y ago
        This talk is incredible food for thought: On the spectrum of abstraction by Cheng Lou (react-europe 2016) [1] If you've read some of the classics, such as Structure and Interpretation of Computer Programs (1979, Gerald Jay Sussman and Hal Abelson) [2], this talk is a really interesting look at the state of affairs on abstraction circa 2016. [1]: https://youtu.be/mVVNJKv9esE https://youtu.be/mVVNJKv9esE [2]: https://mitpress.mit.edu/sicp/full-text/book/book.html https://mitpress.mit.edu/sicp/full-text/book/book.html
      - coldtea 10y ago
        >I'm not sure why people struggle so much and fight abstractions so much but I guess that's a sign a techie is getting "old". Yeah, it's a sign they are older, and have seen the same shit play again and again, and starry eyed newcomers fall for every new fad with shit-eating grins...
    - akanet 10y ago
      I don't think this is a good HN comment. If you disagree that these are useful attributes for a platform to provide, please explain so that we can reason about your position. Condescending to people's earnest work isn't a virtue we should promote.
      - matt4077 10y ago
        It's a pretty good argument: the three features mentioned as advantages over static or server-rendered html only exist to mitigate problems created by the SPA structure itself. It's like touting "fast battery charging" as an advantage of a Tesla over a Porsche.
        nilliams 10y ago
        I don't agree, but let's break this down, comparing to a traditional app in Rails/Django that renders HTML server-side, then progressively enhances with a sprinkling of JS. > automatic code splitting By code-splitting we implicitly mean we're also managing dependencies (e.g. via require() or import statements). In a traditional server-rendered-app, you can achieve something similar to code-splitting by manually breaking up your script tags across pages as needed, but you lose dependency management. With code-splitting you get both, and your bundles are going to be better optimised than if you hand-picked script-tags (at least that's the promise of automatic code-splitting, and it'll only be enhanced as 'tree shaking' techniques mature). > routing Really, this should say 'filesystem-based routing', which you don't get for free in rails/django afaik. Granted you get it in old-school PHP, which I think Next is open about wanting to copy the 'ease' of. I think that's cool. > hot code reloading You don't get that in server-rendered frameworks. It's a hugely pleasurable boon to development to not lose all your page state when you just changed a bit of CSS or JS that shouldn't affect state. It even won't destroy CSS or HTML text-content changes I made with the Chrome devtools, which would get lost if I used something like 'live reload' to reload the page with a server-rendered framework. > universal (server-side and client-side) rendering It's not the server-side rendering that's the advantage, because like you say ... we already had that. It's the fact it's both. The initial load is server-side, which is a big win for mobile devices especially (remember when Twitter switched from an SPA back to server-side-rendering to improve 'time-to-first-tweet'). But every subsequent page load is done by requesting the minimal data needed and rendering client-side, which is faster than loading a full page from the server.
    - mixedCase 10y ago
      Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. When well-executed, it provides a better experience to the average user. Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time. Does the tooling suck donkey ass? Yes. Does it have serious tradeoffs to consider? Yes. But in many cases it's the right thing to do to have a higher-quality product.
      - empthought 10y ago
        > Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. This isn't true. Have a look at how the GitHub UI is implemented. [1] There's even a name for this approach. [2] [1] http://pjax.herokuapp.com http://pjax.herokuapp.com [2] http://roca-style.org http://roca-style.org
        NoGravitas 10y ago
        Pjax/hijax is absolutely the right way to go for content-focused sites.
      - Touche 10y ago
        > Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. Client-side routing is rarely used to change small stuff. It's usually used to replicate an entire page transition. > When well-executed, it provides a better experience to the average user. It's rarely well-executed. Client-side routing means you have to replicate every feature of browser routing, and most frameworks get it wrong. Numerous issues like not supporting cmd/ctrl+click to open in a new tab, ext, are common. > Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time. Like the GP said, this is a self-created problem. Separate development pages to test out small parts of an application is how you avoid replicating state. But today's web development environment is so wrapped up in tooling and build complexity that creating a new page to test out a small part of the application is actually really hard to do.
- bpizzi 10y ago
  Who said that it was only meant for reimplementing simple HTML pages? It's a lightweight framework around React, and React was made for anything but for simple HTML pages. Crazy to me how some people will never miss an occasion to bash experimentations.
  - Touche 10y ago
    The example in this article is Hacker News, which is simple HTML pages. The example (and other similar SPA Hacker News examples) is worse than the real Hacker News.
    - spion 10y ago
      So how is it worse?
      - Touche 10y ago
        Slower.
        deleted 10y ago
        [deleted]
        spion 10y ago
        Speed is more or less the same here...
    - bpizzi 10y ago
      There's a logical flaw in that answer: I said 'this was not made only for simple html page', emphasize on the 'only', and your counter argument is 'there's at least one example of it being used for simple html page'. At this point I could still respond with 'this was not made only for simple html page', emphasize on the 'only'.
tonetheman 10y ago
Frameworks made of frameworks... frameworks all the way down
- pweissbrod 10y ago
  The word framework is broad and I dont see this as the same kind of thing as React. This marries set of frameworks which work well together and provides a opinionated but clean approach to building larger apps more efficiently/consistently. Similar to eiffel, MEAN, jHipster etc. There is great value in this kind of bundling effort for those of us less-experienced with the frameworks who need help getting a proper start
- weka 10y ago
  In 3 years, we'll go back to square one! :-)
- frik 10y ago
  I would rather favor libraries over frameworks - more freedom, less worries.
ergo14 10y ago
Why in the world everything needs to be made with react that makes it incompatible/hard to integrate with any other frameworks?
- okket 10y ago
  IMHO because react is designed this way. It makes it easy to add to existing content, it is not an "opinionated" framework. This is great for getting quick results, but not for compatibility, easy source code navigation, etc. You can add these constraints later, but you will be on your own island. Maybe sometime a standard ("best current practices") emerges...
  - ergo14 10y ago
    At this point I have to use react more or less. It is a ghetto. React vs the world. I'd like to have more than one option to use here.
    - bpizzi 10y ago
      Obvious solution to your problem: write your own js component library. And don't forget to submit it to the HN crowd when you're done, you should get a very positive feedback.
      - ergo14 10y ago
        There are other solutions out there: polymer, skatejs, x-tags, vue, angular, aurelia. Some of them are more interoperable with others and can be use in multiple projects using different frameworks - I'd like this to be the norm.
        bpizzi 10y ago
        So, to go back to your original post ('Why in the world everything needs to be made with react'): not everything is made for/with react, and you provided really good counterarguments againts yourself (polymer, vue, angular, etc). I still don't get the point you were trying to make (no offense really).
vincivince 10y ago
Nice work.
Polarity 10y ago
nice, thx!
sergiotapia 10y ago
Next looks very interesting and feels very much like the PHP of old where stuff just works with sane defaults. Very cool stuff. My one criticism of this is: Component CSS is cancer. I've worked on a large scale javascript project and it was riddled with duplicated CSS in every component, all in the name of being conflict-free. You know what I call that? Not knowing how to scope your styles properly with something like BEM. http://getbem.com/ http://getbem.com/
- Kiro 10y ago
  I completely disagree. After working with component CSS I vomit when I see any CSS not encapsulated to one single component. I don't want to change a global CSS declaration and accidentally change something completely different. You can always import the stuff you really want shared.
  - tlrobinson 10y ago
    Yeah, I'm still not sure what the "best" solution is but I'm pretty sure it will allow for better composition and static analysis than "global" CSS.
  - WA 10y ago
    Do you have some reading material on how to do this properly? Because I never worked with component-based CSS yet, but want to have a look at it and wondered about what your parent posted, too.
    - idreyn 10y ago
      There's a set of libraries like Aphrodite, Glitter, jsx-style, and JSS that help you do this. I'd look at some benchmarks [1] and do some comparison before you make a decision yourself. I've worked extensively with Aphrodite (disclaimer, my employer maintains it) and have found it works with React to make a pretty good workflow for SPAs. It does require some buy-in from everyone involved with the codebase since you'll have Aphrodite-defined styles clashing with stuff in external stylesheets, and there are occasional edge cases where you'd like to use some crazy CSS selector that Aphrodite doesn't support, but this is often a sign that you should be restructuring your component in a more straightforward way. The style reuse and composability story is very good, since all styles are wrapped around bare JS objects which are super easy to manipulate and the ES6 spread syntax [2] makes it all look very elegant. If it's important to you to keep styles and markup in different files, you can do that too as long as you're happy giving them all .js/.jsx/.ts extensions. In general it is frustrating to me that total buy-in into the React model comes at the cost of support for actual standards like Web Components, but I never want to write UI in a non-declarative way again so I'm hoping someone smarter than I can figure out how to bring these two worlds together so we can let the browser properly namespace our CSS rather than relying on randomly generated class name infixes as Aphrodite does. [1] https://engineering.hellofresh.com/the-css-in-js-battle-89c34a7a83ea#.cae5q4lkd https://engineering.hellofresh.com/the-css-in-js-battle-89c3... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
jakobloekke 10y ago
I'm curious: Where do these anti-React (anti-spa?) people come from, technologically? Rails? Php? Some .Net stack? Do you think the web Peaked with Perl-based CGI-scripts? I've been in this game for many years, and to me, any technology that speeds up development cycle time is an improvement. There's a reason React is so popular.
- pweissbrod 10y ago
  In the 2000s we used ASP.NET webform user controls and java struts in a VERY similar approach to what react calls a "component" which is great because concepts such as composition and event percolation come naturally and make a great amount of sense (to me). There were many developers who were raised to strive for segregating logic from display (keep your js away from your HTML) and that MVC was a universal solution to front-end development. From what I've seen angular does these things very well and feels more natural to teams where this mindset is well-established.
- kuschku 10y ago
  > any technology that speeds up development cycle time is an improvement. The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on. We come from a world where you have a simple .gradle config file, and you press one command, and it installs and everything just works. No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades (see Bouncycastle, e.g.), etc. Coming from this style of development where tech actually works well, and is stable, to the JS world of React where everything constantly breaks, is very complicated and over enterprise-ified, etc is quite annoying. Obviously, on the other hand, the React world provides other massive advantages, such as quick iteration, innovation, etc – but the work to get something working with constant quality for years is entirely different. Because you’ll have to fork all your dependencies, because those won’t be stable. So if you want your product to be included in Debian Stable, you don’t want to use React. Because you’ll end up forking and maintaining every single of your dependencies-.
  - treehau5 10y ago
tabeth 10y ago
Ah, so close. I really just want something like Handlebars, with a generic adapter for any language for compilation. Then you can load with javascript a client-side controller if you want to add in interactivity. --- To expand, I think the idea solution would be the following: 1. Server side view, let's call it "Bars" 2. Bars can be written on the front-end or back-end, does't matter. It'll compile to BarsHTML. 3. If you write Bars on the back-end, then when you serve your page it'll compile Bars into BarsHTML. 3a. If you want to sprinkle JS onto Bars, you'll use BarsControllerJS, an adapter to whatever framework of your choice, to manipulate it. The main difference between this and manipulating the DOM is that the interface to do this is not DOM centric. 4. If you write Bars on the front-end, it's the same as (3), but you get (3a). If you decide you'd rather do server side rendering, you literally just move your views to the server. The controller is already abstracted, so you wouldn't need to do anything else.
- bhurlow 10y ago
  You can use Next.js to do server-side only rendering. It uses React idioms for rendering in favor of vanilla templating
- laktek 10y ago
  Not exactly the same, but what you describe is similar to the concept of components in Pragma (a project I'm working on). I will write a more detailed post when it's ready for release. Meanwhile you can check the "How Pragma works" in the intro blog post http://www.laktek.com/2016/11/29/introducing-pragma/ http://www.laktek.com/2016/11/29/introducing-pragma/
- gniquil 10y ago
  I think you miss the point of having Next.js being based on React. Although I think handlebars/htmlbars are great (I'm a big ember user), the cool thing about React is it's component based. So pretty much everything you mentioned above, replace BarsHtml to react components, you have Next. However, the react components though in my opinion is much better than handlebars. It is more powerful, more flexible and at the same time more disciplined.
- ramses0 10y ago
tambourine_man 10y ago
I guess I became way too cynical. I though it was a satire, based on its name. Maybe there is some hidden self deprecating joke that went over my head, but Next + JS + 2.0 seemed too buzzwordy to be true. The tech looks interesting. Still looks to me like a lot of stuff that I don't understand why I would need, but that's an old rant I have with the curent js ecosystem.
mike-cardwell 10y ago
I rebuilt https://www.emailprivacytester.com https://www.emailprivacytester.com in NextJS v1 - https://gitlab.com/mikecardwell/ept3/tree/master https://gitlab.com/mikecardwell/ept3/tree/master - Was a pleasure to use. My main problem though was that I couldn't add custom routes for API end-points, so had to split the application into a frontend (in Next) and backend express app. Looks like v2 fixes this. I will definitely be updating to take advantage.
xutopia 10y ago
There is something I do not understand. Why does `<div>` not create a syntax error in the Javascript examples? Is there a pre-processor?
- SlyShy 10y ago
  Yes, JSX considers that valid syntax.
- developerdanny 10y ago
  it uses JSX which allows you to use HTML in JS :-)
- ksherlock 10y ago
  babel, typescript, and bublé can convert jsx into javascript.
- Hnus 10y ago
  Take a look here https://facebook.github.io/react/docs/react-without-jsx.html https://facebook.github.io/react/docs/react-without-jsx.html
migueloller 10y ago
We recently used Next.js to build out an MVP. It was a pleasure to work with. For those wondering what this is, it's basically a slightly more opinionated Create React App [1]. Here are some of the benefits: - No need to setup complicated tooling - Server and client (SPA-style) rendering out of the box - Filesystem for routing using the `pages` directory - `getInitialProps` component lifecycle to encapsulate data requirements per component - Automatic code splitting for each route - If it works with React, it works with Next.js Here are some of the issues we encountered: - Importing non-JS files from `node_modules` (like normalize.css) was not as simple as it could be (#1245 [2]) - Animation transition between pages is still being worked on (#88 [3]) - There are still some inconsistencies between server and client that could improve, like running Webpack on the server (#1245 [2]) - Doing proper scroll restoration when routing (#1309 [4]) We will continue to use it as long as it keeps letting us move fast without having to worry about spending hours setting up React tooling. [1] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [2] https://github.com/zeit/next.js/issues/1245 https://github.com/zeit/next.js/issues/1245 [3] https://github.com/zeit/next.js/issues/88 https://github.com/zeit/next.js/issues/88 [4] https://github.com/zeit/next.js/issues/1309 https://github.com/zeit/next.js/issues/1309
- threatofrain 10y ago
  > For those wondering what this is, it's basically a slightly more opinionated Create React App. Does that mean the top benefit of next.js is to alleviate difficulties with Webpack + Babel + etc?
  - migueloller 10y ago
    I wouldn't say it's the top benefit but it is a benefit indeed! You don't have to worry about setting any of those up unless you want to customize them. You shouldn't have to because they come with sane defaults (i.e., Babel has support for latest ES and the Webpack config takes care of everything for you). For example, the only custom change we had to make was to add Webpack's `DefinePlugin` to expose `.env` variables in the client. It was extremely easy though (3 LOC) and we didn't need a full Webpack config. See: https://github.com/zeit/next.js#custom-configuration https://github.com/zeit/next.js#custom-configuration
andrewgleave 10y ago
The MP4 included in the page causes graphics corruption and locks my MBP in Safari 10.1. Anyone else seeing this? Save your work before trying, though.
asadlionpk 10y ago
I have recently migrated my boilerplate code to Next.js and it's awesome to work in. Previously I had my own code-splitted/server-side rendering setup but next does it better!
swlkr 10y ago
I used next on a side project, zero boilerplate is refreshing.
Stamy 10y ago
Vue.js ecosystem has alternative as well. It is Nuxt.js (https://nuxtjs.org/ https://nuxtjs.org/)
- marvindanig 10y ago
  Super! I love the way VueJS community plays its cards in this otherwise corporate driven turf of open source-y stuff. Will take a look at nuxtjs next.
  - deleted 10y ago
    [deleted]
- shaydoc 10y ago
  It is most excellent. Great little intuitive routing convention, plus plays well with express
- tribby 10y ago
  nuxt is great but I'd wait until the 1.0, which I would guess is coming in a couple of months. it doesn't support response streaming yet, and a few other things that may have been addressed since I last looked..
mmgutz 10y ago
If I'm understanding correctly, seems like this is back to the old days when routes mapped directly to pages. From experience with ASP, it is not a good thing. You need to separate the routing from the presentation ala MVC. I can see the benefit if next.js is intended to be create-react-app++.
smdz 10y ago
I don't understand why people here are comparing Next.js to create-react-app. I see Next.js primarily focusing on server-rendered React and then it also supports client-rendering. I see create-react-app is primarily focused on client-javascript. Am I missing something?
- deleted 10y ago
  [deleted]
- akhilcacharya 10y ago
  Yeah, to me it reminds me more of a react-only Meteor without the baked-in DB
- codecurve 10y ago
  Because both are opinionated ways to get a React project going without having to configure any tooling yourself. Next.js also focuses on client side JavaScript, but happens to render at the server first, so that there's something there for users before the client bundles have downloaded, parsed and been executed. You could think of it as a more configurable create-react-app that supports server side rendering, with a convention over configuration approach to pages and links.
  - williamle8300 10y ago
    > You could think of it as a more configurable create-react-app that supports server side rendering, with a convention over configuration approach to pages and links. You are a poet, sir. Best answer.
anupshinde 10y ago
It would be great to see TypeScript support with NextJS out of the box. It can be done with some work today. Inspired by an earlier(probably first release) of NextJS, I had attempted TypeScript and server-rendered react here: http://www.anupshinde.com/posts/react-typescript-server-render/ http://www.anupshinde.com/posts/react-typescript-server-rend...
- styfle 10y ago
  Very cool. I wrote a SSR React + TypeScript boilerplate [0] and have been trying to keep it updated, but I just found out next.js has a TS example[1] so now I think I'll switch over. [0]: https://github.com/styfle/react-server-example-tsx https://github.com/styfle/react-server-example-tsx [1]: https://github.com/zeit/next.js/tree/master/examples/with-typescript https://github.com/zeit/next.js/tree/master/examples/with-ty...
ndreckshage 10y ago
Next is great. I would love to deprecate my SSR starter kit - Sambell - https://github.com/humblespark/sambell https://github.com/humblespark/sambell - once it supports a layout file, for animated transitions, etc. Right now, React Router seems fundamentally more powerful as a SPA framework.
- symboltoproc 10y ago
  just fyi it's possible to change the commit history, so no "proof" ;)
EGreg 10y ago
Not to toot our own horn, but I wanted remark on how similar the issues we have had to deal with in our own framework (https://qbix.com/platform https://qbix.com/platform), since 2011. When we built it, we had out of the box: + Tools (our name for components) + Pages (to support all web standards) You place tools on pages, the framework does the rest: + It loads JS and CSS on demand + It adds/removes tools from pages automatically as you navigate + Support for web standards, HTML5 history w fallbacks, etc. + Tools can contain other tools + You have events for when all parent tools have activated (onActivate) and when all child tools activated (onInit) + JS and CSS had to be namespaced by convention from day 1, by module and tool name. We use events instead of virtual DOM. We didn't use fancy JSX or preprocessors to do it. It's all written in ES4 JS and runs on every modern browser and IE8. But the problems are very similar in scope.
- laktek 10y ago
  Any links to sources of sample apps built with it? Interested to see how you compose pages with Tools.
  - EGreg 10y ago
    Sure. Here is a full app built on it: https://customizemypic.com https://customizemypic.com - it has a GITHUB link Here is a showcase of what is possible: https://vimeo.com/208438090 https://vimeo.com/208438090 And here are some tutorial videos on pages and tools: https://qbix.com/platform/tutorials https://qbix.com/platform/tutorials
egeozcan 10y ago
I wonder how hard it would be to programatically cache a Next.js app with a ServiceWorker to make it also work offline. I guess one could copy the logic from the prefetch script as it makes network requests like this: http://i.imgur.com/c3H176u.png http://i.imgur.com/c3H176u.png
fourstar 10y ago
I want to use this but I'm hesitant to do so for a project that's backed specifically by a single company. Can someone help alleviate my concerns? I had to verify my email address and accept the TOS before I could use their command line tool.
- migueloller 10y ago
  Next.js is entirely open source and is separate from the product the company offers. Their command line tool is one of the interfaces they provide to use their product but is not needed to use Next.js.
  - fourstar 10y ago
    Awesome -- thanks! This looks fun to play around with.
  - holtalanm 10y ago
    saying something is entirely open source is useless if their License Agreement contains riders like Facebook's React license agreement does. I just don't trust their modified License Agreement.
jonknee 10y ago
This page has some huge issues loading resources. I kept it open as a tab to dive into later and noticed it was still spinning after a long time... I refreshed with Developer Tools open and after 2 minutes over 100MB had been transferred! It appears the screencast video is to blame, it is not only huge (~70MB), but it keeps getting downloaded instead of just replaying. I just checked the console again and the page is now up over 300MB downloaded. Glad I wasn't on mobile data! Update: I downloaded the video and ran it through ffmpeg to see how much space could be saved... Original size 72.2MB, new size 1.7MB. Screencasts obviously compress very well, but this was pretty surprising. You could easily optimize this down further and probably half the size yet again. ffmpeg -i hello-world_2.mp4 -vcodec libx264 -preset veryfast smaller.mp4
- grigio 10y ago
  I confirm, the video is too big
- timneutkens 10y ago
  We're on it, thanks!
  - eclark 10y ago
    The size is much smaller. As for downloading multiple times: I don't think it's happening though it looks like it. The server is sending 206 Partial Content for the video. This is why the file downloads multiple ranges if the page is left open for a while. The first response if for a chunk of the file. The next few are for different chunks. Then it repeats. ~8 Mins on the page and I have 5 downloads of the hello-world_2.mp4 that went to the server. I have 4 that were able to be served from the disk cache.
- deleted 10y ago
  [deleted]
- asaddhamani 10y ago
  It really is a sad state of affairs that this is unsurprising.
- 10y ago
grumblestumble 10y ago
i know this is a tangent and not directly related to next.js, but the react ecosystem's insistence on coming up with increasingly convoluted and self-defeating stories around how to handle CSS instead of just using the tool the way it's intended is pure insanity. the emphasis with styled-jsx favors encapsulation with no real thought put into external overrides or customization, which makes this a non-starter for creating vendor components that are actually usable. compare https://github.com/zeit/styled-jsx https://github.com/zeit/styled-jsx, which can only euphemistically be called a naive implementation, with the documentation around custom properties, with the styling documentation at https://developers.google.com/web/fundamentals/getting-started/primers/shadowdom https://developers.google.com/web/fundamentals/getting-start....
beezischillin 10y ago
Awesome stuff. Just a quick question that doesn't click with me: how would you use Redux to manage application state for multiple users, server-side? If someone could drop me some examples or articles on this, I'd be really thankful!
- pierrehenrit 10y ago
  Check this: https://github.com/kirill-konshin/next-redux-wrapper https://github.com/kirill-konshin/next-redux-wrapper and usage here: https://github.com/zeit/next.js/blob/master/examples/with-redux https://github.com/zeit/next.js/blob/master/examples/with-re...
  - beezischillin 10y ago
    Thank you, I've seen the clock one on the website, however the thing that doesn't exactly click with me is how would you, for example handle multiple users with server-side rendering, where each user only has access to their own state data? I'm pretty clear on how to use client-side react with redux, it's just the server side part that would include stuff like user authentication seems confusing to me so far, since I haven't seen a clear implementation of that yet. Thanks!
    - cstrat 10y ago
      I have been trying to work this out myself too. Would love to see some examples on how to address this. The challenge seems to be that while the server side rendered bit would work fine - it could query a DB locally after authenticating a users cookie (for example)... If the client routed to a page (not using the server rendering) - you would need to have duplicated code to handle how the client can fetch that data, as it cannot query the DB directly.
jorjordandan 10y ago
The link is wrong for the Koa server example. It points to the Hapi example, it should point here: https://github.com/zeit/next.js/tree/master/examples/custom-server-koa https://github.com/zeit/next.js/tree/master/examples/custom-...
hoodoof 10y ago
>> "More than 3.1 million developers read our announcement post of Next.js. " Really? 3.1 million developers? I'm not saying I don't believe, but wow, how? edit: actually I am saying either I don't believe or you've miscalculated somehow.
- stocktech 10y ago
  They're probably just reporting google analytic numbers. I don't think that's unfair.
  - hoodoof 10y ago
    Even so, 3.1 million page views?
    - aioprisan 10y ago
      Over a few months? Plausible.
zackify 10y ago
If anyone wants to see, we are using next.js 2.0 on https://kimmel.com https://kimmel.com. Yes, the designer added way too many fonts, but overall it's a really nice static site thanks to next and the programmatic api allowed me to generate blog post pages!
n3bs 10y ago
How does this compare to react-boilerplate? I've been using react-boilerplate recently and it's been solid so far.
- geniium 10y ago
  This seems to be totally another approach. More like an opinionated setup where you can get a project set up and ready in a few line of codes. Very interesting approach! What are the pros and the cons? Someone that has used both should help us here.
  - scottmf 10y ago
    I've used both and prefer next.js. Granted I'm using GraphQL but I'd prefer it regardless. RBP is actually more opinionated. It's "best* practices to the extreme" at the cost of productivity and lots of boilerplate. It's also a little hostile towards server-side rendering. I enjoyed RBP and learned from it, but we switched to next.js (with styled-components and apollo-client) and things have been far smoother. To be honest I can't really think of a reason to use RBP over Next.js. The creator @mxstbr has tweeted positively about Next.js, has other projects to look after (e.g. styled-components), and hasn't updated it since January, so I'm not sure RBP has much of a future anyway.
geniium 10y ago
Very promising!
kbody 10y ago
I would love and use this if it was using Riot instead of React.
TeeWEE 10y ago
Looks cool. But everybody who thinks of building a webapp, try todo it without react if you don't need it. For example https://next-news.now.sh/ https://next-news.now.sh/ is MUCH MUCH slower than normal hacker news. And its also much more difficult to maintain, and less future proof. Greetings
- foxylion 10y ago
  It is so much slower because it uses another API which requires multiple requests to get the same data.

627 points by tbassetto 10y ago

Crazy to me how people rebuild a simple HTML page and "navigate around" it as a passable performance test. What is going wrong with web development? Why, god, why?

adgasf 10y ago
It has live updates and page pre-fetching.
mateuszf 10y ago
How many other web frameworks with support for "automatic code splitting, routing, hot code reloading and universal (server-side and client-side) rendering" do you know?
- megous 10y ago
  All sound like solutions to self-created problems.
  - 0x142857 10y ago
    programming itself is a problem.
  - watty 10y ago
    There are tasks that can be completed quicker with web frameworks and tasks that can be completed quicker without them. They aren't a solution for every task. I'm not sure why people struggle so much and fight abstractions so much but I guess that's a sign a techie is getting "old".
    - megous 10y ago
      Struggle and fight abstractions? Some abstractions cause more trouble than they solve, and then create solutions to their own problems on top. That's the point. Older techie might have seen more abstractions, and choose more wisely the lesser complicated one for the job.
    - pg314 10y ago
      > a sign a techie is getting "old". Some of those "older" techies have gotten a wisdom that only comes with experience.
    - K0SM0S 10y ago
      This talk is incredible food for thought: On the spectrum of abstraction by Cheng Lou (react-europe 2016) [1] If you've read some of the classics, such as Structure and Interpretation of Computer Programs (1979, Gerald Jay Sussman and Hal Abelson) [2], this talk is a really interesting look at the state of affairs on abstraction circa 2016. [1]: https://youtu.be/mVVNJKv9esE https://youtu.be/mVVNJKv9esE [2]: https://mitpress.mit.edu/sicp/full-text/book/book.html https://mitpress.mit.edu/sicp/full-text/book/book.html
    - coldtea 10y ago
      >I'm not sure why people struggle so much and fight abstractions so much but I guess that's a sign a techie is getting "old". Yeah, it's a sign they are older, and have seen the same shit play again and again, and starry eyed newcomers fall for every new fad with shit-eating grins...
  - akanet 10y ago
    I don't think this is a good HN comment. If you disagree that these are useful attributes for a platform to provide, please explain so that we can reason about your position. Condescending to people's earnest work isn't a virtue we should promote.
    - matt4077 10y ago
      It's a pretty good argument: the three features mentioned as advantages over static or server-rendered html only exist to mitigate problems created by the SPA structure itself. It's like touting "fast battery charging" as an advantage of a Tesla over a Porsche.
      - nilliams 10y ago
        I don't agree, but let's break this down, comparing to a traditional app in Rails/Django that renders HTML server-side, then progressively enhances with a sprinkling of JS. > automatic code splitting By code-splitting we implicitly mean we're also managing dependencies (e.g. via require() or import statements). In a traditional server-rendered-app, you can achieve something similar to code-splitting by manually breaking up your script tags across pages as needed, but you lose dependency management. With code-splitting you get both, and your bundles are going to be better optimised than if you hand-picked script-tags (at least that's the promise of automatic code-splitting, and it'll only be enhanced as 'tree shaking' techniques mature). > routing Really, this should say 'filesystem-based routing', which you don't get for free in rails/django afaik. Granted you get it in old-school PHP, which I think Next is open about wanting to copy the 'ease' of. I think that's cool. > hot code reloading You don't get that in server-rendered frameworks. It's a hugely pleasurable boon to development to not lose all your page state when you just changed a bit of CSS or JS that shouldn't affect state. It even won't destroy CSS or HTML text-content changes I made with the Chrome devtools, which would get lost if I used something like 'live reload' to reload the page with a server-rendered framework. > universal (server-side and client-side) rendering It's not the server-side rendering that's the advantage, because like you say ... we already had that. It's the fact it's both. The initial load is server-side, which is a big win for mobile devices especially (remember when Twitter switched from an SPA back to server-side-rendering to improve 'time-to-first-tweet'). But every subsequent page load is done by requesting the minimal data needed and rendering client-side, which is faster than loading a full page from the server.
  - mixedCase 10y ago
    Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. When well-executed, it provides a better experience to the average user. Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time. Does the tooling suck donkey ass? Yes. Does it have serious tradeoffs to consider? Yes. But in many cases it's the right thing to do to have a higher-quality product.
    - empthought 10y ago
      > Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. This isn't true. Have a look at how the GitHub UI is implemented. [1] There's even a name for this approach. [2] [1] http://pjax.herokuapp.com http://pjax.herokuapp.com [2] http://roca-style.org http://roca-style.org
      - NoGravitas 10y ago
        Pjax/hijax is absolutely the right way to go for content-focused sites.
    - Touche 10y ago
      > Automatic code splitting, routing and client-side rendering are necessities to provide websites that don't require a full screen repaint and server request to change small stuff. Client-side routing is rarely used to change small stuff. It's usually used to replicate an entire page transition. > When well-executed, it provides a better experience to the average user. It's rarely well-executed. Client-side routing means you have to replicate every feature of browser routing, and most frameworks get it wrong. Numerous issues like not supporting cmd/ctrl+click to open in a new tab, ext, are common. > Hot code reloading is a way to test changes without dropping current state, something that's extremely handy during development to avoid wasting time replicating said state every time. Like the GP said, this is a self-created problem. Separate development pages to test out small parts of an application is how you avoid replicating state. But today's web development environment is so wrapped up in tooling and build complexity that creating a new page to test out a small part of the application is actually really hard to do.
bpizzi 10y ago
Who said that it was only meant for reimplementing simple HTML pages? It's a lightweight framework around React, and React was made for anything but for simple HTML pages. Crazy to me how some people will never miss an occasion to bash experimentations.
- Touche 10y ago
  The example in this article is Hacker News, which is simple HTML pages. The example (and other similar SPA Hacker News examples) is worse than the real Hacker News.
  - spion 10y ago
    So how is it worse?
    - Touche 10y ago
      Slower.
      - deleted 10y ago
        [deleted]
      - spion 10y ago
        Speed is more or less the same here...
  - bpizzi 10y ago
    There's a logical flaw in that answer: I said 'this was not made only for simple html page', emphasize on the 'only', and your counter argument is 'there's at least one example of it being used for simple html page'. At this point I could still respond with 'this was not made only for simple html page', emphasize on the 'only'.

tonetheman 10y ago

Frameworks made of frameworks... frameworks all the way down

pweissbrod 10y ago
The word framework is broad and I dont see this as the same kind of thing as React. This marries set of frameworks which work well together and provides a opinionated but clean approach to building larger apps more efficiently/consistently. Similar to eiffel, MEAN, jHipster etc. There is great value in this kind of bundling effort for those of us less-experienced with the frameworks who need help getting a proper start
weka 10y ago
In 3 years, we'll go back to square one! :-)
frik 10y ago
I would rather favor libraries over frameworks - more freedom, less worries.

ergo14 10y ago

Why in the world everything needs to be made with react that makes it incompatible/hard to integrate with any other frameworks?

okket 10y ago
IMHO because react is designed this way. It makes it easy to add to existing content, it is not an "opinionated" framework. This is great for getting quick results, but not for compatibility, easy source code navigation, etc. You can add these constraints later, but you will be on your own island. Maybe sometime a standard ("best current practices") emerges...
- ergo14 10y ago
  At this point I have to use react more or less. It is a ghetto. React vs the world. I'd like to have more than one option to use here.
  - bpizzi 10y ago
    Obvious solution to your problem: write your own js component library. And don't forget to submit it to the HN crowd when you're done, you should get a very positive feedback.
    - ergo14 10y ago
      There are other solutions out there: polymer, skatejs, x-tags, vue, angular, aurelia. Some of them are more interoperable with others and can be use in multiple projects using different frameworks - I'd like this to be the norm.
      - bpizzi 10y ago
        So, to go back to your original post ('Why in the world everything needs to be made with react'): not everything is made for/with react, and you provided really good counterarguments againts yourself (polymer, vue, angular, etc). I still don't get the point you were trying to make (no offense really).

vincivince 10y ago

Nice work.

Polarity 10y ago

nice, thx!

sergiotapia 10y ago

Next looks very interesting and feels very much like the PHP of old where stuff just works with sane defaults. Very cool stuff. My one criticism of this is: Component CSS is cancer. I've worked on a large scale javascript project and it was riddled with duplicated CSS in every component, all in the name of being conflict-free. You know what I call that? Not knowing how to scope your styles properly with something like BEM. http://getbem.com/ http://getbem.com/

Kiro 10y ago
I completely disagree. After working with component CSS I vomit when I see any CSS not encapsulated to one single component. I don't want to change a global CSS declaration and accidentally change something completely different. You can always import the stuff you really want shared.
- tlrobinson 10y ago
  Yeah, I'm still not sure what the "best" solution is but I'm pretty sure it will allow for better composition and static analysis than "global" CSS.
- WA 10y ago
  Do you have some reading material on how to do this properly? Because I never worked with component-based CSS yet, but want to have a look at it and wondered about what your parent posted, too.
  - idreyn 10y ago
    There's a set of libraries like Aphrodite, Glitter, jsx-style, and JSS that help you do this. I'd look at some benchmarks [1] and do some comparison before you make a decision yourself. I've worked extensively with Aphrodite (disclaimer, my employer maintains it) and have found it works with React to make a pretty good workflow for SPAs. It does require some buy-in from everyone involved with the codebase since you'll have Aphrodite-defined styles clashing with stuff in external stylesheets, and there are occasional edge cases where you'd like to use some crazy CSS selector that Aphrodite doesn't support, but this is often a sign that you should be restructuring your component in a more straightforward way. The style reuse and composability story is very good, since all styles are wrapped around bare JS objects which are super easy to manipulate and the ES6 spread syntax [2] makes it all look very elegant. If it's important to you to keep styles and markup in different files, you can do that too as long as you're happy giving them all .js/.jsx/.ts extensions. In general it is frustrating to me that total buy-in into the React model comes at the cost of support for actual standards like Web Components, but I never want to write UI in a non-declarative way again so I'm hoping someone smarter than I can figure out how to bring these two worlds together so we can let the browser properly namespace our CSS rather than relying on randomly generated class name infixes as Aphrodite does. [1] https://engineering.hellofresh.com/the-css-in-js-battle-89c34a7a83ea#.cae5q4lkd https://engineering.hellofresh.com/the-css-in-js-battle-89c3... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

jakobloekke 10y ago

I'm curious: Where do these anti-React (anti-spa?) people come from, technologically? Rails? Php? Some .Net stack? Do you think the web Peaked with Perl-based CGI-scripts? I've been in this game for many years, and to me, any technology that speeds up development cycle time is an improvement. There's a reason React is so popular.

pweissbrod 10y ago
In the 2000s we used ASP.NET webform user controls and java struts in a VERY similar approach to what react calls a "component" which is great because concepts such as composition and event percolation come naturally and make a great amount of sense (to me). There were many developers who were raised to strive for segregating logic from display (keep your js away from your HTML) and that MVC was a universal solution to front-end development. From what I've seen angular does these things very well and feels more natural to teams where this mindset is well-established.
kuschku 10y ago
> any technology that speeds up development cycle time is an improvement. The problem is that for many, react does not do that – because you need npm, webpack, babel, systemjs, and so on and so on. We come from a world where you have a simple .gradle config file, and you press one command, and it installs and everything just works. No need to configure thousands of transpilers, no need to handle constantly breaking dependencies, because people keep their API stable for years, some even decades (see Bouncycastle, e.g.), etc. Coming from this style of development where tech actually works well, and is stable, to the JS world of React where everything constantly breaks, is very complicated and over enterprise-ified, etc is quite annoying. Obviously, on the other hand, the React world provides other massive advantages, such as quick iteration, innovation, etc – but the work to get something working with constant quality for years is entirely different. Because you’ll have to fork all your dependencies, because those won’t be stable. So if you want your product to be included in Debian Stable, you don’t want to use React. Because you’ll end up forking and maintaining every single of your dependencies-.
- treehau5 10y ago

tabeth 10y ago

Ah, so close. I really just want something like Handlebars, with a generic adapter for any language for compilation. Then you can load with javascript a client-side controller if you want to add in interactivity. --- To expand, I think the idea solution would be the following: 1. Server side view, let's call it "Bars" 2. Bars can be written on the front-end or back-end, does't matter. It'll compile to BarsHTML. 3. If you write Bars on the back-end, then when you serve your page it'll compile Bars into BarsHTML. 3a. If you want to sprinkle JS onto Bars, you'll use BarsControllerJS, an adapter to whatever framework of your choice, to manipulate it. The main difference between this and manipulating the DOM is that the interface to do this is not DOM centric. 4. If you write Bars on the front-end, it's the same as (3), but you get (3a). If you decide you'd rather do server side rendering, you literally just move your views to the server. The controller is already abstracted, so you wouldn't need to do anything else.

bhurlow 10y ago
You can use Next.js to do server-side only rendering. It uses React idioms for rendering in favor of vanilla templating
laktek 10y ago
Not exactly the same, but what you describe is similar to the concept of components in Pragma (a project I'm working on). I will write a more detailed post when it's ready for release. Meanwhile you can check the "How Pragma works" in the intro blog post http://www.laktek.com/2016/11/29/introducing-pragma/ http://www.laktek.com/2016/11/29/introducing-pragma/
gniquil 10y ago
I think you miss the point of having Next.js being based on React. Although I think handlebars/htmlbars are great (I'm a big ember user), the cool thing about React is it's component based. So pretty much everything you mentioned above, replace BarsHtml to react components, you have Next. However, the react components though in my opinion is much better than handlebars. It is more powerful, more flexible and at the same time more disciplined.
ramses0 10y ago

tambourine_man 10y ago

I guess I became way too cynical. I though it was a satire, based on its name. Maybe there is some hidden self deprecating joke that went over my head, but Next + JS + 2.0 seemed too buzzwordy to be true. The tech looks interesting. Still looks to me like a lot of stuff that I don't understand why I would need, but that's an old rant I have with the curent js ecosystem.

mike-cardwell 10y ago

I rebuilt https://www.emailprivacytester.com https://www.emailprivacytester.com in NextJS v1 - https://gitlab.com/mikecardwell/ept3/tree/master https://gitlab.com/mikecardwell/ept3/tree/master - Was a pleasure to use. My main problem though was that I couldn't add custom routes for API end-points, so had to split the application into a frontend (in Next) and backend express app. Looks like v2 fixes this. I will definitely be updating to take advantage.

xutopia 10y ago

There is something I do not understand. Why does `<div>` not create a syntax error in the Javascript examples? Is there a pre-processor?

SlyShy 10y ago
Yes, JSX considers that valid syntax.
developerdanny 10y ago
it uses JSX which allows you to use HTML in JS :-)
ksherlock 10y ago
babel, typescript, and bublé can convert jsx into javascript.
Hnus 10y ago
Take a look here https://facebook.github.io/react/docs/react-without-jsx.html https://facebook.github.io/react/docs/react-without-jsx.html

migueloller 10y ago

We recently used Next.js to build out an MVP. It was a pleasure to work with. For those wondering what this is, it's basically a slightly more opinionated Create React App [1]. Here are some of the benefits: - No need to setup complicated tooling - Server and client (SPA-style) rendering out of the box - Filesystem for routing using the `pages` directory - `getInitialProps` component lifecycle to encapsulate data requirements per component - Automatic code splitting for each route - If it works with React, it works with Next.js Here are some of the issues we encountered: - Importing non-JS files from `node_modules` (like normalize.css) was not as simple as it could be (#1245 [2]) - Animation transition between pages is still being worked on (#88 [3]) - There are still some inconsistencies between server and client that could improve, like running Webpack on the server (#1245 [2]) - Doing proper scroll restoration when routing (#1309 [4]) We will continue to use it as long as it keeps letting us move fast without having to worry about spending hours setting up React tooling. [1] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [2] https://github.com/zeit/next.js/issues/1245 https://github.com/zeit/next.js/issues/1245 [3] https://github.com/zeit/next.js/issues/88 https://github.com/zeit/next.js/issues/88 [4] https://github.com/zeit/next.js/issues/1309 https://github.com/zeit/next.js/issues/1309

threatofrain 10y ago
> For those wondering what this is, it's basically a slightly more opinionated Create React App. Does that mean the top benefit of next.js is to alleviate difficulties with Webpack + Babel + etc?
- migueloller 10y ago
  I wouldn't say it's the top benefit but it is a benefit indeed! You don't have to worry about setting any of those up unless you want to customize them. You shouldn't have to because they come with sane defaults (i.e., Babel has support for latest ES and the Webpack config takes care of everything for you). For example, the only custom change we had to make was to add Webpack's `DefinePlugin` to expose `.env` variables in the client. It was extremely easy though (3 LOC) and we didn't need a full Webpack config. See: https://github.com/zeit/next.js#custom-configuration https://github.com/zeit/next.js#custom-configuration

andrewgleave 10y ago

The MP4 included in the page causes graphics corruption and locks my MBP in Safari 10.1. Anyone else seeing this? Save your work before trying, though.

asadlionpk 10y ago

I have recently migrated my boilerplate code to Next.js and it's awesome to work in. Previously I had my own code-splitted/server-side rendering setup but next does it better!

swlkr 10y ago

I used next on a side project, zero boilerplate is refreshing.

Stamy 10y ago

Vue.js ecosystem has alternative as well. It is Nuxt.js (https://nuxtjs.org/ https://nuxtjs.org/)

marvindanig 10y ago
Super! I love the way VueJS community plays its cards in this otherwise corporate driven turf of open source-y stuff. Will take a look at nuxtjs next.
- deleted 10y ago
  [deleted]
shaydoc 10y ago
It is most excellent. Great little intuitive routing convention, plus plays well with express
tribby 10y ago
nuxt is great but I'd wait until the 1.0, which I would guess is coming in a couple of months. it doesn't support response streaming yet, and a few other things that may have been addressed since I last looked..

mmgutz 10y ago

If I'm understanding correctly, seems like this is back to the old days when routes mapped directly to pages. From experience with ASP, it is not a good thing. You need to separate the routing from the presentation ala MVC. I can see the benefit if next.js is intended to be create-react-app++.

smdz 10y ago

I don't understand why people here are comparing Next.js to create-react-app. I see Next.js primarily focusing on server-rendered React and then it also supports client-rendering. I see create-react-app is primarily focused on client-javascript. Am I missing something?

deleted 10y ago
[deleted]
akhilcacharya 10y ago
Yeah, to me it reminds me more of a react-only Meteor without the baked-in DB
codecurve 10y ago
Because both are opinionated ways to get a React project going without having to configure any tooling yourself. Next.js also focuses on client side JavaScript, but happens to render at the server first, so that there's something there for users before the client bundles have downloaded, parsed and been executed. You could think of it as a more configurable create-react-app that supports server side rendering, with a convention over configuration approach to pages and links.
- williamle8300 10y ago
  > You could think of it as a more configurable create-react-app that supports server side rendering, with a convention over configuration approach to pages and links. You are a poet, sir. Best answer.

anupshinde 10y ago

It would be great to see TypeScript support with NextJS out of the box. It can be done with some work today. Inspired by an earlier(probably first release) of NextJS, I had attempted TypeScript and server-rendered react here: http://www.anupshinde.com/posts/react-typescript-server-render/ http://www.anupshinde.com/posts/react-typescript-server-rend...

styfle 10y ago
Very cool. I wrote a SSR React + TypeScript boilerplate [0] and have been trying to keep it updated, but I just found out next.js has a TS example[1] so now I think I'll switch over. [0]: https://github.com/styfle/react-server-example-tsx https://github.com/styfle/react-server-example-tsx [1]: https://github.com/zeit/next.js/tree/master/examples/with-typescript https://github.com/zeit/next.js/tree/master/examples/with-ty...

ndreckshage 10y ago

Next is great. I would love to deprecate my SSR starter kit - Sambell - https://github.com/humblespark/sambell https://github.com/humblespark/sambell - once it supports a layout file, for animated transitions, etc. Right now, React Router seems fundamentally more powerful as a SPA framework.

symboltoproc 10y ago
just fyi it's possible to change the commit history, so no "proof" ;)

EGreg 10y ago

Not to toot our own horn, but I wanted remark on how similar the issues we have had to deal with in our own framework (https://qbix.com/platform https://qbix.com/platform), since 2011. When we built it, we had out of the box: + Tools (our name for components) + Pages (to support all web standards) You place tools on pages, the framework does the rest: + It loads JS and CSS on demand + It adds/removes tools from pages automatically as you navigate + Support for web standards, HTML5 history w fallbacks, etc. + Tools can contain other tools + You have events for when all parent tools have activated (onActivate) and when all child tools activated (onInit) + JS and CSS had to be namespaced by convention from day 1, by module and tool name. We use events instead of virtual DOM. We didn't use fancy JSX or preprocessors to do it. It's all written in ES4 JS and runs on every modern browser and IE8. But the problems are very similar in scope.

laktek 10y ago
Any links to sources of sample apps built with it? Interested to see how you compose pages with Tools.
- EGreg 10y ago
  Sure. Here is a full app built on it: https://customizemypic.com https://customizemypic.com - it has a GITHUB link Here is a showcase of what is possible: https://vimeo.com/208438090 https://vimeo.com/208438090 And here are some tutorial videos on pages and tools: https://qbix.com/platform/tutorials https://qbix.com/platform/tutorials

egeozcan 10y ago

I wonder how hard it would be to programatically cache a Next.js app with a ServiceWorker to make it also work offline. I guess one could copy the logic from the prefetch script as it makes network requests like this: http://i.imgur.com/c3H176u.png http://i.imgur.com/c3H176u.png

fourstar 10y ago

I want to use this but I'm hesitant to do so for a project that's backed specifically by a single company. Can someone help alleviate my concerns? I had to verify my email address and accept the TOS before I could use their command line tool.

migueloller 10y ago
Next.js is entirely open source and is separate from the product the company offers. Their command line tool is one of the interfaces they provide to use their product but is not needed to use Next.js.
- fourstar 10y ago
  Awesome -- thanks! This looks fun to play around with.
- holtalanm 10y ago
  saying something is entirely open source is useless if their License Agreement contains riders like Facebook's React license agreement does. I just don't trust their modified License Agreement.

jonknee 10y ago

This page has some huge issues loading resources. I kept it open as a tab to dive into later and noticed it was still spinning after a long time... I refreshed with Developer Tools open and after 2 minutes over 100MB had been transferred! It appears the screencast video is to blame, it is not only huge (~70MB), but it keeps getting downloaded instead of just replaying. I just checked the console again and the page is now up over 300MB downloaded. Glad I wasn't on mobile data! Update: I downloaded the video and ran it through ffmpeg to see how much space could be saved... Original size 72.2MB, new size 1.7MB. Screencasts obviously compress very well, but this was pretty surprising. You could easily optimize this down further and probably half the size yet again. ffmpeg -i hello-world_2.mp4 -vcodec libx264 -preset veryfast smaller.mp4

grigio 10y ago
I confirm, the video is too big
timneutkens 10y ago
We're on it, thanks!
- eclark 10y ago
  The size is much smaller. As for downloading multiple times: I don't think it's happening though it looks like it. The server is sending 206 Partial Content for the video. This is why the file downloads multiple ranges if the page is left open for a while. The first response if for a chunk of the file. The next few are for different chunks. Then it repeats. ~8 Mins on the page and I have 5 downloads of the hello-world_2.mp4 that went to the server. I have 4 that were able to be served from the disk cache.
deleted 10y ago
[deleted]
asaddhamani 10y ago
It really is a sad state of affairs that this is unsurprising.
10y ago

grumblestumble 10y ago

i know this is a tangent and not directly related to next.js, but the react ecosystem's insistence on coming up with increasingly convoluted and self-defeating stories around how to handle CSS instead of just using the tool the way it's intended is pure insanity. the emphasis with styled-jsx favors encapsulation with no real thought put into external overrides or customization, which makes this a non-starter for creating vendor components that are actually usable. compare https://github.com/zeit/styled-jsx https://github.com/zeit/styled-jsx, which can only euphemistically be called a naive implementation, with the documentation around custom properties, with the styling documentation at https://developers.google.com/web/fundamentals/getting-started/primers/shadowdom https://developers.google.com/web/fundamentals/getting-start....

beezischillin 10y ago

Awesome stuff. Just a quick question that doesn't click with me: how would you use Redux to manage application state for multiple users, server-side? If someone could drop me some examples or articles on this, I'd be really thankful!

pierrehenrit 10y ago
Check this: https://github.com/kirill-konshin/next-redux-wrapper https://github.com/kirill-konshin/next-redux-wrapper and usage here: https://github.com/zeit/next.js/blob/master/examples/with-redux https://github.com/zeit/next.js/blob/master/examples/with-re...
- beezischillin 10y ago
  Thank you, I've seen the clock one on the website, however the thing that doesn't exactly click with me is how would you, for example handle multiple users with server-side rendering, where each user only has access to their own state data? I'm pretty clear on how to use client-side react with redux, it's just the server side part that would include stuff like user authentication seems confusing to me so far, since I haven't seen a clear implementation of that yet. Thanks!
  - cstrat 10y ago
    I have been trying to work this out myself too. Would love to see some examples on how to address this. The challenge seems to be that while the server side rendered bit would work fine - it could query a DB locally after authenticating a users cookie (for example)... If the client routed to a page (not using the server rendering) - you would need to have duplicated code to handle how the client can fetch that data, as it cannot query the DB directly.

jorjordandan 10y ago

The link is wrong for the Koa server example. It points to the Hapi example, it should point here: https://github.com/zeit/next.js/tree/master/examples/custom-server-koa https://github.com/zeit/next.js/tree/master/examples/custom-...

hoodoof 10y ago

>> "More than 3.1 million developers read our announcement post of Next.js. " Really? 3.1 million developers? I'm not saying I don't believe, but wow, how? edit: actually I am saying either I don't believe or you've miscalculated somehow.

stocktech 10y ago
They're probably just reporting google analytic numbers. I don't think that's unfair.
- hoodoof 10y ago
  Even so, 3.1 million page views?
  - aioprisan 10y ago
    Over a few months? Plausible.

zackify 10y ago

If anyone wants to see, we are using next.js 2.0 on https://kimmel.com https://kimmel.com. Yes, the designer added way too many fonts, but overall it's a really nice static site thanks to next and the programmatic api allowed me to generate blog post pages!

n3bs 10y ago

How does this compare to react-boilerplate? I've been using react-boilerplate recently and it's been solid so far.

geniium 10y ago
This seems to be totally another approach. More like an opinionated setup where you can get a project set up and ready in a few line of codes. Very interesting approach! What are the pros and the cons? Someone that has used both should help us here.
- scottmf 10y ago
  I've used both and prefer next.js. Granted I'm using GraphQL but I'd prefer it regardless. RBP is actually more opinionated. It's "best* practices to the extreme" at the cost of productivity and lots of boilerplate. It's also a little hostile towards server-side rendering. I enjoyed RBP and learned from it, but we switched to next.js (with styled-components and apollo-client) and things have been far smoother. To be honest I can't really think of a reason to use RBP over Next.js. The creator @mxstbr has tweeted positively about Next.js, has other projects to look after (e.g. styled-components), and hasn't updated it since January, so I'm not sure RBP has much of a future anyway.

geniium 10y ago

Very promising!

kbody 10y ago

I would love and use this if it was using Riot instead of React.

TeeWEE 10y ago

Looks cool. But everybody who thinks of building a webapp, try todo it without react if you don't need it. For example https://next-news.now.sh/ https://next-news.now.sh/ is MUCH MUCH slower than normal hacker news. And its also much more difficult to maintain, and less future proof. Greetings

foxylion 10y ago
It is so much slower because it uses another API which requires multiple requests to get the same data.