yarn create next-app my-app & cd my-app & yarn dev
and be up and running in 2 minutes.
-Is it the same thing as nuxt js but different?
- Yarn? I thought that npm was the thing to use again.
- How does yarn know that “create next-app” command? Perhaps some yarn install globally thing?
- Does it include typescript support or is it javascript only?
- Which node version is needed? And if I switch, is that create next app still available then?
- How many things are transpiled? Are there any other concepts i need to understand?
- What is the testing framework of choice these days?
- How long will this framework be hip? Am i talking about months, a few months, a year, two years? Hip is important, i (or new employees) dont want to work with software which is considered old fashioned.
- Apparently i need this layer on top of react client side rendering. Another concept.
- Full control over babel or webpack is exactly the thing which makes it complex. It is probably easy to get started and then you have to make that little tweak on a changed babel plugin to make “it” work.
- Is frontend and backend react the same? As in: will it share the same babel config and will every node function be available on the client side and vice versa?
Even if every answer is positive, it is such a huge amount of stacked concepts and technologies.
Dont get me wrong, i like programming in javascript / typescript. I think the programming is fun, but fixing the damn tooling and having debates about it sucks.
NextJS is a library for doing server-side rendering in your React app. I've never touched Vue, so I don't know if that's what nuxt js does
> Yarn? I thought that npm was the thing to use again.
They're fairly interchangeable and it doesn't matter much these days.
> How does yarn know that “create next-app” command? Perhaps some yarn install globally thing?
Yeah it checks the registry of create-* packages and installs the relevant ones.
> Does it include typescript support or is it javascript only?
Yep, by default can use TS with NextJS. I only use TS when possible. Going back to vanilla JS is a horrifying thought!
> How long will this framework be hip?
React is probably the most popular front-end framework and pretty beloved. It's used seemingly everywhere these days. Since SSR is such an important use-case for websites, I'd wager that combined with how prevalent React is, NextJS will be around for a long, long time.
> Full control over babel or webpack is exactly the thing which makes it complex. It is probably easy to get started and then you have to make that little tweak on a changed babel plugin to make “it” work.
Anecdotally, I've used the default configs for create-react-app starters, NextJS, or Electron Forge starters and haven't needed to modify anything.
Yes.
> Yarn? I thought that npm was the thing to use again.
Yarn has many features that npm doesn't - plugins, constraints, PNP, zero installs, workspaces, etc.
> How does yarn know that “create next-app” command? Perhaps some yarn install globally thing?
You can do yarn dlx or npx create-next-app. It will temporarily install and run the package or command.
> Does it include typescript support or is it javascript only?
Typescript support is as easy as changing your file names, installing typescript, and adding a tsconfig. You don't need to set up anything. Next does it for you on the first run.
> Which node version is needed? And if I switch, is that create next app still available then?
You are cool with current LTS and previous LTS (from my testing).
> How long will this framework be hip? Am i talking about months, a few months, a year, two years? Hip is important, i (or new employees) dont want to work with software which is considered old fashioned.
Next has been supported for years. Vercel is the company backing next for their platform so I would say about the same time as vercel. Given they got funding this year, don't think they will die soon.
> What is the testing framework of choice these days?
jest
> How many things are transpiled? Are there any other concepts i need to understand?
SSR. There are few concepts you will have to learn to actually take benefit of it (getServerSide props, getStaticSideProps, etc) but out of the box, you don't need to do anything different. The routing is already included so that's one less thing to worry about. Next does automatic static optimization (unless you do something stupid with your root app). You are benefiting without doing any work.
> Full control over babel or webpack is exactly the thing which makes it complex. It is probably easy to get started and then you have to make that little tweak on a changed babel plugin to make “it” work.
Most things will work via the next plugins. It will be a rare case where you have to set up your own server. You can take full control when you want.
> Is frontend and backend react the same? As in: will it share the same babel config and will every node function be available on the client side and vice versa?
Next builds your app and responds with either fully static views or via pre-hydrated views hydrating on the client-side. Look up hydration in react.
The project I work on uses gulp(probably is ancient already and I have to use soemthing cooler). With gulp sometimes when I switch branches of my project it will crash , I understand how it works and why it happens so I restart it , but someone that does not understand the "magic under the hood" will not know what to search for, what to google for etc. Same for react or angular, if you do not know what is happening under the hood you will eventually cause performance issues(similar if you don't understand how CPU/memory works)
My point is that if the abstractions are not perfect you will sooner or later (probably sooner) have to understand them , read the code etc.
Support for others is inbuilt.
Why transpile to single files? It will be faster to have many smaller files for http2 speed up.
Bootcamp also teaches those concepts nowadays. They are different than what they used to be. Check frontend masters, egghead etc.
I can do this too: without the "modern frontend" all I had to do is open my code editor.
Bonus: Next's built-in API support makes building quick APIs for your project (and its static/hybrid/dynamic) data loading a breeze. While not suited for everything, at the very least, Next and Airtable can get your POC/MVC/prototype running in a day.
The few times I tried to build something in Gatsby I was bogged down in mediocre documentation and a mountain of (maybe?) necessary plugins. I don't know.
Not sure how to feel about Gatsby's GraphQL-first approach either.
Forcing everything to go through graphql is also a pain and adds an unnecessary indirection that requires a million extra dependencies.
Perhaps it was just that Gatsby felt closer to react-static’s model and it was more readily apparent how to adapt a react-static site to Gatsby with as few changes as possible, using their createPage api to replace the route config in react-static and bypassing all the GraphQL as described in https://www.gatsbyjs.org/docs/using-gatsby-without-graphql/ - I didn’t have time to do a detailed comparison of frameworks or rebuild large parts of the site.
I was pleasantly surprised how quick and easy the migration was, took me about 90 mins for a site with about six templates and Gatsby seems to build faster and has a much better ecosystem of plugins etc. I wrote up the process at a high level at https://github.com/react-static/react-static/issues/1203#iss... if anyone is interested in the specifics
Did I understand correctly that next.js isn’t just a static site generator and ideally you have a server side component too? This was what started confusing me in their docs, but perhaps I got the wrong end of the stick.
I’ll have to give next.js a proper look next time I’m building a site from scratch anyway!
It's a dead-simple MD -> HTML generator that uses React for templating. No JS code on the client, unless you import your own scripts.
Some time ago I've decided to rewrite a landing page, written in Node + EJS templates + JQuery, using some kind of static generator. I have always heard good things about NextJS as well as Gatsby, but after some exploration I decided to go with NextJS, since Gatsby seemed more complex and better suited for CMS/other complex websites rather than a simple, light landing page.
The developer experience has been amazing. Plus, I've found an awesome library[0] for dealing with i18n, which completely absorbed the pain of dealing with multiple languages: getting SEO right, make links work, and so on.
Plus, pairing NextJS with PReact, brought my pages first-load size down to ~40KB (external resources excluded), which I didn't think it was possible for something built with React.
The only things that I missed from CRA-like apps were environment variables, which have been added with this release, and a good integration with third-party tools like eslint, typescript and prettier. I did not use typescript because it was just overkill for a simple landing, and I'm launching eslint by hand and in the CI, so I really miss how good the integration is when developing a normal React App bootstrapped with CRA (which has all of this awesomeness out of the box).
However I had to switch to Gatsby because of its superior support for responsive images.
With Next I couldn't find a way to cache all the generated variants of images between builds, which made the site take more than 5 minutes to build.
Gatsby ecosystem seems more mature also.
Imo, simpler if you don't require dynamic views.
https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...
specifically this sub-thread of Mithril's author and myself doing a "Hello World" Next.js perf assessment vs a full-blown ecommerce page:
https://old.reddit.com/r/javascript/comments/ghfyd2/secondgu...
HTML + JQuery, which the hydration approach is compared with, is not used for performance reasons per se. It's used because its easier to reason about and the incremental interactivity that something like JQuery brings to HTML is better than writing your entire frontend in React for something as simple as a blog, for example.
FWIW, the linked site is built with a 300 line custom build script, Rollup, Buble & Terser - even the dev dependencies are extremely minimal. no, it doesnt have the latest HMR hotness, so the DX could be a bit better if i wanted more bloat.
https://us.thermosoft.com/floor-heating/systems/thermotile-m...
* Edit -- initially i incorrectly claimed that this site uses mithril -- (it uses domvm w/SSR, not Mithril)
the link above disables Google Analytics on that page, which would otherwise add an extra 50ms of js time (and would account for the majority of the js on the page).
(it uses domvm w/SSR, not Mithril)
I have been doing the latter for some time with https://github.com/airbnb/hypernova for a rails API.
except it's not "here-and-there". everything down from `<html>` is re-SSR'd and fully re-hydrated on each page load.
here-and-there is what jquery does.
So I loaded up this Next hello world: https://hello-world-app-eight.now.sh/
I can see it downloaded 65kB of compressed JavaScript which is _a lot_.
I worked on a small Mithril SPA and the compressed JS bundle (which includes the CSS) is 41kB. Granted it's not a complex app, but it's certainly not a hello world.
It’s not like the 65kb here is 1kb for every N characters of text. It’s an overly simplified “hello world” example. The point is that you’ll still see sizes of around 65kb even with much more complexity than “hello world.”
How does it replace a client side state management solution?
For those interested, I recently put together these slides https://jamstack-toronto.now.sh/ for Jamstack Toronto that goes more in-depth into this.
tl;DR: static pages for landing pages, static site generation for content like our blog, static dashboard with SWR against our REST API.
Video should be out soon!
I can’t recommend it enough. Although if you’re doing anything with moderate complexity, it is still important to understand what’s going on under the hood. At least, you should know the difference between client side routing and server side routing, and any implications of when you might need to treat one differently than the other. I could see a total noob potentially getting hung up on that aspect of it. But the rest of the ease-of-use outweighs any complexity stemming from SSR, IMO.
parcel build *.html --public-url https://domain/
React/Redux are building blocks to your own "React Stack".
You can use other state libraries (like xState, MobX, etc) depending on your programming style (reactive, state machines, etc.)
It depends what you want to build. You choose how you stack it.
Our experience was that nextjs was way more reliable (had to restart the nuxtjs local server every couple page loads), had much much better support for typescript, and had a more active community and ecosystem which led to questions being answered more easily and things improving at a quicker rate as well.
That being said, I think it's great to have competition and hope Nuxtjs continues to do their thing! I'm particularly excited about the new frameworks being built on top of or adjacent to nextjs (Blitzjs, Redwood, Remix).
The biggest difference is that Gatsby is exclusively static, whereas Next can do static pages, server-rendered pages, or a hybrid of the two approaches.
Gatsby has a GraphQL-based data-fetching system, while Next is much less opinionated. Next gives you a place to do your data fetching, but doesn't dictate how you fetch it. Personally I find Gatsby's GraphQL stuff confusing, but YMMV.
I've also found some of the libraries to be fairly flakey - PWA support breaks my app every-time I've tried to implement it. Lazy Hydration works for a while and then (without any changes) starts dropping random JS errors.
I've noticed a lot of valid Github issues being closed automatically with no attempt by the team to address them - they're simply opened up as questions on a forum that never gets looked at.
What complexities are you running into with router in React? (I'm genuinely curious, I had to use it a few weeks ago for a simple app and found it surprisingly simple).
my favorite feature of `now` is environment variables, and `next.js` 9.4 has even better support. so if using `now`, you store your env vars / secrets in your project on https://vercel.com/ in separate buckets for prod, dev, etc
then on your local environment run `now env pull` and get the latest dev env vars populated in `.env` of your project. this is super great for remote teams where you don't have to share .env files via communication channels / ask someone for the latest variable value
Do you just build your static website and then fetch the data from the browser like React would? Because if so, why would I use Next and not pure React?
SSR frameworks sound very attractive to me due to Kubernetes and hitting internal resources that shouldn't need to be exposed to the world, but I find myself again and again creating gateway services exposing backend services for Ingress.
However, regardless, you should really put it behind a load balancer of some kind, and it's generally best to do your TLS termination in that too.
And you'll want something to manage the application and make sure it's running etc as normal. Usually the cleanest option is to have it wrapped up in a Docker image being managed by an orchestrator, but there's also options like pm2
And of course TLS termination and load balancing aside, you do that in your orchestration platform (so, Kubernetes typically).
That's why Next.js is focused on enabling both eager and lazy pre-rendering behaviors (AOT and JIT). There is no silver bullet :)
If I have a large app that has a few pages which use websockets so I'm not sure if nextjs is something that makes sense for me or if I should just start with create-react-app and go from there.
https://www.datocms.com/blog/offer-responsive-progressive-lq...
We have a huge web based “operating system” and constantly adding more stuff. I spent a couple months architecting and implementing i18n and translations, for example. I looked at GNU language files and other formats and made our own JSON based one.
I tried my hand at static site generation, and it basically takes an existing site and renders certain URLs from the config (including looping through variable values) as a specific browser would fetch them. If you serve different versions of a resource to different browsers (eg mobile browser or css vendor prefixes) you’d have to generate different directories for each one, which can be cleanly chosen by a web server based on the user agent string.
This led to a whole host of issues that made us refactor our framework’s server->client data exports into two parts: session data and regular config data. So a static page would not have any session data. Any experience of being logged-in would have to be added via Javascript or widgets hosted in iframes.
We also have scripts like “combine.php” and “update.php” which minify and combine files, or look at file modification times and set up metadata with timestamps and hashes to use for subresource integrity.
Actually, I would say that the idea of “static site generation” can be a special case of CACHING. To achieve 90% of the benefits, just host your site through a CDN and set your web app server as an origin server. Pages can be rendered on demand and then cached on a CDN. You will have to separate out your session stuff, though! And any dynamicall generated content will need to go under that.
Finally... I would say that all this is actually pointless :) Because you should be building client-first apps. Assume Javascript is available and do all your routing, layouts, header, footer, locally.
There are TONS OF REASONS WHY THAT IS THE FUTURE. The rabbit hole goes much deeper:
https://qbix.com/blog/2020/01/02/the-case-for-building-clien...
If you can be patient enough to cache any state you might have in a special global var that gets serialized during the "server side render", then it works for any JavaScript framework that can rehydrate/reattach to SSR'd HTML.
Fast Refresh seemed impressive in some GIF's in tweets a couple weeks ago.