Samsung phones and Pixels aren’t that bad either.
I am not saying it to be proud, but I tested our 3mb internal app with a 5 year old android phone, and worked.
The only time it was slow is if the browser itself was old (e.g. Chrome 44).
And what is the best solution? Client Side Rendering is worse, because users see a blank page until the script is parsed. 100KB is actually desirable, because it's included Vue and Vuex out of the box.
Sort of makes me bummed out that the Dart project failed.
If there was one time when we could have escaped the client side hell that is JavaScript it would have been then, when chrome had astonishing market share, and Dart could compile down to JS to ease the transition until native support became standardized.
But nope, here we are with anotherone.js every week.
Is there a way around the nested mess in Flutter widgets? I took a stab at a small app but it was basically a new div hell. Besides that however, it was quite neat.
It's ambitions and potential versus its current adoption make it a relative flop. Plus, since it's made by Google it may randomly end up in the graveyard without warning.
Dart wouldn't stop the relentless cycle of frameworks coming and going.
Case in point: Angular has an alternative Dart implementation which is AFAIK used by Google internally, but it didn't take the web by storm and currently the TS flavour is by far the dominant one.
If you just said the first two sentences and we could have inferred that you don't work in frontend. Every technology has tradeoffs, and frankly I'd like to hear about this mystical backend panacea you're implying.
I generally work in go, where the standard library covers the vast majority of use cases. If you have some crazy specific performance needs there are frameworks for that, but generally vanilla go will get you where you need to go.
I’d love to see a “modern” web app built in pure JavaScript without a framework.
this title and entire premise of the essay is the definition of false dichotomy. when you use nuxt.js you use vue.js. its very clear to webdevs what the metaframework does more than the framework, and you need both.
> this title and entire premise of the essay is the definition of false dichotomy
The article's very first words are: Nuxt.js is a frontend framework built upon Vue.js so I think it's more of a semantics thing on what he meant by "over" (i.e. on top of vs. replaces).
Perhaps useful to some sites. Assuming Google has issues with Vue. Not useful for someone doing content behind a sign-in that isn’t going to ever be SEOed anyway?
I've found the dev experience with nuxt to be more enjoyable overall than it is with vue-cli. The main reason for that I would say is that you don't have to bother with routes and the generator can set up Tailwind (or other CSS frameworks/tools)
Generally, it feels like it strikes a good balance between being fully configurable boilerplate and opinionated framework.
There are other points in favor of doing SSR + hydration besides SEO:
1) Reducing the amount of JS you are sending to the client.
2) Not making a SPA and keep the native functionality of back/forward behavior (scroll behavior, cached pages, forms are filled when going back).
3) Simplifying development. You don't need to manage central state anymore as you're dealing with one page at a time. You might not need an API as you're rendering the page from the server. Etc.
I've been making SPAs for years and for my current project I'm doing SSR + hydration (not using Vue) and loving it.
It reduces the JavaScript sent to each page even further because it doesn't have a runtime per se. Basically each component is "compiled" to a set of imperative DOM instructions with some helper functions.
It's not perfect but I'm willing to accept all its shortcomings because of everything I get in return.
Sometimes I hit a little bump on the road which would be faster/easier to solve in React/Vue/etc but even including those slowdowns I save so much net dev time it's crazy.
That's just one point. Nuxt is the best way to built a multi-page web app with Vue components. Once you're using vue-router and Vuex, you might as well use Nuxt.
Well, about the not useful, I was working on a large service for lawyers and accountants behind a paywall, but then the new CEO decided we wanted to open up portions of stuff to google. So just because something isn't going to ever be SEOed anyway, doesn't mean that at some point in time, guess what, we need to SEO optimize some of this stuff!
My biggest thing with Nuxt is that only the first page load is server side rendered. Everything else is client side. So doing complex search and re-render is done client side.
I admit I don't know the space that well, but I find it interesting that you get static site generators for SPA frameworks, and the companies behind them get really significant VC funding.
Naively it seems a trivial problem, but I guess that SEO for SPA is not as trivial as I imagine?
Why are people slapping Static Site Generators to all the problems?
Imagine you build an e-commerce website that has ten thousands of products, that can be accessed by example.com/products/{product-slug}. Now what is making more sense:
1. Generating ten thousands of .html file for each products in the DB
2. Use routing in Nuxt like this "/products/$productSlug" and query for $productSlug in the database
To me the (2) approach is a clear winner here. And the performance only depends on how fast your API can query a single product from the database, which is pretty fast 99% of the time.
I've used Nuxt.js when I started rewriting a membership site from WordPress to Vue.js. But at that time, the routing options were limited so I opted for a hand crafted Vue.js + server side rendering setup. Maybe today, I would try out Nuxt.js again. Or maybe not, the drawbacks are another layer of abstraction on top of Vue.js. That being said, their community is great and the development is very active. When I did a project in React, and tried Next.js, I expected to find much more info and plugins for this combination, but found this to not be the case.
I'm pretty happy with Nuxt. I built a project with a custom SSR server based on Vue's guide (https://ssr.vuejs.org/), and maintaining it/tweaking it wasn't too bad, but moving all that complexity to Nuxt was nice. If you'd like to see a realistic codebase, warts and all, it's here: https://github.com/thomasboyt/jam-buds/tree/master/app (powers the jambuds.club frontend).
They do have a kind of weird plugin/module system that I worry is an overly complicated layer of abstraction - basically, stuff that would normally be manually hooked up in your server or client entry point script now gets called automatically by Nuxt at various points. Still, it is useful for setting up things like authentication (e.g. parse cookies on server and set auth headers in Axios).
They're also still iterating on the public API, though they've been pretty careful to deprecate without breaking things. Like, the fetch() hook that used to be used to load data at a page level (e.g. "before transitioning to this route, load this set of data") was totally overhauled to now be "load data for this component," with no "pre-transition await" available anymore (https://nuxtjs.org/blog/understanding-how-fetch-works-in-nux...). This is a good change, but an example of the complex problems that come up in these SSR frameworks, and why they end up being a lot more complex than just simple wrappers around the ecosystem. You really have to buy in when you use a framework like this, more than just buying into Vue itself.
I did see that they just raised a seed round (https://nuxtjs.org/blog/seed-round), which is surprising to me. I don't see a lot in that announcement about how they're going to make money, which is a bit scary. Over in React-land, of course, Next.js is nominally owned by Vercel (formerly Zeit), which is also venture-backed, but Next is related to their primary revenue stream while not being at all the main focus of the company, which is probably the right spot for this sort of thing.
Moving to Vue 3 will be a problem for Nuxt, I think, because of the abstractions they've built on top of Vue.
(also, glad this post came up because while double-checking to see how big Nuxt is in my app, I realized I was failing to gzip my client assets because I misconfigured Caddy, gah!)
There are people over on reddit who say that EVERY project should use nuxt. from the lowly todo app, to huge erp projects...
Yet, especially for ERP projects, most of those features are problematic. Like SEO. I don't want a search engine to ever see my content. In fact, my robots.txt says not to index it. SSR is a non starter, since everything would vary based on the user, we're just shifting the rendering back to the server, for no real gain other than the round trips on the api. The routes can be a problem as well. My routes have different navigation guards depending on permissions and state for the user, i haven't checked but i doubt auto generated guards based on folder structure wouldn't handle our weird business logic. COmbined with the difficulty of dealing with errors server side, nuxt.js isn't going to work in these kinds of cases.
TL;DR Nuxt.js does not work for everyone, even if people say it does.
Think SAP or Salesforce with a bunch of custom/addons. Sometimes account features are built in.
It's very much on a different scale of complexity than a todo app. Or any app that 'does one thing well'. I think a lot of devs forget this when talking about what everyone MUST do, or making recommendations like a form should never have more than 5 fields.
Most of the ssr for performance is around how a couple extra milliseconds will increase your bounce rate. For some of us, if our users bounce, they get fired, because the site is the tool they use to do their job. (but we should always endeavour to be performant, because we don't want to make their job more miserable) So things like bounce rate doesn't matter.
Nuxt works fine for all the uses case that I have come across, even for ERP projects. With Nuxt you can have real redirects, real 404 pages, and a well-established project structure. The only hard thing is that server-side error is more difficult to inspect
We use Nuxt on a fairly large project. One of the biggest problems we’re having is that there’s no routes file you define yourself, you structure it by putting views in folders. This is a nightmare once you have more than a few models. It also leads to highly confusing page names, and if you have more than one variable in a route, completely screws everything up. We’ve ended up grouping things together in folders just to make it easier to manage, but that directly effects the URL.
My understanding was that it just added to the existing generated list, I can’t work out how you’d tell it to ignore all your current pages and then manually write them all out?
That's the main point of Nuxt. You look at the URL and find the page component without going through the routes file. In case that doesn't work for you, you can use `extendRoutes` for dynamic use-cases.
In my humble opinion, you lose a lot when you go fully static. One particular case that becomes a pain in the ass is redirections. Nuxt has some redirect modules but they feel super half baked.
Also routing is a mess. Really no way to set up routing in a decent, understandable way.
So in my opinion just use Nuxt when you are sure your website is not going to need any complex functionality that is easily achievable with a server middleware. Pretty sure that there are other ways to achieve good SEO and in general Search Engine indexation without giving up so much.
I feel as though if you just want a static website, you're better to use one of the more mature frameworks designed for that purpose, like Ruby on Rails or Asp.net Core etc.
I worked on a project built with Nuxt about a about a year ago and I really didn't like it. Everything felt like a chore.
Am I missing something or did the definition of static website change? AFAIK a static site is one that has no backend and you can throw on S3 or whatever. An ASP.NET project is pretty much the absolute furthest you can get from a static website.
Yeah this seems close to the philosophy of no side effects for functional languages. It's neat and has some nifty benefits for your code but for the 1% of situations where you need side effects/client-side rendering, you're gonna end up fighting the tool rather than enjoying it.
I only use SSR for `bot` or for `?ssr=true` in dev mode.
My setup is that, SSG most of the time, with fallback to SSR for bot/crawlers, else return the spa.html which is just a SPA.
Alternatively, if you want to get the same result in terms of SEO. You can use seo4ajax.com. In 5 minutes it's integrated and ready to use. Disclosure: I am the founder of the service.
As others pointed out nuxt can be very restrictive when you're trying to build something that doesn't fit their mould.
What I end up using is vanilla vue.js and a cli plugin to statically generate the pages that need to be SEO friendly during build.
Best of both worlds.
I always use Nuxt by default for new projects, and it's a correct decision every time. People who choose to do Client Side Rendering (SPA) finally struggling on SEO and other tasks.
1. Nuxt can runs in SPA mode just like using Vue CLI. The opposite is not true
2. SEO is the winning feature of Nuxt, no doubt.
3. Real server status code: especially useful for redirections and 404 pages. For example if you do `curl -I /some-page-that-does-not-exist`, you will get back 404 status code, which is critical for sitemaps and uptime tools. (Instead in SPA you always get 200 for all the pages).
4. Pages written in Nuxt seems to display faster, because the HTML is sent immediately. I say "display" here, not necessarily "load" faster.
5. Real Express middleware helps a lot when doing route validations and authorizations. You can also make calls to private API without exposing them on the client side.
6. Can adjust the amount of HTML sent to client by wrapping client-side-only components in a <client-only> component. Which means that on the server you don't need to generate giant HTML for a simple datepicker, and let the browser does that
79 comments
[ 4.5 ms ] story [ 156 ms ] threadThe only time it was slow is if the browser itself was old (e.g. Chrome 44).
The solution is to have a performance budget at the start of your project so things never get so bad.
NextJS
NestJS
why all these frameworks have very similar names? it is very confusing every time I read a news about one of them I wonder which one is which.
If there was one time when we could have escaped the client side hell that is JavaScript it would have been then, when chrome had astonishing market share, and Dart could compile down to JS to ease the transition until native support became standardized.
But nope, here we are with anotherone.js every week.
Case in point: Angular has an alternative Dart implementation which is AFAIK used by Google internally, but it didn't take the web by storm and currently the TS flavour is by far the dominant one.
I think we're very lucky that Chrome never decided to include that Dart VM. Typescript turned out to be much better than Dart.
I think we can agree to disagree. I would much rather use Dart, imo.
NestJS is probably a coincidence.
The quagmire of subtly different JavaScript frameworks is definitely the leading reason I avoid front end work like the plague.
I’d love to see a “modern” web app built in pure JavaScript without a framework.
The article's very first words are: Nuxt.js is a frontend framework built upon Vue.js so I think it's more of a semantics thing on what he meant by "over" (i.e. on top of vs. replaces).
They're two different kinds of projects, with different trade-offs, even though the underlying front end framework is the same.
Perhaps useful to some sites. Assuming Google has issues with Vue. Not useful for someone doing content behind a sign-in that isn’t going to ever be SEOed anyway?
Generally, it feels like it strikes a good balance between being fully configurable boilerplate and opinionated framework.
I don’t send JS, my CDN does, so not a big win there.
There are other points in favor of doing SSR + hydration besides SEO:
1) Reducing the amount of JS you are sending to the client.
2) Not making a SPA and keep the native functionality of back/forward behavior (scroll behavior, cached pages, forms are filled when going back).
3) Simplifying development. You don't need to manage central state anymore as you're dealing with one page at a time. You might not need an API as you're rendering the page from the server. Etc.
I've been making SPAs for years and for my current project I'm doing SSR + hydration (not using Vue) and loving it.
It reduces the JavaScript sent to each page even further because it doesn't have a runtime per se. Basically each component is "compiled" to a set of imperative DOM instructions with some helper functions.
Hopefully they will get there one day but so far it gives me the feeling that I could hit a dead-end with it at any time.
Sometimes I hit a little bump on the road which would be faster/easier to solve in React/Vue/etc but even including those slowdowns I save so much net dev time it's crazy.
Sharing filtered links or storing filtered links in your favorites becomes impossible when the query parameters don't change.
Naively it seems a trivial problem, but I guess that SEO for SPA is not as trivial as I imagine?
Imagine you build an e-commerce website that has ten thousands of products, that can be accessed by example.com/products/{product-slug}. Now what is making more sense: 1. Generating ten thousands of .html file for each products in the DB 2. Use routing in Nuxt like this "/products/$productSlug" and query for $productSlug in the database
To me the (2) approach is a clear winner here. And the performance only depends on how fast your API can query a single product from the database, which is pretty fast 99% of the time.
Going to the website it wants me to install .. Safari 13.
They do have a kind of weird plugin/module system that I worry is an overly complicated layer of abstraction - basically, stuff that would normally be manually hooked up in your server or client entry point script now gets called automatically by Nuxt at various points. Still, it is useful for setting up things like authentication (e.g. parse cookies on server and set auth headers in Axios).
They're also still iterating on the public API, though they've been pretty careful to deprecate without breaking things. Like, the fetch() hook that used to be used to load data at a page level (e.g. "before transitioning to this route, load this set of data") was totally overhauled to now be "load data for this component," with no "pre-transition await" available anymore (https://nuxtjs.org/blog/understanding-how-fetch-works-in-nux...). This is a good change, but an example of the complex problems that come up in these SSR frameworks, and why they end up being a lot more complex than just simple wrappers around the ecosystem. You really have to buy in when you use a framework like this, more than just buying into Vue itself.
I did see that they just raised a seed round (https://nuxtjs.org/blog/seed-round), which is surprising to me. I don't see a lot in that announcement about how they're going to make money, which is a bit scary. Over in React-land, of course, Next.js is nominally owned by Vercel (formerly Zeit), which is also venture-backed, but Next is related to their primary revenue stream while not being at all the main focus of the company, which is probably the right spot for this sort of thing.
Moving to Vue 3 will be a problem for Nuxt, I think, because of the abstractions they've built on top of Vue.
(also, glad this post came up because while double-checking to see how big Nuxt is in my app, I realized I was failing to gzip my client assets because I misconfigured Caddy, gah!)
Yet, especially for ERP projects, most of those features are problematic. Like SEO. I don't want a search engine to ever see my content. In fact, my robots.txt says not to index it. SSR is a non starter, since everything would vary based on the user, we're just shifting the rendering back to the server, for no real gain other than the round trips on the api. The routes can be a problem as well. My routes have different navigation guards depending on permissions and state for the user, i haven't checked but i doubt auto generated guards based on folder structure wouldn't handle our weird business logic. COmbined with the difficulty of dealing with errors server side, nuxt.js isn't going to work in these kinds of cases.
TL;DR Nuxt.js does not work for everyone, even if people say it does.
It's very much on a different scale of complexity than a todo app. Or any app that 'does one thing well'. I think a lot of devs forget this when talking about what everyone MUST do, or making recommendations like a form should never have more than 5 fields.
Most of the ssr for performance is around how a couple extra milliseconds will increase your bounce rate. For some of us, if our users bounce, they get fired, because the site is the tool they use to do their job. (but we should always endeavour to be performant, because we don't want to make their job more miserable) So things like bounce rate doesn't matter.
Also routing is a mess. Really no way to set up routing in a decent, understandable way.
So in my opinion just use Nuxt when you are sure your website is not going to need any complex functionality that is easily achievable with a server middleware. Pretty sure that there are other ways to achieve good SEO and in general Search Engine indexation without giving up so much.
I worked on a project built with Nuxt about a about a year ago and I really didn't like it. Everything felt like a chore.
A better example of a static site generator would be something like Jekyll (https://jekyllrb.com/)
1. Nuxt can runs in SPA mode just like using Vue CLI. The opposite is not true
2. SEO is the winning feature of Nuxt, no doubt.
3. Real server status code: especially useful for redirections and 404 pages. For example if you do `curl -I /some-page-that-does-not-exist`, you will get back 404 status code, which is critical for sitemaps and uptime tools. (Instead in SPA you always get 200 for all the pages).
4. Pages written in Nuxt seems to display faster, because the HTML is sent immediately. I say "display" here, not necessarily "load" faster.
5. Real Express middleware helps a lot when doing route validations and authorizations. You can also make calls to private API without exposing them on the client side.
6. Can adjust the amount of HTML sent to client by wrapping client-side-only components in a <client-only> component. Which means that on the server you don't need to generate giant HTML for a simple datepicker, and let the browser does that