Alternatives to Nuxt.js

Next.js is probably the most enjoyable React framework our team could have picked. The development is an extremely smooth process, the file structure is beautiful and organized, and the speed is no joke. Our work with Next.js comes out much faster than if it was built on pure React or frameworks alike. We were previously developing all of our projects in Meteor before making the switch. We left Meteor due to the slow compiler and website speed. We deploy all of our Next.js projects on Vercel.

Mixmax was originally built using Meteor as a single monolithic app. As more users began to onboard, we started noticing scaling issues, and so we broke out our first microservice: our Compose service, for writing emails and Sequences, was born as a Node.js service. Soon after that, we broke out all recipient searching and storage functionality to another Node.js microservice, our Contacts service. This practice of breaking out microservices in order to help our system more appropriately scale, by being more explicit about each microservice’s responsibilities, continued as we broke out numerous more microservices.

I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.

We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.

Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis  for cache and other time sensitive operations.

We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.

Since we have different frontend apps we have found useful to have Bit to document visual components and utils in JavaScript.

We are in the process of adopting Next.js as our React framework and using Storybook to help build our React components in isolation. This new part of our frontend is written in TypeScript, and we use Emotion for CSS/styling. For delivering data, we use GraphQL and Apollo. Jest, Percy, and Cypress are used for testing.

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

Our whole Node.js backend stack consists of the following tools:

• Lerna as a tool for multi package and multi repository management
• npm as package manager
• NestJS as Node.js framework
• TypeScript as programming language
• ExpressJS as web server
• Swagger UI for visualizing and interacting with the API’s resources
• Postman as a tool for API development
• TypeORM as object relational mapping layer
• JSON Web Token for access token management

The main reason we have chosen Node.js over PHP is related to the following artifacts:

• Made for the web and widely in use: Node.js is a software platform for developing server-side network services. Well-known projects that rely on Node.js include the blogging software Ghost, the project management tool Trello and the operating system WebOS. Node.js requires the JavaScript runtime environment V8, which was specially developed by Google for the popular Chrome browser. This guarantees a very resource-saving architecture, which qualifies Node.js especially for the operation of a web server. Ryan Dahl, the developer of Node.js, released the first stable version on May 27, 2009. He developed Node.js out of dissatisfaction with the possibilities that JavaScript offered at the time. The basic functionality of Node.js has been mapped with JavaScript since the first version, which can be expanded with a large number of different modules. The current package managers (npm or Yarn) for Node.js know more than 1,000,000 of these modules.
• Fast server-side solutions: Node.js adopts the JavaScript "event-loop" to create non-blocking I/O applications that conveniently serve simultaneous events. With the standard available asynchronous processing within JavaScript/TypeScript, highly scalable, server-side solutions can be realized. The efficient use of the CPU and the RAM is maximized and more simultaneous requests can be processed than with conventional multi-thread servers.
• A language along the entire stack: Widely used frameworks such as React or AngularJS or Vue.js, which we prefer, are written in JavaScript/TypeScript. If Node.js is now used on the server side, you can use all the advantages of a uniform script language throughout the entire application development. The same language in the back- and frontend simplifies the maintenance of the application and also the coordination within the development team.
• Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.

I'm planning to create a web application and also a mobile application to provide a very good shopping experience to the end customers. Shortly, my application will be aggregate the product details from difference sources and giving a clear picture to the user that when and where to buy that product with best in Quality and cost.

I have planned to develop this in many milestones for adding N number of features and I have picked my first part to complete the core part (aggregate the product details from different sources).

As per my work experience and knowledge, I have chosen the followings stacks to this mission.

UI: I would like to develop this application using React, React Router and React Native since I'm a little bit familiar on this and also most importantly these will help on developing both web and mobile apps. In addition, I'm gonna use the stacks JavaScript, jQuery, jQuery UI, jQuery Mobile, Bootstrap wherever required.

Service: I have planned to use Java as the main business layer language as I have 7+ years of experience on this I believe I can do better work using Java than other languages. In addition, I'm thinking to use the stacks Node.js.

Database and ORM: I'm gonna pick MySQL as DB and Hibernate as ORM since I have a piece of good knowledge and also work experience on this combination.

Search Engine: I need to deal with a large amount of product data and it's in-detailed info to provide enough details to end user at the same time I need to focus on the performance area too. so I have decided to use Solr as a search engine for product search and suggestions. In addition, I'm thinking to replace Solr by Elasticsearch once explored/reviewed enough about Elasticsearch.

Host: As of now, my plan to complete the application with decent features first and deploy it in a free hosting environment like Docker and Heroku and then once it is stable then I have planned to use the AWS products Amazon S3, EC2, Amazon RDS and Amazon Route 53. I'm not sure about Microsoft Azure that what is the specialty in it than Heroku and Amazon EC2 Container Service. Anyhow, I will do explore these once again and pick the best suite one for my requirement once I reached this level.

Build and Repositories: I have decided to choose Apache Maven and Git as these are my favorites and also so popular on respectively build and repositories.

Additional Utilities :) - I would like to choose Codacy for code review as their Startup plan will be very helpful to this application. I'm already experienced with Google CheckStyle and SonarQube even I'm looking something on Codacy.

Happy Coding! Suggestions are welcome! :)

Thanks, Ganesa

For Etom, a side project. We wanted to test an idea for a future and bigger project.

What Etom does is searching places. Right now, it leverages the Google Maps API. For that, we found a React component that makes this integration easy because using Google Maps API is not possible via normal API requests.

You kind of need a map to work as a proxy between the software and Google Maps API.

We hate configuration(coming from Rails world) so also decided to use Create React App because setting up a React app, with all the toys, it's a hard job.

Thanks to all the people behind Create React App it's easier to start any React application.

We also chose a module called Reactstrap which is Bootstrap UI in React components.

An important thing in this side project(and in the bigger project plan) is to measure visitor through out the app. For that we researched and found that Keen was a good choice(very good free tier limits) and also it is very simple to setup and real simple to send data to

Slack and Trello are our defaults tools to comunicate ideas and discuss topics, so, no brainer using them as well for this project.

Bootstrap is a great idea until your designer wants something that doesn't fit neatly into a 12 column paradigm. Then things start to get difficult. We've had to add customizations and tweaks to Bootstrap-ed HTML that by the time we were done, we would have been better off just going straight CSS. Bootstrap helps with responsiveness, but again, it's an "80/20" solution at best. And that 20 percent can be a nightmare. Plus, most clients have this odd belief that you just drop Bootstrap into an app, and abracadabra, your site is totally responsive over every type of screen and form factor in existence. This is not the case. We have had MUCH better and faster results with Tailwind CSS. Our designers are happy we're not trying to force them into a Bootstrap-friendly design, and even with responsive sites, development has been easier and faster.

TL;DR: Shall I keep developing with Nuxt.js 2 and wait for a migration guide to Nuxt 3? Or start developing with Vue.js 3 using Vite, and then migrate to Nuxt 3 when it comes out?

Long version: We have an old web application running on AngularJS and Bootstrap for frontend. It is mostly a user interface to easily read and post data to our engine.

We want to redo this web application. Started from scratch using the newest version of Angular 2+ and Material Design for frontend. We haven't even finished rewriting half of the application and it is becoming dreadful to work on.

• The cold start takes too much time
• Every little change reload the whole page. Seconds to minutes of development lost looking at a loading blank page just changing css
• Code maintainability is getting worse... again... as the application grows, since we must create everytime 5 files for a new page (html, component.ts, module.ts, scss, routing.ts)

I'm currently trying to code a Proof of Concept using Nuxt.js and Tailwind CSS. But the thing is, Vue.js 3 is out and has interesting features such as the composition API, teleport and fragments. Also we wish to use the Vite frontend tooling, to improve our time developing regardless of our application size. It feels like a better alternative to Webpack, which is what Nuxt 2 uses.

I'm already trying Nuxt.js with the nuxt-vite experimental module, but many nuxt modules are still incompatible from the time I'm posting this. It is also becoming cumbersome not being able to use teleport or fragments, but that can be circumvented with good components.

What I'm asking is, what should be the wisest decision: keep developing with Nuxt 2 and wait for a migration guide to Nuxt 3? Or start developing with Vue.js 3 using Vite, and then migrate to Nuxt 3 when it comes out?