Betting my career on JAMstack.

Levi ᕙ(⇀‸↼‶)ᕗ on March 02, 2019

My posting declined a bit around the start of the new year, but that has been because I have been pretty busy doing some things.. Those things are ... [Read Full]
Editor guide

Cool! I think this is a reasonably safe bet and a good time to get in.

JAMstack is not going to replace everything, but it is clearly a trend.


Thanks! I totally agree! : )


Bet your software engineering career on practices & principles instead of specific tech :)


I would argue that JAMstack is a practice and not a specific tech. This isn't "Betting my career on Gatsby"


Sorry, it's just a bundle of tech that will eventually get partially replaced (even though there will be legacy apps to stay).

I'm talking about:

  • principles of software design,
  • clean code,
  • XP principles (TDD, pairing, continuous integration and delivery, and others),
  • knowing enough different technologies that you're not afraid of any new tech because you can learn it in a few days to level that normal single-tech devs can do only in 6 months,
  • understanding of the product and business parts of any organization,
  • working effectively with people, communication and soft skills,
  • empathy.

Phone me when they replace JavaScript friendo.

Not sure what you’re getting at. Betting career on a single language or framework seems weird to me, even if it’s not going to go away.

I do JS/TS on the front-end side of my day-to-day work, and I also do Go/Ruby/Python for CLIs, Kotlin/Ruby/Go/Python for back-ends, and I do Kotlin/Swift for mobile apps. And I did in the past things like Clojure, Scala, and Haskell on production applications (both backend and frontend).

Also, within bounds of each language, I’m proficient at using at least 2-3 frameworks and a considerable amount of libraries.

What’s the point of betting a career on a single stack or language? I mean, what does it even mean?

Let’s tackle the meaning of the concept of betting:

Betting is very similar to gambling and in general any risk-taking.

That means that if JAMStack is no more, or not HOT, your career would be over, or would sustain serious damage that’ll take years to recover.

Is this true for what you’ve meant by “betting on JAMStack?”


Signed up on jamestack.courses :)
Looking forward to it~


Awesome! Hopefully I’ll have some stuff in the coming weeks.


Waste of time mate. Next.js is way better than Gatsby. It offers SSR, static export and the docs and quality of the framework are much, much better ;)
Next.js leaves Gatsby with the jaw on the floor ;)


I’ve used Next a lot, introduced it at American Express and now they use it a lot too. With that said, I prefer Gatsby quiet a bit. Next is a fine piece of technology though! Good to have to choose between such awesome choices.


This is a very naive and ill-informed opinion. Gatsby and Next both fulfill different needs and each framework focuses on improving DX/UX in different ways.



It's not. In the podcast you shared Wesbos said "Let's assume Next doesn't have static site export because if you need that, you should probably pick Gatsby".
Well... this is really bad assumption. With Next you may have much better quality framework that can do all what Gatsby can, and Gatsby is low quality chunk of code (did you see the source code?) with low quality docs, that can't do what Next does.

Btw. I used both for multiple projects.

better quality framework

Entirely subjective. Better in what ways? I'd argue Gatsby and Next have different strengths, which is exactly what I said in my comment. Neither is "better" than the other because that's a completely subjective statement.

[Next] can do all what Gatsby can

This is just wildly untrue. An extremely large percentage of Gatsby's framework is devoted to an opinionated GraphQL based data layer. Next does not provide any utilities or assumptions about your data sources. This can be considered a strength or weakness of Next based on your use cases. But to say that Next and Gatsby offer equivalent functionality is very misleading. Gatsby also provides Progressive Web App functionality and includes a vast plugin architecture. Next's surface area as a framework is overall much smaller than Gatsby'. Next is much less opinionated about how you fetch data and architect your web application, whereas Gatsby seeks to "control" more of your application's code. This is a classic difference in paradigms referred to as Convention over Configuration. Gatsby takes a more "convention" based approach, whereas Next favors "configuration".

Gatsby is a low quality chunk of code (did you see the source code)

Yes! In fact I'm a contributor! What issues have you seen with Gatsby's code base? I'm interested to know which parts of its architecture and code you found low quality.

low quality docs

I don't agree with this. I think Gatsby has excellent documentation and iirc has even made several hires since they became a startup for "Open Source Maintainers" focused on documentation and community.

[Gatsby] can't do what Next does

This is somewhat accurate. Gatsby cannot perform on-demand server-side rendering like Next can. They are different frameworks that do different things after all!

You ask why low quality:

github.com/gatsbyjs/gatsby/tree/ma... this is the code of its reducers
github.com/gatsbyjs/gatsby/tree/ma... Those are the tests... No tests. Sorry, a single file with low quality test to only one reducer with plenty of commented out code.
There is really not much logic in frontend projects. There where any logic is, there must be tests.

I think Gatsby has excellent documentation

Yeah, documentation that teaches you basics of JS, sounds like a child has written it (couldn't stand its manner), and present you with an example that works. Just the problem is, that if you change anything that would normally be fine it stops working and it doesn't explain why.

If you write an opinionated framework, make sure all the decisions are very clearly pointed out and explained in docs with great rationale behind that. Showing examples of working code, not explaining why it works, and saying "wow you are awesome, you've just built a site within 5 mins" really isn't the quality I would expect from a tool built by professionals for professionals. Maybe for people who doesn't understand how to code and need to create something... but then still, wordpress is better.

I'm not really sure what's soured your opinion of Gatsby so severely, but I've had quite the opposite experience to you building and shipping multiple production Gatsby and Next code bases. In my mind, Gatsby's what I reach for by default, but if I know I'll have custom use cases or need more backend functionality then Next is my choice. Also, with Next's recent addition of serverless-rendering (nextjs.org/blog/next-8/#serverless...) it will likely fit in a lot better to my existing serverless applications.

You've missed some tests for Gatsby's Redux actions/reducers here: github.com/gatsbyjs/gatsby/tree/ma...

Here's the test output I see for the redux directory in that particular package:

❯ yarn jest packages/gatsby/src/redux
yarn run v1.12.3
$ jest packages/gatsby/src/redux
 PASS  packages/gatsby/src/redux/reducers/__tests__/page-data-dependencies.js
  add page data dependency
    ✓ lets you add a node dependency (13ms)
    ✓ lets you add a node dependency to multiple paths (1ms)
    ✓ lets you add a connection dependency
    ✓ removes duplicate paths (1ms)
    ✓ lets you add both a node and connection in one action (5ms)

 PASS  packages/gatsby/src/redux/reducers/__tests__/config.js
  config reducer
    ✓ let's you add a config (19ms)
    ✓ handles empty configs (2ms)
    ✓ Validates configs with unsupported options (41ms)
    ✓ It corrects pathPrefixes without a forward slash at beginning (2ms)
    ✓ It removes trailing forward slash (1ms)
    ✓ It removes pathPrefixes that are a single forward slash (1ms)
    ✓ It sets the pathPrefix to an empty string if it's not set (1ms)

  console.log packages/gatsby/src/redux/reducers/config.js:16
    The site's gatsby-config.js failed validation

  console.log packages/gatsby/src/redux/reducers/config.js:19
    ValidationError: "someRandomThing" is not allowed

 PASS  packages/gatsby/src/redux/reducers/__tests__/redirects.js
    ✓ lets you redirect to an internal url (5ms)
    ✓ lets you redirect to an external url (1ms)
    ✓ lets you redirect using https (1ms)
    ✓ lets you redirect using http (1ms)
    ✓ lets you redirect using // (1ms)
    ✓ lets you redirect using ftp (1ms)
    ✓ lets you redirect using mailto (1ms)

 PASS  packages/gatsby/src/redux/__tests__/status.js
  Status actions/reducer
    ✓ allows setting plugin status (4ms)
    ✓ allows updating status (2ms)
    ✓ throws an error if status isn't an object (1ms)
    ✓ throws an error if the plugin name isn't set (1ms)

 PASS  packages/gatsby/src/redux/__tests__/jobs.js
  Job actions/reducer
    ✓ allows creating jobs (7ms)
    ✓ allows completing jobs (4ms)
    ✓ allows updating jobs (1ms)
    ✓ Allows you to set other info on the job
    ✓ throws an error if an ID isn't provided (1ms)
    ✓ throws an error if endJob is called for a job that's already ended (2ms)

 PASS  packages/gatsby/src/redux/__tests__/pages.js
  Add pages
    ✓ allows you to add pages (11ms)
    ✓ Fails if path is missing
    ✓ Fails if component path is missing (1ms)
    ✓ Fails if the component path isn't absolute
    ✓ Fails if use a reserved field in the context object (1ms)
    ✓ adds an initial forward slash if the user doesn't (2ms)
    ✓ allows you to add pages with context (1ms)
    ✓ allows you to add pages with matchPath (5ms)
    ✓ allows you to add multiple pages (2ms)
    ✓ allows you to update existing pages (based on path)
    ✓ allows you to delete paths (1ms)

 PASS  packages/gatsby/src/redux/__tests__/run-sift.js
    ✓ resolves fields before querying (1ms)
    filters by just id correctly
      ✓ eq operator (20ms)
      ✓ eq operator honors type (1ms)
      ✓ non-eq operator (1ms)

 PASS  packages/gatsby/src/redux/__tests__/babelrc.js
  Babelrc actions/reducer
    ✓ allows adding a new plugin (7ms)
    ✓ allows updating the options of an existing plugin (2ms)
    ✓ allows adding a new preset (1ms)
    ✓ allows updating the options of an existing preset (1ms)
    ✓ allows specifying the stage for the plugin
    ✓ allows specifying the stage for the preset (1ms)
    ✓ sets default presets/plugins if there's no userland babelrc (1ms)
    ✓ allows setting options
    ✓ allows setting options on a particular stage
    ✓ allows merging config items (1ms)

 PASS  packages/gatsby/src/redux/__tests__/nodes.js
  Create and update nodes
    ✓ allows creating nodes (14ms)
    ✓ allows updating nodes (2ms)
    ✓ nodes that are added are also "touched" (1ms)
    ✓ allows adding fields to nodes (1ms)
    ✓ throws error if a field is updated by a plugin not its owner (1ms)
    ✓ throws error if a node is created by a plugin not its owner (1ms)
    ✓ throws error if a node sets a value on "fields" (1ms)

Test Suites: 9 passed, 9 total
Tests:       61 passed, 61 total
Snapshots:   35 passed, 35 total
Time:        5.92s
Ran all test suites matching /packages\/gatsby\/src\/redux/i.
✨  Done in 7.51s.

I've never heard of documentation that was too beginner friendly, but if you want some more complex or involved documentation from Gatsby, check out some of their "behind the scenes" docs that explain the architecture decisions in Gatsby:

Gatsby also hosted a webinar recently that detailed a lot of the technical features included out of the box with Gatsby: gatsbyjs.com/behind-the-scenes/

You wonderful patient man lol

Code of Conduct Report abuse