3 ms·

Sincere question, how many people work on this application or suite of applications? One, ten, twenty? It's as the number of developers grow on projects that t

Sincere question, how many people work on this application or suite of applications? One, ten, twenty? It's as the number of developers grow on projects that these things become nightmares. Having worked somewhere that used React and had extremely strict eslint and typescript settings, it was all so uniform (those type checking static linting really keep the guard rails on code quality) because you were guided to use the same effective patterns in solving those problems. In fact, all the interesting work started happening outside interactions with the framework (and more around redux, in this case) so we were more focused on business logic and other concerns, react fell straight into the background. There were only ~25 developers or so. The ecosystem and the framework really lent itself hand in hand. That shouldn't be left out of discussions like this. I can see this model falling flat on its face after about 6 developers working in this system, especially since there is no adjacent tooling that specifically made to keep the guard rails on code quality. I'd love to hear a counter example to that. Edit: my point is, in order for something to be an acceptable alternative to React, it needs to have the ability to thrive in an example like I gave. React isn't for the 1 man shop, per se, or even perhaps a team of 5-6 developers that can coordinate well. Its real strength is in large application development, with `n` number of developers, where n is greater than 6. Thats just been my experience.

lhorie 6y ago
I'm not familiar with crank.js adoption, but Lichobile (lichess mobile app) and flarum.org are two relatively large open source mithril.js codebases that I'm aware of. They are both several years old and have a decent number of contributors. IMHO, a lot of Mithril code looks like React code. Things like eslint/tsconfig can be setup equally strictly regardless. Having seen some truly gargatuan React apps, I'd actually argue that neither React nor Mithril do much to enforce structure aside from the componentization aspect (which, to be fair, is a big part of it). Ember, for example, is arguably far more prescriptive with regards to code structure consistency. What I do think is true of React and similar libraries/frameworks (think mithril, but also vue, svelte, etc) is that once you setup a structure of your liking, the path of least resistance tends to also be the happy path, i.e. even "copy-paste" programming generally ends up resulting in always making reasonably sized components, always using the state management mechanism idiomatically, etc.
spiffytech 6y ago
I appreciate your response because it brings nuance that is (in hindsight) negligent to leave out of this discussion. My projects can usually count all of the developers on one hand, often with fingers to spare. I get put on a rapid-file bevy of small projects rather than a single long-term project that grows into a large team. Time-to-MVP and rapid iterative redesign as the problem domain gets mapped out are the priorities in my projects, and light, non-prescriptive frontend frameworks work well for that in my experience. I think it makes a lot of sense to define different best practices for one-pizza projects than projects where 25 developers can be described as "only 25". There are a ton of developers at both ends of that spectrum, enough that I wish the broader web developer ecosystem would embrace that distinction.

lhorie 6y ago

I'm not familiar with crank.js adoption, but Lichobile (lichess mobile app) and flarum.org are two relatively large open source mithril.js codebases that I'm aware of. They are both several years old and have a decent number of contributors. IMHO, a lot of Mithril code looks like React code. Things like eslint/tsconfig can be setup equally strictly regardless. Having seen some truly gargatuan React apps, I'd actually argue that neither React nor Mithril do much to enforce structure aside from the componentization aspect (which, to be fair, is a big part of it). Ember, for example, is arguably far more prescriptive with regards to code structure consistency. What I do think is true of React and similar libraries/frameworks (think mithril, but also vue, svelte, etc) is that once you setup a structure of your liking, the path of least resistance tends to also be the happy path, i.e. even "copy-paste" programming generally ends up resulting in always making reasonably sized components, always using the state management mechanism idiomatically, etc.

spiffytech 6y ago

I appreciate your response because it brings nuance that is (in hindsight) negligent to leave out of this discussion. My projects can usually count all of the developers on one hand, often with fingers to spare. I get put on a rapid-file bevy of small projects rather than a single long-term project that grows into a large team. Time-to-MVP and rapid iterative redesign as the problem domain gets mapped out are the priorities in my projects, and light, non-prescriptive frontend frameworks work well for that in my experience. I think it makes a lot of sense to define different best practices for one-pizza projects than projects where 25 developers can be described as "only 25". There are a ton of developers at both ends of that spectrum, enough that I wish the broader web developer ecosystem would embrace that distinction.