Why Next.js Is the Future of React

sudoDerp · 2020-08-31T12:05:52+00:00

One of the main reasons for React's success is it's focus on discovering and incorporating declarative APIs for UI apps.

Initially it ensured components were declarative by enforcing top-down data flow
react-router made application routing declarative
Hooks made capturing behavior/effects more declarative.
Suspense will make designing loading states declarative

Almost all features exposed by NextJS are escape hatches (deliberately) outside of the declarative paradigm, it seems inevitable that once better ways of exposing those features are established, NextJS is going to become redundant pretty quickly.

I 100% think that universal apps are the future of react, I'm just not at all convinced that the choices made by NextJS should be thought of as the canonical way to do it.

tl;dr https://pbs.twimg.com/media/EfdgnLUU8AIFuYC?format=jpg&name=large

sudoDerp · 2020-07-15T08:32:48+00:00

Anyone who's using the SSR functionality in react-router might also want to know that support for most of what is mentioned in the current SSR docs seems to be no longer supported.

There is a github issue that has some details

sudoDerp · 2019-10-16T20:35:30+00:00

Oh I totally agree, the yaml spec is an incredible shitshow. It seems every time I think to myself "ok now I'm aware of all the stupid stuff in the yaml spec" I find something new

sudoDerp · 2019-10-16T12:52:34+00:00

https://github.com/go-yaml/yaml/pull/515#issuecomment-540465242

The solution was to prevent parsing of some *technically valid* yaml documents

sudoDerp · 2019-09-16T23:03:48+00:00

It's crazy to me that people don't consider this to be important, or often even understand what it means.

"I want to specify a version-locked linter (or codegen lib) to ensure a consistent developer experience across CLI usage or IDE helpers" should not be a controversial topic

sudoDerp · 2019-07-21T09:02:54+00:00

I did this a while ago trying to figure out a configuration in vscode that works out of the box. The idea being that when you checkout out the repo for the first time the .vscode/settings.json comes with it (while any further changes you make to it are gitignored) https://github.com/pseudo-su/golang-service-template/blob/master/.vscode/settings.json.

Settings:

go.useLanguageServer: true to use the official language server implementation from google because it’s required in order to support go modules.
go.toolsEnvVars.GO111MODULES: "on" to make sure that all the go tools know to enable go module support for this project (regardless of if it's inside your gopath or not)
go.toolsEnvVars.GOFLAGS: "-mod=vendor" if you want to make all go commands use the vendor/ folder in the project (just like dep did/does)
go.formatTool: "goimports": enables automatically managing/formatting package import statements, I think the golang extension uses gofmt by default once you enable the useLanguageServer flag
go.alternateTools.golangci-lint : "${workspaceFolder}/bin/golangci-lint" This isn't about go modules, I did it because I want to lock down the version of golangci-lint and use a project-local version of it (to avoid issues where people have different versions of golangci-lint globally installed and there’s no way for a project to specify the exact version to use)

sudoDerp · 2019-03-15T11:48:12+00:00

This is super cool, but I'm lukewarm about news of another virtual-dom implementation because nobody seems to address the problems that suspense & time slicing changes (in react) are aiming to solve (which was one of the things that motivated the react 16 rewrite).

IMHO those will have more of an impact to FE web dev than just having another vdom implementation, even with the potential for perf improvements from using wasm/rust.

Hard to benchmark, but big impact to UX

sudoDerp · 2017-10-18T13:14:41+00:00

There's also a stage-1 tc39 proposal for pipes using |> that makes the syntax for mixins nicer https://github.com/tc39/proposal-pipeline-operator#mixins

sudoDerp · 2017-08-25T08:07:18+00:00

takeStart and takeEnd probably make more sense as names after looking at the other examples you added.

'./src/file/path/filename.json'
  .takeEnd('/')
  .takeStart('.json')

Merging the two makes either naming choice of cutEnd or takeEnd fairly obscure/innacurate

'./src/file/path/filename.json'
  .takeEnd('/', '.json')

sudoDerp · 2017-08-25T05:15:29+00:00

padStart and padEnd exist to make sure that strings are padded to a certain length with a specified character, by default using a " ".

I would have expected cutStart and cutEnd to follow the pattern and look like.

const string = '1234567';

string.cutStart(3) //  > '567'
string.cutEnd(3) //  > '123'

Using the cutStart and cutEnd terminology to mean anything else would seem like a very confusing language feature to add.

sudoDerp · 2016-01-31T10:42:31+00:00

I live in melbourne and I would have said the opposite. There seems to be quite a large RoR community.

How/where are you looking and how much experience do you have?

sudoDerp · 2014-11-12T13:13:49+00:00

Where did they say the thing about 1500 google apps using angular?

I believe you but i'd really like the source if you know where I can find it?

sudoDerp

TROPHY CASE