I understand this is a Vercel framework and probably a great distribution channel for new business and increasing overall revenue. But, I'm a bit disappointed the "next" version is more about Vercel's own internal business agenda. Promoted as amazing "DX" is not really true. It had a better DX compared to the other tools, that's why it grew so popular, but not seeing anything real DX related in version "10". Other tools are starting to do things a bit better.
Analytics, great idea, is a huge disappointment. It's just a Vercel thing and not NextJS, not to mention a "pro/enterprise" paid feature, not cheap either.
A few days ago I saw the YT videos of "future of Svelte" and that video was really about "DX" with no non-sense no BS that just focused on the real next evolution on web/app dev. That DX really resonated with me.
My opinion, I'm not sold on NextJS 10, the "commercial" move kind of turned me off and scares me of platform lock-in, but I'm getting more and more interested into Svelte (v4?) and I'm seriously looking to switch to it from NextJS.
Note: "DX" stands for "Developer eXperience", meaning how joyful, easy it is to get started with the tool and feeling productive.
Whenever the Next.js + Vercel combo gains a new feature, Vercel ensures that it's available in standalone Next.js too – even when deployed to other providers.
That's true for all the features mentioned in the Next.js 10 blog post: Image optimization, Internationalization, but also Analytics.
Since you mentioned the latter: Did you notice that we wrote a detailed documentation page about how to report those metrics to any service of your choice?
Sure, there's obviously a whole UI piece to this as well – but since you interact with Next.js programmatically and there's a quite sophisticated data storage that needs to back all of this as well, Vercel optionally provides you with a pre-built solution.
But again, to be clear: If you want to use Analytics + Next.js elsewhere, Next.js supports reporting them natively – even if not hosted on Vercel.
> Did you notice that we wrote a detailed documentation page about how to report those metrics to any service of your choice?
Perhaps you should link that on the Analytics[0] page instead of directing users to contact the sales team for more information on non-Vercel deployments.
I'm rewriting a bunch of my Vue components into Svelte, and turning my Nuxt (which were previously React/Next) projects into Sapper, and it's a crazy easy process. My Svelte codebase is tiny compared to my Vue codebase.
I'm slightly "worried" about Sapper not being at v1.0 yet but... it's been working great for my MVPs
TL;DW - parts of Sapper may be in a future version of Svelte, but looking to add support for mixed static and dynamic pages and improving development speed to change by using Snowpack.
I'm pretty out of the loop when it comes to Svelte/Sapper. I've looked at it, but never used it. However I did recently spot that they're already working on a successor to Sapper called Svelte Kit. So maybe that's why Sapper isn't at 1.0, and maybe never will be.
I feel the same way. We've switched from React to Svelte at work. Going back to React would be a step backwards for us, so much feels needlessly overengineered with awkward APIs. React was a great improvement on Angular, but luckily things are still moving forward.
Well, this sounds a bit typical JS dev talk. React isn't all that terrible, it's actually quite good and battle-proven. It has great libraries, many devs are familiar with it and if you know it well you can be pretty damn productive with it.
Not to say Svelte doesn't have great innovative features, but I myself don't still feel that tempted to jump into Svelte. What some of us don't like, is the infamous JS churn where libraries are changed every year because "this new one is better".
Some of us are attracted to JS dev because of the rapid evolution and change. React is well-tested and mature, I'm simply stating that for me personally going back to it would be frustrating after developing in Svelte.
React is extremely bloated. I don’t think it can justify its weight on content pages. If all you need are some show hide buttons and a CSS animation, it’s way too heavy. That’s a pretty good reason to look at other tools.
If all you need are some show hide buttons and a CSS animation, do the whole thing in four or five lines of vanilla JS in an inline script tag. You're right that React is the wrong tool for the job, but so is Svelte and so is everything else discussed in this thread.
UI component libraries for Svelte are a little lacking in maturity in my experience. I would recommend including a CSS library such as Bootstrap or Materialize. Tailwind is also popular, but not my cup of tea.
There are good alternatives to React that are as actively developed. There don't seem to be good alternatives to Bootstrap that are nearly as actively developed (excluding CSS utility class libraries like Tailwind).
My team recently evaluated 30-40 CSS frameworks to use with a custom component library, and we were surprised when Bootstrap was the clear winner. Other CSS frameworks have gotten buzz over the years, and we assumed something new and shiny would come out on top, but when we evaluated all of them, we saw sporadic commits, many unresolved issues (e.g., see Bulma issue 3074), small bus factors, inadequate support for keyboard navigation, and other issues.
So using Bootstrap with a newer alternative to React is valid. (Though, we're using Bootstrap with Next.js.)
By all means, stick to your React or Java backend or whatever it is you do if that's where you feel most comfortable. No need to feel so threatened by new alternatives.
Technically any static ui library can easily be turned into reactive components in any of the frameworks. I personally use & recommend Tailwind css, you still need to design/build your UI elements and components but Tailwind helps you speed it up.
How are y'all testing your svelte apps/components? Jest+Testing Lib seems to have issues calculating code coverage and there are few quirks like having to do work arounds to test slots that prevent me from totally switching over.
Good point it would have helped if the clearly mention what's in the open source vs what's paid service tied to Vercel. Alsi I'd like a point by point comparison with Google Analytics for their analytics offering, is that in open source?
The only thing on the list that's related to Vercel is the analytics platform. Even that is clearly listed as something you can leverage via your own provider.
Svelte is the lead of virtualdom less `ui=f(data)` language/framework. It's the only one you can mutation DOM without its program being corrupted (though not sure if you try hard, it could be)
There is only 1 thing that would make me switch from Elm to Svelte is template as a function. Make it compose like functions! So that you can have as many as functions you want. With current Svelte, these functions are bunch of files .. unfortunately.
If UX is user experience, the user flows of a product/application and how people generally feel about using/interacting with it.
The DX is the developer experience. It follows a similar idea. How do you feel about using git? What about Visual Studio Code versus neovim? How do you like using Elm? What don't you like about.
Think about all the libraries or frameworks you use. Some of them clearly offer a better experience than others, these are the types of things that affect the DX.
Take documentation for example, a piece of tech (whether it be an IDE, library, or CLT) with proper documentation full of examples, usage, and recipes is extremely nice. I would favor tech that has better documentation over others, documentation is just one part of the DX. Not the only part, but hopefully you can start to see what can increase or decrease the DX.
> The DX is the developer experience. It follows a similar idea. How do you feel about using git?
To me, how I feel about using (working with) git is git's UX.
How I would feel working on git (were I to do so) would be git's DX.
Now, for a project that has git as part of its expected dev tooling, how I feel about using git in that particular context would be part of that particular project's DX.
It's confusing or always needs further distinction if "UX" when discussing client-side application development is talking about developers. "DX" is useful.
OTOH, when I hear about DX of a software product (especially an open source one), my intuitive understanding is that it is experience of developers working on the product, not of developers that happen to be users of the product (which, if they are the normal users of the product, would just be UX.)
it's a full of crap metric due to the fact that the definition wildly varies among developers. While UX can be quantified by actual metrics (retention, number of steps, accessibility points), DX is nothing but a bunch of opinions.
> Nowadays users browse the web using their phones, tablets, and laptops, yet images are still as a one size fits all. For example: sites load a 2000 by 2000 pixel image, but phones are only displaying it as 100 by 100 pixels.
That's what srcset & <source> were invented for.
> Furthermore, 30% of images on web pages are outside of the initial viewport, meaning the browser loads images that a user does not see until they scroll further down the page.
That's why we now have a loading=lazy HTML attribute
> When using the next/image component, images are automatically lazy-loaded, meaning they're only rendered when the user is close to seeing the image. This prevents loading that 30% of images outside of the initial viewport.
This has been done many times before. For images outside the viewport it's great; for images which are in the viewport, the browser isn't able to discover the image until the JS has loaded and decided which image size to fetch. In my experience this slows down the overall rendering of the page.
I see the Google Chrome team was involved in creating this component so I'd like to know what's different this time, because they have the data.
> Developers can mark images that are in the initial viewport, allowing Next.js to automatically preload these images. Preloading images in the initial viewport has shown improvements to the Largest Contentful Paint by up to 50%.
How can smart preloading work when the image size isn't known until the JS component runs? If we're back to loading the 2000px image then we're losing a lot of optimization.
If they're relying on client hints [1] then we can get as far as an image as wide as the browser window width, but no more - at the price of poor browser compatibility.
Preloading also has its own costs, as it messes with the browser's prioritization of page content. I've found it easy to prioritize something you know is essential and unintentionally increase load time metrics.
> That's what srcset & <source> were invented for.
Next.js is going to be using srcset under the hood, I'm sure. The whole point of Next.js is to make best practices like this defaults, not to do anything groundbreaking and new.
> That's what srcset & <source> were invented for.
next/image makes use of srcset.
> This has been done many times before. For images outside the viewport it's great; for images which are in the viewport, the browser isn't able to discover the image until the JS has loaded and decided which image size to fetch. In my experience this slows down the overall rendering of the page.
>I see the Google Chrome team was involved in creating this component so I'd like to know what's different this time, because they have the data.
No knowledge of what Google contributed to this, but my experience of running Google PageSpeed Insights on many sites is that this sort of optimization does improve the metrics Google measures.
Also, while I agree in part with most of your points, I still think we should give credit to nextjs for making this easy.
Sure, maybe you don't need a library to use srcset. If you are going to run our own custom build processes (or server endpoints) that generate images in a range of appropriate sizes and write the corresponding front-end code, good for you. Next.js has done nothing to stop any of this.
But many (most?) websites don't bother with any of that and just load one giant image for everyone. If there is a tool that makes using optimized images as easy loading one giant image for everyone, I think that's great.
I don't know Next.js but I just spot checked a comparison to see if srcset is an exact subtitute.
- If I'm reading CanIUse chart correctly, it says IE11 isn't compatible.[1]
- syntax of srcset requires manual and verbose specification of different source images. E.g. from MDN[2]:
<img srcset="elva-fairy-480w.jpg 480w,
elva-fairy-800w.jpg 800w"
sizes="(max-width: 600px) 480px,
800px"
src="elva-fairy-800w.jpg"
alt="Elva dressed as a fairy">
- Next.js example[3] is simpler and shorter:
import Image from 'next/image'
<Image src="/profile-picture.jpg" width="400" height="400">
The Next.js post also says that <Image> tag also provides the following dynamic feature: When using the next/image component, images are automatically lazy-loaded, meaning they're only rendered when the user is close to seeing the image. This prevents loading that 30% of images outside of the initial viewport.
Like I said, I'm not an expert. The Next.js Image function doesn't look like useless redundancy with plain HTML5.
Yeah, I mean, screw IE11 users. An unsupported srcset just means that they will not benefit from this enhancement but they will just download a standard size. This is perfectly fine.
As for the syntax, yes, it’s better to always have some generator to create it. WordPress has been doing it for years with a plain `the_image($id)` call.
A better way of saying this is that srcset gracefully degrades for IE11. They will miss out on the benefits, but they still get to use a regular <img /> tag.
> How can smart preloading work when the image size isn't known until the JS component runs?
From the article:
- Image dimensions are enforced, allowing browsers to immediately render the space needed for the image instead of having it jump in when loaded, preventing layout shift.
- While width and height on the HTML <img> element can cause issues with responsive layouts, this is not the case when using next/image. When using next/image the image is automatically made responsive based on the aspect ratio from the provided width and height.
Is srcset commonly used? I am not familiar with it but I'm more full stack than frontend and often feel like front end moves faster than I can keep up with.
I don't know about its popularity, but it works as advertised and my company had used it. What's more important is that it's a correct solution for the problem (unless old browser support is required).
Saying you have the only and first solution to a problem and having no comment section and never acknowledging people on twitter, hackernews and reddit.
The big elephant in the room most of these frameworks are missing is partial hydration. Instead of hydrating the whole page, only the interactive parts are hydrated, sending the absolutely minimal JS needed to the client.
AFAIK only Marko has this feature today. Since it's developed and used at Ebay they focused on the best SSR+hydration experience from the start.
Imba v2 will also have patial hydration (confirmed by the devs here on HN).
Other than those two, it seems nobody is really taking partial/progressive/lazy hydration seriously. IMO SSR+partial hydration is really the next frontier in web development.
It's possible to do it yourself (I did it recently with a Svelte project) but it results in complicated setups. We need a solution that does it transparently, extracting the needed components and data automatically.
The React team is working on some experiments that’s not quite what you’re describing but achieves the goal of sending way less code to the client. I can’t wait until tools like that are more standard.
It's not. That issue is closed and the last comment says:
> Overall it’s currently not possible to do this besides following what’s described in the article. Definitely something we plan on tackling eventually!
I thought it was a massive use case for Facebook. I recall seeing Facebook engineering tech talks about how they write their JavaScript with different types of import statements to optimize what gets rendered in SSR versus on the client. I think this is a similar video: https://www.youtube.com/watch?v=KT3XKDBZW7M
> The HTML output by this stream is exactly equal to what ReactDOMServer.renderToString would return.
I imagine this returns a stream as a convenience for Node servers that are streaming chunks of HTML. I don't think it means that React's SSR is rendering chunks of HTML in an async fashion and returning each chunk to the stream as soon as it's ready.
You're right. ReactDOMServer.renderToNodeStream is to support HTML streaming, which can allow the browser to start rendering the (as far as it knows, static HTML) document before it receives all the HTML. This is nice, but probably is not a huge factor if you're using HTTP caching via a CDN or a static site generator (since the CDN will likely support HTML streaming).
I remember thinking when I first saw Marko it's kinda crazy how unknown Marko is given how well they've been doing streaming SSR and Partial Hydration for years. At production scale at eBay.
Does Elder do SSR or only SSG? It's sort of crazy how automatic partial hydration is in Marko. You just write your code and it works. No extra consideration etc.
Does Next.js do pre-rendering, i.e. if I have a store with 500 products, will it pre-render the HTML (photos, etc.) for all 500 products and serve it as a static request? Or will it assemble the template on the server, send it down to the client and then do some amount of interactivity hydration later on during the page load?
What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations?
I haven't used a JS framework with server-side rendering in a while - but from what I remember it seemed to add a terribly high TTFB to the overall page load, which negatively impacted SEO. As a result we abandoned SSR based frameworks completely and just went with minimal JS on the client and pre-rendered all the pages on the server as HTMLs which loaded pretty much instantly.
Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration
It _can_ prerender all of those combinations. Here is a directory I made with 1000+ pages, prerendered and hosted for free on netlify: https://www.givepuppylove.com/organizations/ . I've found that single digit thousands is about the maximum you can currently have and keep build times reasonable.
If you want to recognize the user's location and display the appropriate currency or language, you would probably want to wrap content dependent on location in a "ClientOnly" type component. So it would not be prerendered in that case. Example code:
As far as count of pages Vercel has a limit of 16000 and Netlify technically has no limit (AFAIK), although the build times will cost you eventually. You can work around this limit in a lot of cases while keeping things prerendered by putting dynamic information in querystrings.
But yeah, if you have 10k pages it seems unavoidable to me that initial build time will be high. With `fallback: 'blocking` you could decide to build each page at runtime when it is requested for the first time – this spreads out initial build time.
What would be nice is being able to re-use compiled pages across builds. Imagine having 10k pages compiled, and you have to push out a new build that only updates 5 pages, or none at all (eg an API change). It would be nice if it could make use of the compiled pages from the previous build, only re-compiling the pages that needed it. Of course the devil is in the details, and figuring out which pages need to be re-compiled basically requires you re-building the pages.
Right, actually building all those pages at once necessarily takes time. But on Netlify, most of my build time isn't actually used doing `next build`, it's the un-logged-to-user file transfer to their server / CDN cache invalidation / whatever hosting magic they do after the static files are built.
So at least in my case, NextJS would have to create a way to not rebuild files that haven't changed, and then the hosting/CDN provider would also need to be able to see which files those are and respond accordingly. This all seems very doable eventually though.
For each page, you can set `fallback: 'blocking'`. If set, the page is not built at compile time. Instead, it will be compiled the first time it's requested. So the first request will take longer, then after that it'll be fast.
Alternatively, on a per-page decision you could decide to use server side generation (page built at compile time) or server side rendering (page compiled when requested).
You have options that let you spread out the time, but ultimately it's going to take time to build millions of pages.
Like acoard said below, I think the recommendation there would be to use their hybrid cache / dynamic rendering option. You do lose a lot of the cool benefits of being fully static in that case though. In general, yes that kind of documentation would be very helpful.
Disclaimer being that I'm talking mostly about 5 - 10 page presentation websites, consistently, I achieve 95+ on Google Page Speed for Mobile when deploying the Next.JS solutions on the Vercel infrastructure. There are helpers for working with images that can generate multiple versions, transform to WebP and other stuff. This is where most of the optimization work goes I think.
> Most of the time when I see the "new hotness" being advertised, there don't really seem to be any specifics that tackle advanced use-cases so it's difficult to accurately assess whether the technology is worth serious consideration
I'm also averse to 'hotness' but at the same time, consideration should be given based on use case. I can't talk for advanced use-cases with Next.JS but using it for the one off freelancing simple website gig, it's a breath of fresh air.
There's also a customer serving around 100.000 pregenerated web pages (simple stuff, catalog item with pictures, related items and people linked to it) and the speed is insane for navigating their internal catalogue :)
> if I have a store with 500 products, will it pre-render the HTML (photos, etc.) for all 500 products and serve it as a static request?
You can set it up to retrieve all 500 products and render the html on the server.
> What if my store has multicurrency / multilingual versions of all these 500 pages - will it pre-render all of these combinations?
The server is making all the requests that would have been made on the frontend. So if the server knew the locale of the user it could presumably load the correct currency and language.
Next.js can do both pre-rendering (static output) and dynamic server-side rendering. I can't speak to your questions about internationalization though.
I recently played around with Next 9.5 prerendering. It had about 400 simple pages with artificially slow API responses to get an idea.
- you can prerender a decent amount of pages no probs
- you can prerender only a subset and then have Next render the necessary pages on the server upon request
- as the page is being prerendered, you can send placeholder content, so ttfb is low
- linking to a non-prerendered page within Next will prefetch (and thus prerender) said page as soon as the link is in the viewport (can be disabled)
- in Vercel you can set the branch name as an env variable. I set it to prerender almost nothing during build time if the branch name contained “hotfix”
So far I think it is worth serious consideration. Will it work for you? I dunno. But it’s a breeze to set up, quick to learn, and run some experiments of your own.
> I haven't used a JS framework with server-side rendering in a while - but from what I remember it seemed to add a terribly high TTFB to the overall page load, which negatively impacted SEO.
You can just stick a CDN like Cloudflare in front of your requests, and this issue is resolved.
I have mixed emotions on this framework. If you're doing a simple project, Next is the best around. Also great for marketing pages, etc. But if you have a more sophisticated app, with an API, page routes that need to toggle based on cookies, etc, then you have to integrate something like Express. I've done this several times with Next, and it just doesn't pay off. I've also tried to use it at work, but it changes rapidly, and it'd be too much to expect engineers who aren't keeping up with everything on the clientside to know what to do.
I feel like there's a need for something between roll-your-own and what vercel is offering.
I assume you're referring to what Next describes as a "Custom Server", e.g. taking over the server-side control flow.
Personally, I keep Next stock for the frontend, and just write an entirely separate backend/API server. I would want to do that in any event, just to achieve separation of concerns and avoid lock-in.
Next.js has been very good for not introducing breaking changes in my experience (especially for the JavaScript ecosystem). The changes are more along the lines of lots of new and useful things (e.g. image optimisation) as opposed to problematic maintenance issues.
I agree cookies can be a bit awkward with Next but I've always found a way around.
Would a minimalist framework like mithril.js fill that gap? I've had a pretty good experience when using it for some small to mid sized projects. Since its on the simple side, the updates are infrequent and have been pretty painless to keep up with.
I think he means if you want to offer React server side you will need some-sort of web framework to serve it. Usually that's Express or Fastify or something like that.
Routing seems like the biggest limitation, but it's a trade off to use their file-based routing which has it's pros too. This precludes page transitions unless you do some really ugly work arounds.
Yeah, I think it's going down the VC wormhole right now. It was a fantastic microframework for doing a few core tasks extremely well. Creating a fully-managed hosting platform is a good revenue stream to support the development. Adding analytics and commerce with vendor tie-ins seems like serious mission creep.
I had also avoided modern web up until very recently. I focused only on Django sites and wrote custom JavaScript as necessary.
I even did a 3 month django project with a view that was almost entirely JavaScript—it would have been a perfect candidate for react but I refused.
As a compromise with myself I used es6 js on that and eliminated use of jQuery from my code.
About a month ago I started work on react. I had very similar feelings going in and was annoyed at having to figure out the node dependency thing.
And I was aghast at the “tool chain” which is the post processing you need to do on React and other modern front end.
However, I was really surprised at how much better it is to build front end using this rather than html templates and sprinkles of js.
I was also surprised to find out that the django community barely has a pulse compared to what is happening in react.
It’s safe back there, but there is no innovation. Once you see what is happening in modern web, it feels like a ghost town.
I think it’s a pretty good time to get into React right now. CRA just got an update, functional components are mainstream and now there is this nextjs.
I encourage you to give react a try, at the very least it will make you think more about why you’re building the way you are.
Try starting with VueJS... it can be added to a page just like jquery and you get the same reactivity/template/etc support on the page without having to setup a compiler/etc.
Then after you learn that if you want to create a full app, vue (in vue-cli) has config templates that will help you set everything up so you can just start adding the pages to the app. A full app is nice because the compiler and linting will catch a lot of js errors making your app more reliable, allowing you to write larger apps (this is the biggest reason people use these frameworks).
The concepts in Vue are similar enough to React, Nuxt, Next, etc that it's pretty easy to learn the others after you have the basics down.
Same. I mean I understand how it works but I ask myself what's the point every time. I've looked into react and I hate how it works and I hate how every 2 months people are begging for some new optimization because its slow and sucks. Then version 5000 is released and fixes that slowdown, but every react site I've ever used is still buggy and slow as hell.
No. People have said this about every web framework since PHP5 and its not true. Web development does tend to favor fast iteration which can lead to problems if the tech debt compounds but that doesn’t mean the people aren’t developers, at all.
So what you're saying is that React spawned an army of people who we can call developers, despite them not knowing how browsers and HTTP works, what algorithms are, how to approach developing your javascript app so it doesn't become spaghetti mess in 24 seconds and abusing terminology from systems programming just in order to make their field appear more serious than it is?
Now, what word could we use for people who are not.. well, "developers"? Programmers maybe?
OK, so definitely my mind is blown with stuff they did. NextJS is great tool and focus on shopping and using that as a use case to improve your whole framework is fantastic.
I also love youth that I see in the team, I am a little bit older :).
Like others here, I am impressed with Svelte and trying to find how and where to use it. We live in great time where we are showered with amazing tools for development.
Having said that, for more traditional, ReactJS scenarios, NextJS is pretty much without competition (even though there is plenty). New features with localization and image optimization are fantastic and allow next level of mobile websites. If we are ever to break Apple/Google monopoly on appstore, this is a way to do it. I think analytics package is solid addition and if you don't want to pay, you don't have to use it, it is for commercial projects.
Anyhow, I am really impressed with features they did and how it is integrated into their platform. Not huge fan of Vercel name still :) but it is great platform.
Vercel is great at getting out of the way of deployments and just working. But I've deployed Next apps to Linux servers on AWS, GC, DO and it wasn't much more involved that a standard Node deployment - Next with Elastic Beanstalk is pretty straight forward too.
Doesn't it still come with a server that you can just run on Heroku? That's what I'm doing, and although I'm not at v10 yet, I can't recall any major challenges there.
I think retiring Sapper was the right decision. I have a feeling Rollup will meet a similar end too.
They both seemed like fine pieces of software. They just don't seem offer separate much their counterparts nowadays that warrants continued feature development.
Rollup isn't going anywhere! When you poke behind the scenes of newer build tools, like Snowpack and Vite and the custom compiler that powers Remix Run, you'll find Rollup doing a lot of the heavy lifting. And it's the preferred choice of most libraries. There's a reason for that :)
The project hasn't really been publicly released yet. The repository is still private. The package is up on npm, but isn't ready for widespread adoption yet. I'd recommend sticking with Sapper for now.
I am not sure I buy into all the svelte hype, and even if claims about it's speed/build size are true - the difference isn't enough to outweigh the enormous advantage vue has in terms of a more mature ecosystem/tooling.
Could be. Angular growth has stalled for the past year or so. Polymer is pretty much dead.
OTOH hand why would Google invest in a React-based solution? Google could start from scratch an create the next best thing if they wanted to. To me it's pretty clear the future is a compiler based approach like Svelte, with support for SSR, partial hydration, static generation, and dynamically loading smaller parts of a page (eg: AJAX + hydration). All with a kickass DX.
If Google wanted to takeover React, the solution is at the browser level. Fix rendering and state management with native language built ins, and voila, we are out of the stupid frontend hell.
Wtf is hydration? Is that like when websites used to render json payloads on the page on first render?
This field is getting scammy with its nonsense. Create one more stupid word, and I swear I will lose my god damn mind.
I tried nextjs because I thought it would be a good way to learn React but I found it really confusing. Is it really better to master React first then try nextjs?
This is the resource I used (as someone who's been doing web development for ~20 years) to get a a basic understanding of React. It, plus some side projects, was enough to get me up to speed: https://daveceddia.com/pure-react/
I'm sure there are others that are free; but, this is what worked for me.
I think create-react-app is much more beginner friendly. Fewer concepts to learn. Rolling your own or using script tags to begin with is also an option (see this course for an example: https://egghead.io/courses/the-beginner-s-guide-to-react)
And create-react-app would be all I would ever need except that SEO on single page apps that don't have data loaded upon load really sucks compared to server side rendered pages. Is there a way to build a site using create-react-app and enable server side rendering without implementing a whole other framework like Nextjs?
We used React Router's ssr process described here[1] on my last React project. It worked ok, but there's a bit of hoop-jumping to go through if your pages are populated by async data.
I can't believe NextJS still doesn't have named routes, resorting to hacks like next-routes or next-named-routes to have a semblance of sanity managing links throughout larger apps.
Also, doing things like /@[username] is still a huge hack, unsupported.
It looks like both of those packages are used for creating dynamic routes with named parameters. Nextjs supports this already. Is that what you meant by "named routes", or is that something different? https://nextjs.org/docs/routing/dynamic-routes
Maybe duplicate content isn't a problem with modern SEO - but it's a problem for my workflow and is potentially one reason why NextJS won't be on my list for any new projects.
Cant you just set a canonical URL meta tag? It’s very common for content to be available through multiple urls. (Eg, have a numeric ID and a slug in the URL. Any slug is valid in case of renames, but the ID is the relevant identifier).
I'm not sure if they are dogfooding their own framework, but it's annoying that the cards on the home page won't even let you select their content without going straight to a different page. It's a subtle breakage of `a href` behavior but I see that on a lot of sites where I'd like to copy a value and instead an action fires off when I don't want to.
this seems to have less to do with Next.js and is more of a design decision. Each card has a native anchor tag inside, and when you tab through these links the card is ignored and the links are focused. The card itself is a 'fake' js link, that redirects when clicked.
i personally would've made the entire card an anchor link, but either approach is possible in Next.js
In short With Next you control when things are rendered: SSG/SSR/CSR, so you get much more flexibility and can cover more use-cases. And it is React based, which is a huge plus, especially if you adhere to a modern style.
What use cases does that cover though that Hugo and Jekyll can't? For landing pages and typical business websites for example, some basic ways to create reusable snippets of HTML feel enough for me. I don't want to have to deal with a lot of React, SPA stuff and JavaScript build issues unless it's really worth it.
Next with static rendering (or Gatsby, which I find horribly over complicated) are alternatives to Hugo and Jekyll. If you already know React, they are pretty easy to set up since they handle all the webpack/babel stuff for you, so you shouldn't have Javascript build issues.
When statically rendered, React is mostly just an alternative templating language.
Looks cool. The scope this asks for in GitLab is too much (everything):
This application will be able to:
Access the authenticated user's API
Grants complete read/write access to the API, including all groups and projects, the container registry, and the package registry.
The new image solution is strictly more powerful than anything currently offered. Since they also control the initial rendering of the HTML, they can seamlessly opt to embed an image via a data url.
Kinda suprised they didn't do digital commerce first. Ecommerce and selling physiscal products is such a pain in comparison which won't go a way with a storefront.
Google does a lot of different things. In this case, it’s part of the Chrome team that has been focusing on this and how to help the web dev ecosystem more broadly.
The problem with doing something like that manually is that it’s painful at scale, and easy to forget. If scale isn't an issue, sure roll your own. But for my uses, I’m more likely to use tooling as a default, preview, then override when the preview doesn’t do what I want/expect.
Is support for nested routes going to be added any time soon?
If I don't want a full page reload when clicking a new tab for example? Or if I want to implement the age old header, sidebar main content layout without importing the header/sidebar in all my routes/components?
I'm aware there are hacks to get around this but would be nice if the standard next router supported nested routing with persistent layouts for those who need it : https://github.com/vercel/next.js/issues/8193
Next really doesn’t add a giant layer of anything, it’s almost vanilla React aside from their own routing and the server side functions (which you can start out not using)
Why are all these frameworks so big. Compiling, boiler plating, templating, huge API's etc.
I just want a real component framework where i can have something like:
<script>
include "MyComponentFramework.js"
page = new Page();
panel = new Panel();
button = new Button().addCssClass("buttonclass");
Page.addComponent(panel)
panel.addComponent(button)
button.bind('click',function(){
panel.addComponent(someComponent);
panel.rerender();
}
</script>
I will use something like bootstrap for css.
My backend can be anything. UI is just fetching data via API's
I really don't like templating and compiling on the frontend. It makes the development process slow.
Basically what your example is describing is jQuery with some functions wrapped around some stuff. Sure, if you want to write a ton of imperative code, you can do that, but people who have been building UIs on the web for a couple decades have been down that road and have collectively determined it’s a nightmare.
Seems like you're asking for UI components (page, panel, button) that you can just use? This isn't the problem Next is trying to solve. You might be better off with something like MaterialUI, Ant, Bootstrap, of any of the many other batteries-included UI frameworks.
Or I guess Web Components were supposed to solve this problem, too, but I think they missed their window.
Am I the only developer that feels that React ... and perhaps the whole web paradigm ... is about the worst way to think about and develop client GUIs?
After using Google's new Flutter framework (which is built to develop cross platform apps: iOS, Android, Web, embedded) I felt like I had my eyes open. The structure seems so much more logical and easy to navigate.
The Web (and React) paradigm of putting some code in HTML, some in CSS, and then some in JS, just seems like a step backwards to me after using Flutter where everything is just code. Designers build in Adobe XD or Figma, and then they hit export, and it dumps out FLutter code that a developer can directly read and incorporate into her project. There isn't a bewildering array of different things all being processed by different other things ... dumping out yet more things. Its just code to binary ... that's it.
And that's another thing ... I like the code to binary direct link. React Native's JS logic + bridge to native always seemed like such an inefficient shim. And seeing the framerate of widgets in Flutter its pretty clear we have been leaving some performance on the table for the convenience of making everything in Javascript.
Having said that, I'm sure Flutter on the web is as bulky as any other JS framework, as there it has to run on JS/HTML/CSS like everyone else.
JSX is not HTML, even though its syntax is very similar. It’s a data structure that’s renderer-agnostic. It can be rendered to HTML, or to a live DOM, or to other outputs. IIRC, Netflix uses React to render at least some components on entirely non-web interfaces like smart TVs.
To me, that fact is what makes React (and other libraries like Preact that have a similar interface) more compelling than the template-oriented alternatives. As far as I’m aware, Flutter takes basically the same approach, just with different syntax. I believe the same is true of SwiftUI. And Elm, and the various UI libraries for Clojure.
And as another comment mentioned, you can use a variety of CSS-in-JS approaches, which at least last time I looked is actually the more common approach in the React community.
Add in TypeScript (or whatever static type system in whatever compile to JS language), and you’re basically comparing bike sheds at this point.
Flutter has even more abstraction than what most people are using for web clients. That doesn't come for free, though it tends to always look like 100% upside until you actually use it and see the trade-offs it makes. Ruby on Rails also used to attract a lot of comments like yours until people realized the trade-offs.
Btw, if Flutter makes the web dev paradigm look bad, then I wonder what you think of the iOS/Android/desktop client paradigms where you don't even get much choice like you have on the web. Like using Core Data's "ORM".
You're essentially hoping Flutter spares you from ever having to drill any deeper than the Flutter abstraction on each of your deploy targets which simply doesn't yet match reality. And of all the client dev experiences, it's the web that has the options closest to Flutter, so it's not the one I'd damn first.
Flutter has a very good plugin architecture. You don't actually have to use their widgets if you don't want to. And as for being restricted to the prevailing platform paradigm ... you have as much freedom as the platform gives you. For some things Flutter can't provide miracles ... like to access specific device hardware you are going to have to build a native bridge ... but in the end Flutter is building a binary that is ... as much as possible ... standalone. It even reinvents GUI components instead of bridging to the prevailing OS ones, touch input instead of using the native one, etc., so that you have more control (if you want it).
It’s still not HTML. It’s just syntactic sugar for function calls. You don’t have to use it either way; you can just call `React.createElement` directly if you don’t like JSX.
Analytics, great idea, is a huge disappointment. It's just a Vercel thing and not NextJS, not to mention a "pro/enterprise" paid feature, not cheap either.
A few days ago I saw the YT videos of "future of Svelte" and that video was really about "DX" with no non-sense no BS that just focused on the real next evolution on web/app dev. That DX really resonated with me.
My opinion, I'm not sold on NextJS 10, the "commercial" move kind of turned me off and scares me of platform lock-in, but I'm getting more and more interested into Svelte (v4?) and I'm seriously looking to switch to it from NextJS.
Note: "DX" stands for "Developer eXperience", meaning how joyful, easy it is to get started with the tool and feeling productive.