DEV Community: The Spider

Meteor vs Next? A brutally honest answer

The Spider — Thu, 04 Jun 2020 09:38:42 +0000

Meteor is Awesome. Next is Awesome. I love both frameworks, but they cannot be compared. It’s not even apples compared to oranges. One is an apple and the other is a basket full of apples. The risk of this basket is that there is always this rotten apple that you might want to throw away even though you’ve now paid for it. The real question you should ask is does the price of buying the apples separately outweigh the price of buying 1 basket and throwing away some of them. Even more so, if you consider that the apples of the basket were picked by real apple experts, do you really want to take the risk of picking the wrong apples yourself?

Both Next and Meteor have their purpose and what you should look at is what they give you vs what you have to build or throw away.

Where Next.js shines

Next.js is your apple. It’s an amazing view layer and it provides you with all the tooling needed to easily integrate your React frontend. Not only that, it follows some nice patterns to allow plug-ability which keeps your code-base nice and tidy. Some of the things where Next.js really shines is pre-rendering, serverside rendering + hydration, routing and optimized hot module replacement capabilities. In other words, it takes care of all the complex render related stuff and provides convenient functionalities to hydrate your components using getServerSideProps and getStaticProps and also a nice CLI tool to help you build and pre-render it for serverless purposes.

What Next.js lacks

One HUGE thing that Next.js doesn’t have though a solid thought trough state layer with best practices in how to use it. With state layer I mean both UI state and domain state. Luckily Next.js is React which means that you can be assured of powerful UI state capabilities using React hooks and the context API.

UI State is not domain state

It should be clear that there is a huge difference between the UI state and domain state. Even more so, the way you manage domain state is totally different than UI state. There's an article with an excellent explanation about the difference between the two.

In short: UI state is essentially the internal state of your components and layout. For example a dropdown that is open or a collapsed menu. View state is unique to an app. Domain state however is business related and is unique to a business. For example in a webshop domain state would be the products and product categories, for a blog this would be articles and the categories of those articles. The real downside of Next.js is on the domain state side, because there is none, except for the hydration helpers that I’ve just mentioned.

Of course you could use a tool like ApolloJS, but that means that you need to create another API application for its server and you need to install its client into the next project, provide it with all the boilerplate and create mechanisms to provide serverside rendering.

I’ve seen most developers do Apollo Integrations or in fact any API integration VERY wrong, creating a fundamentally broken project that requires months of refactoring to get it in good shape. Its exactly this practice that developers in companies never get time for.

React's history of breaking changes

Next.js is React. I’m very experienced in React, but I need to admit that React is a moving target. I would consider it a low level UI component abstraction with powerful state management tools like hooks and providers, but besides basic documentation for its tools, it does not promote many best practices with the result of having a very scattered community. That React is a low level API also reflects back on the number of breaking changes. React is at time of writing on version 17/18. Any project (that includes the Next based ones) that has been there for a couple of versions has had to go trough quite some refactor rounds just keep everything up to date.

Where Meteor shines

Meteor is your basket of apples. It has mostly awesome stuff. Especially on the server. The server by default is typically THE frontender’s weekpoint. Since the introduction of so called BFF’s (Backend for frontends) - which promised to provide a proper abstraction over existing frontends I’ve seen people doing Express.js integrations that make me cringe. Even worse, without them knowing it, they are essentially reinventing something that Meteor OWNS to the core from when it first appeared 8 years ago (2012).

The Unfortunate Meteor Paradox

It’s a paradox. People were shooting at Meteor, because it “was hard to make it work with existing backends”, but now we are introducing “BFF’s” that should provide the exact level of abstraction that Meteor gives us, but most devs fail to build an efficient toolkit that even closely matches that of Meteor. Even worse, I found myself diving into existing projects of just 2 years old and it unfortunately had to become my sole purpose to maintain parts of the API that I would never even have to touch in Meteor.

Microservices - The biggest argument against Meteor

As some of you might know. Meteor has and still markets itself as a full-stack platform. This is the official guide catch-phrase: "Meteor is a full-stack JavaScript platform for developing modern web and mobile applications.".

Somehow developers can't see the difference between a micro-service architecture and the term full-stack. Because of that they wrongly put Meteor into a corner of "not working as part of a large ecosystem". Did you know that micro-services themselves are "stacks"? Just look at ANY application that runs with SSR enabled. There is a server involved. Even more so, bigger sites often introduce the concept of BFF's to act as an API purely designed for 1 specific frontend. Meteor IS the ideal BFF AND your frontend. But what about Mongo and Minimongo? You don't 'have' to use it, but even for this there are some good reasons to do so - even if you don't have a Mongo database.

Minimongo is a undervalued domain state library

Meteor works with, but also without Mongo. Most people dont realize this, but is very easy to NOT use Mongo, but still Minimongo. Minimongo is the number 1 type of library that I always miss when building big UI interfaces. I get optimistic UI and server sync for free. In Apollo this is still very complex. Unfortunately Minimongo has been originally built to work closely with Mongo (hence the name) and that’s why people get confused by it. Best way to look at Minimongo is by looking at it as a full-stack domain data layer for the UI with powerful query and sync mechanisms. It’s NOT Mongo, but it does use similar powerful features. You can use ANY backend as has been proven by the Redis Oplog package and the SQL integration layer. I’ve been using Meteor mostly on top of existing Rest backends. Here's the guide which illustrates how easy it is:

https://guide.meteor.com/data-loading.html#loading-from-rest

Meteor VS Apollo

So what about Apollo Server then? Well… GraphQL is awesome. Complex, but awesome. It’s complex, because it has a high learning curve. It forces standards and introduces a different paradigm, but I do feel that it’s the way to go. Meteor’s EJSON actually provides similar capabilities and together with Meteor's DDP Protocol and Minimongo it provides all the tools you need. You could also use DDP without Minimongo and have your own UI state manager.

EJSON + Minimongo is likely what has inspired the MDG folks to build a tool like ApolloJS. MDG is the company that initially built Meteor and later sort-of left Meteor to its faith and continued with ApolloJS. Tiny has acquired Meteor and seems to be igniting a spark in many idle Meteor developers. One thing that Apollo doesn't really have though is a high level API. It leaves integration of different tools to the developers and frameworks - which is good, but the same thing applies as what you see in the React community. Scattered practices and a lot of people creating API implementations that make me cringe.

If you do like Apollo (Like me) then you might want to look at using Apollo with Meteor. This way you leverage Meteor's and Apollo's advantages

Meteor integrates well with Blaze, React, Vue, Angular and Svelte

Meteor has a couple of “first class UI citizens” like Blaze, React and Svelte (Not tried Svelte, but it’s a cool new UI lib). It also provides Vue integration - though 3th party - but it illustrates that integrations are doable, though admitted not that simple for un-experienced people - especially doing the HMR part is difficult, but in all fairness, try to nail that with Webpack for the server side..

Another huge advantage of Meteor is its backwards compatibility and history of baby bottom smooth transitions to major version upgrades. That’s in contrast with Next. Given that Next works on top of React, I must say that the Next team does a good job of simplifying the transitions though.

Meteor's downsides

IMHO. Meteor’s biggest downside used to be its greatest asset, which is its built system. I love Meteor’s build-system, its very efficient in bundling for targeted clients. Old browser? Here’s a special bundle for you! Again I challenge you to try and configure such a feature with Webpack! The problem however is that most of the community has shifted towards Webpack, because of its plug-ability (Like WHY?! I just want my darn frontend to load magically, because build tools are boring… ain't nobody got time for that? No offence brilliant gods that maintain these things! I truly need and endorse you!). Somehow developers love doing these things themselves, because they think they are doing something really special - It’s horrifying. However a new trend is emerging. Vite is an emerging tool that relies on just the basic stuff. It’s VERY fast and simple to setup. Meteor might benefit from this new trend - though there are many directions and options on how to benefit from it.

SSR and hydration

Another downside is SSR and hydration for Minimongo. However you could of course just integrate Apollo Server and Client with Meteor and have the best of both worlds: https://www.apollographql.com/docs/react/integrations/meteor/ 1

In conclusion

Admitted. Both frameworks are awesome, but they work on different levels. Next.js, Nuxt.js, Gridsome and many other UI frameworks focus on JUST the render layer. They are the shiny apples. They have excellent documentations and I love the communities (big mention to the Vue and Nuxt communities and of course @evanyou - once part of MDG - and @akryum who has given us the Vue integration package for Meteor). Meteor is still a league of its own, because it's much more than 1 apple. It works with other tools like Apollo and the different UI libraries. You could even use Meteor’s server and integrate it with Next.js or Nuxt.js! In that case a package like SimpleDDP might be helpful to easily connect Next to Meteor's DDP API Many devs do this.

There are only a few frameworks that sort-of approach parts of Meteor’s API layer functionalities. One of them is Feathers.js, but it’s mainly focused on ‘just’ the API client / server part. Another one is RxDB, but I see that one more as a replacement for Meteor’s DDP, Methods and Minimongo integration. Again, just 1 part of the total picture.

The choice is up to you, but if your focus needs to be on features, I would choose Meteor. If you require only the UI part with very powerful features and things like static rendering, use Next. (That is if you decided that React is your tool of choice)

4 reasons to attend any frontend conference

The Spider — Mon, 16 Dec 2019 18:19:27 +0000

I often get the question from fellow developers and business people: "Why should I or my developers attend a conference?". Here's my take as a seasoned developer with a strong focus on business.

1: It's by far the best way to explore new stuff

The frontend world has become a complex landscape because of growing expectations from consumers and stakeholders. What makes it worse is the sheer number of directions your developers could follow to solve a specific problem.

One solution for this is to attend conferences. It's a unique opportunity to meet other developers that face similar problems or they might have already come up with a solution of their own!

A while ago I was attending a conference where a guy spoke about Micro Frontends. When we started discussing it during the after drinks, other developers of similar companies joined us. Then we decided to start a 'task-force' where we discuss our approaches online specifically targeted towards our shared use-cases and that worked for us! It was essentially speeding up our work and saved us months of trial and erroring by ourselves and 50 other developers!

Imagine the cost saving here on human resources. Plus you get a lot of 'free' expertise from other developers and a chance to make them bond with your company!

2: Great opportunity to meet the experts

The speakers at a conference are there for a reason. They either solved something in a unique way, have new insights to share or they are sharing the latest features of the frameworks that they are contributors or creators of.

Let's say you are a Vue developer working with Nuxt.js. Then what's better than talking with the people that created Nuxt.js?! They are the experts, because they have created Nuxt.js with the intention to solve specific problems. They could help you and your company to tackle problems using that framework's best practices!

Beat that, online tutorials!

3: It's good fun!

I'm this guy that loves talking and discussing developer related stuff endlessly. Since conferences are mostly packed with like-minded people (fellow developers, software companies, designers, etc) it is a great way to talk with new people and share different perspectives on the same subjects.

Most conferences also have after-parties with drinks where it's simply about having a good time. This promotes the community feeling and allowes people to connect in a different setup besides the professional environment of a company.

4: It's impossible to learn if you don't know what you need to learn

The developers world is huge. There are so much patterns, architectures, concepts, soft-skills and languages and they all solve specific problems. It's easy to go onto Google and search for a concept that you are already aware of, but it's impossible to look for a concept from which you have no clue that it exists in the first place!

Now imagine you allow your developers to take coaching classes (which can literally cost a lot of money). Which class or subject should they cover?

Conferences and other people are the best place to stumble upon new concepts and give insights into what subjects your developers should be focussing on!

Why Frontend Love and VueJS Amsterdam?

At Frontend Love we strive to be the ultimate platform for experts, developers and companies to team up. The speakers and subjects are being chosen by our own developers and this has multiple reasons.

Some of our developers are very active contributors to communities and open source projects. I personally love to talk about subjects that matter for developers and am able to give technical feedback on the topics themselves. This improves the quality of the talks and the schedule as a whole. Creating the schedule is actually our side-job!

Also devs working on other companies means that we know what issues companies are dealing with and that's how we select the right experts for the stage! Its therefore guaranteed to be extremely valuable for your company and your developers to attend!

Our focus on developers sets us apart!

Frontend Love is really focussed towards frontend developers. This is what sets Frontend Love apart from other huge conferences, where speakers often times have nothing to do with development in general. Our speakers are either developers, advocates or tutors! Some other conferences are mostly purely focussed on other companies and simply show the latest and greatest. Not so much towards developers, even though they sell it as if it is a technical conference..

Vue.JS Amsterdam is even more focussed towards (obviously) Vue specific stuff and even so, there is so much to talk about so many topics to cover...

We still have tickets available for both Frontend Love (19th February 2020) and our Vue.JS Amsterdam (20/21th February 2020):

https://frontenddeveloperlove.com/

https://vuejs.amsterdam/

Using Webpack for API development!

The Spider — Mon, 09 Dec 2019 14:46:25 +0000

Looking for the example with Webpack and Apollo Server? Here's the Example repo on Github

I just want to share this rather confusing fact. Webpack is 'not' a server. It's a development tool meant to create bundles. It 'packs' web stuff...

In other words. You use webpack to build your app into something that can be ran by your Node version of choice or by a browser. You are the builder, Webpack is your conveyor belt and at the and of that tool chain will be an executable that can be started by the node command or a tool like nodemon.

Webpack works as follows:

You create a file with a module (file that exports a function or class)
Webpack detects the module
Webpack transforms this module into the format of your choice
Webpack then adds this module into (typically) one javascript file called a "bundle". It's even called bundle.js in most cases

If you use Babel, Webpack can then transform es7 style Javascript and make it compatible for people that use older versions of Javascript.

What is the webpack-dev-server?

Webpack dev server is in fact a simple 'server' that is pre-configured to serve your bundle during development. This is nice, because it allows you to develop an app quickly using stuff like Hot Module Reloading (HMR). However, it is 'not' meant to be a tool for developing an API or any Backend App. Here's my reasoning:

The webpack-dev-server is in fact a simple Express server that uses the webpack-dev-middleware under the hood. Whenever you start it, it will run Webpack in 'watch' mode. This means that every change you make to your source code, will make Webpack transform this source and serve it for any browsers. This means that it's not only taking care of the conveyor belt, but it's also acting as a server that serves the bundle to a browser.

Note that webpack-dev-server serves separately transformed modules (the modules are not being bundled)

What is Hot Module Reloading?

The HMR principle works a bit different then the default Webpack bundler. Instead of creating a new bundle every time you make a change, it only transforms the modules, but keeps them as separate modules. Webpack-dev-server then serves these modules for your browser.

The webpack-dev-server runs a small layer of code called the HMR runtime. This runtime is connected via a websocket. This websocket is a realtime connection between your browser and your development server. Whenever your modules change on the server, they will be pushed to the browser. The runtime will then replace that module without reloading the entire browser.

It should speak for itself that this runtime and its socket connection should not be part of your production app and should therefore only run in development mode.

Using Webpack for server or backend only

People tend to think that since Webpack creates bundles, its most suitable for regular apps and not so much for APIs. That's mostly true, but it can be very useful for backends too! Should you do it? It depends.

What's certain is that since this whole HMR Runtime functionality and browser stuff is not applicable to API development, you don't need webpack-dev-server. It's overkill for API development and only makes your setup more complex, but Webpack could still be a must have!

When to use Webpack for your API's

Like I said. Webpack is a 'build' or 'transform' tool. You don't need it for development if you can run and reload your app easily using a tool like Nodemon. At some point in time you need to run your API on some server though and that's where you want to use Webpack. Here's my take on when you should and shouldn't.

If you simply require a reload of your API code whenever you make a change, then don't use Webpack for development. If you for example only require some Babel transforms, then simply use Nodemon in combination with a .babelrc file.

The grey area starts when you need to configure more tools. For example, if you want to use Typescript. You could use the 'tsc' command in watch mode, but as soon as you need to combine Babel and Typescript, it might be time to switch to Webpack.

For me the clear boundary starts from when you need to include non-javascript files like graphql or SVG files and need to combine more then 2 transformers.

In fact, whenever I build an Apollo Server API, my first choice would be using Webpack with Nodemon.

A final development setup would be something like this for your Apollo Server of Express API:

Simplifying the flow

We now have 2 processes that we need to start for 1 app. The Webpack watcher and the Nodemon process. To simplify this a bit I'm often using npm-run-all like below in my package.json:



  "scripts": {
    "dev": "npm-run-all -p watch:src watch:dist",
    "watch:src": "webpack --config webpack.development.js",
    "watch:dist": "nodemon ./dist/bundle.js",
    "build": "webpack --config webpack.production.js"
  }

Running npm run dev will make npm-run-all start both the Webpack watcher and the Nodemon script. The final production build is ofcourse just the webpack script. I've also split up the Webpack configuration files for production and development and a file for common configurations like this:



./webpack.common.js
./webpack.development.js
./webpack.production.js

This is how the files look like:

webpack.common.js

Note that I've included the webpack-graphql-loader. This allows me to have separate graphql files.



const path = require('path');

module.exports = {
  module: {
    rules: [
      { test: /\.graphql|\.gql$/, loader: 'webpack-graphql-loader' }
    ]
  },
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js'
  },
  resolve: {
    extensions: ['.js']
  },
  target: 'node'
};

webpack.development.js



const { CleanWebpackPlugin } = require('clean-webpack-plugin');
const merge = require('webpack-merge');
const nodeExternals = require('webpack-node-externals');
const webpack = require('webpack');

const common = require('./webpack.common.js');

module.exports = merge.smart(common, {
  mode: 'development',
  watch: true,
  entry: {
    api: './src/main.js'
  },
  externals: [
    nodeExternals({
      whitelist: ['webpack/hot/poll?1000']
    })
  ],
  plugins: [
    new CleanWebpackPlugin(),
    new webpack.HotModuleReplacementPlugin()
  ]
});

Also an important note is that you will need to configure Nodemon to only listen for changes on ./dist/bundle.js. This prevents unnecessary reloads. You can do that with a nodemon.json in your root:



{
  "watch": ["dist/bundle.js"]
}

Now whenever you need to deploy, the below configuration would be suitable for production. You could deploy it to your Kubernetes and simply start the ./dist/bundle.js or combine this setup with for example the Serverless framework to run it on AWS Lambda, Azure or Google Cloud.

webpack.production.js



const CleanWebpackPlugin = require('clean-webpack-plugin')
const merge = require('webpack-merge')
const nodeExternals = require('webpack-node-externals')
const path = require('path')

const common = require('./webpack.common.js')

module.exports = merge(common, {
  devtool: 'source-map',
  entry: [path.join(__dirname, 'src/main.js')],
  externals: [nodeExternals({})],
  mode: 'production',
  plugins: [new CleanWebpackPlugin()]
})

That's it. I can now simply create a ./src file and build my application by simply following the Apollo Server documentation!

Again: Here's the Webpack Apollo Server example repository.

Conclusion

Webpack is a powerful tool that can be used for both app and API development, but it's easy to drown in its feature set tricking you into thinking that it's more like for example a Node server. When that happens, remember what Webpack actually is - A very powerful and pluggable conveyor belt that 'packs' your app.

In later articles I will focus more on the actual setup side of a project and how you could structure your project to make it simple, but very scalable using patterns like the above Webpack setup.