7 ms·

Front End Development Guide for Large Engineering Teams

172 points by yangshun 9y ago

acemarke 9y ago
It's an excellent set of advice and resources. Good explanations of why each topic matters and what it includes, with links to a few selected resources for each topic and an estimate for study time. I've already added it to my standard advice for getting started with React. I'm _very_ pleased to note that the guide links to my "(R)Evolution of Web Development" presentation [0] and my React/Redux links list [1], and that a number of the other articles referenced are definitely based on my links list contents too :) (Also, for good measure, I'll toss in a link to my "Intro to React and Redux" presentation here as well [2].) [0] http://blog.isquaredsoftware.com/presentations/2016-10-revolution-of-web-dev/ http://blog.isquaredsoftware.com/presentations/2016-10-revol... [1] https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links [2] http://blog.isquaredsoftware.com/2017/02/presentation-react-redux-intro/ http://blog.isquaredsoftware.com/2017/02/presentation-react-...
acconrad 9y ago
I was hoping this would be a guide on managing architectures, common use case traps for handling things like scalability and state. Instead this is just a long-winded way of recommending an opinionated front-end tech stack with resources to learn those stacks. Was not exactly what I was hoping for.
- paradite 9y ago
  This guide is more for beginners who just joined or want to join big tech companies. But I can see that your suggestions would make a great "power up as beginners" guide.
  - foota 9y ago
    I think parent is asking for a guide for structuring large front end projects for intermediate-experienced front end developers.
    - paradite 9y ago
      Oh, I see. That would also be great.
- BigJono 9y ago
  Yep, this is just rehashing the same stuff you can find on any one of 1000 other blog posts, articles or pieces of documentation. The current literature on front-end development in React is woefully short on real world case studies. It seems like everyone is building 30k loc throwaways with a 40 library boilerplate and slathering the internet with masturbatory praise for all the tooling and architectural patterns involved. If you try and Google for any actual details about said libraries, it's buried under mounds of beginner tutorials and faux praise. For example, we just made the decision to use ImmutableJS in a project. Everyone else on the team seems to be happy enough just reading a few blog posts about how great it is and then throwing it into the mix. I have a bunch of questions though, where are all the benchmarks? The docs, and everyone else, claims massive speedups from using immutable data structures, but it's never accompanied by any actual metrics, at least as far as my Google-fu gets me. All of our data lists are paginated server side, we're not doing any mass inserts on large data structures anywhere, and I've never noticed a performance problem on anything else I've written with similar requirements, so I find the claim that ImmutableJS is somehow going to speed up our app to be dubious at best. Moreover, every article under the sun craps on about how great it is to "enforce immutability", but nobody seems to be able to tell me when they last encountered a bug due to an inadvertant mutable update, how much time it cost them, or why they're hiring people who make such elementary mistakes in the first place; or if they do, it's some airy parable with no code example of the bug or the ImmutableJS code that could have fixed it.
  - z3t4 9y ago
    You don't need a library. Just have a policy that everything should be immutable by default and only turn into mutable objects when optimizing, for example for-loops. The benefit with immutability is not performance (it's actually slower) but manageability and debug-ability. It's easier to reason about code when the variables doesn't change, and you'll get all the variable-states when debugging. Example: var foo = 1; var bar = foo + 1;
    - didgeoridoo 9y ago
      The "Performance" section of Facebook's own React docs has this line at the end: "Immutable data structures provide you with a cheap way to track changes on objects, which is all we need to implement shouldComponentUpdate. This can often provide you with a nice performance boost." What I don't really get is, if you've implemented PureComponent and shouldComponentUpdate wherever possible, how can adding Immutable possibly improve performance? I.e. if your components are ASSUMING their inputs are immutable, how does throwing errors on mutation attempts actually speed things up?
- merrvk 9y ago
  Yeah thats what i was hoping for as well, if anyone has seen a piece like that i'd love to see it.
- celim307 9y ago
  Anyone know of a good article/series dealing with this? Tooling is fine and well, but I just got bumped to a lead role, with no one more experienced than me around, and could desperately use some more guidance.
- awkwarddaturtle 9y ago
  At least it wasn't another rant about how RDBMs suck and how great NoSQL or mongodb is or why can't I just store data in a json file. Baby steps. I try to see the silver lining in every cloud.
darklrd 9y ago
It's a great guide with excellent suggestions along the way. I would suggest adding few links on React Optimization to it. A guide on how to break React components and how to implement store/state once you start to scale would be very helpful. :)
- acemarke 9y ago
  This guide is meant as an overview of an array of technologies. My React/Redux links list, on the other hand, has you covered :) See the "React Performance", "React Architecture", "React Component Patterns", and "Redux Architecture" sections: [0] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md https://github.com/markerikson/react-redux-links/blob/master... [1] https://github.com/markerikson/react-redux-links/blob/master/react-architecture.md https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md https://github.com/markerikson/react-redux-links/blob/master... [3] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md https://github.com/markerikson/react-redux-links/blob/master...
  - andrewjrhill 9y ago
    Your list has been absolutely instrumental in my path towards mastering react/redux. A big thank you for all the hard work. You are multiplying the communities knowledge and we're all improving because of it.
    - acemarke 9y ago
      Thanks! Comments like yours are why I keep working on updating my lists :)
  - darklrd 9y ago
    Wow. This is exactly what I was looking for! Thanks a lot for creating and sharing this list.
smt88 9y ago
EDIT: My mistake. I found it. This is incomplete (to the point of being harmful) if it doesn't discuss and assess compile-to-JS, especially TypeScript.
- biggestlou 9y ago
  There is a section on TypeScript and Flow
  - smt88 9y ago
    I scrolled down and searched and didn't find it. Not sure why it didn't work.
partycoder 9y ago
The wide adoption of Flow and TypeScript means that people are starting to realize that explicitly typed code is easier to maintain than implicitly typed code. Hopefully a new EcmaScript version adds the ability to specify types. It's either that or people opting out of JS in favor of wasm based tech in the near future.
- tracker1 9y ago
  I think it largely falls to the size and discipline of the teams doing the work. I get by pretty well without them, but if I had to coordinate with over 20 other developers working in a single codebase, then I'd have a differing opinion. I'd also be pushing for 100% test coverage as it's FAR easier to do in JS than it is in other languages. Of course, adding types makes it harder again.
  - fedlarm 9y ago
    I used to share this opinion as well, until I started working on an internal library that was created by a skilled developer. He had very good test coverage and good quality tests, which turned out invaluable, once I got on board. We tried to move to library towards being fully typed in TypeScript, just to get some experience with TypeScript. Our first thought before starting was, that it would help, but didn't expect it to have a significant impact. During the port to TypeScript (and being strict on typing everything possible), we soon found numerous unexpected behaviors in the code. Some of the issues found, could have been found by a linter, but other things like models changing over time was only found due to adding static types. After this experience I changed my opinion towards the value of static types, from being more than a nice to have feature.
CryoLogic 9y ago
Funny, if you just suggested EmberJS you could cut out a large portion of this guide. Good guide nonetheless for those looking to hack together their own front-end stack.
flor1s 9y ago
Maybe I'm confused, but I always thought front-end development included graphics design. It seems like this guide does not discuss graphics design at all. I don't just mean Photoshop, but also subjects like when/where to use which color, typography, etc. Also this guide contains no information about other product design disciplines such as requirements gathering etc. I was working for a Dutch company a few years ago and our front-end developers worked closely with the graphics designers and the back-end developers to be able to properly do their work. We also had a business analyst who was working more on requirements gathering. In the end the entire team was however responsible for creating a good product for the customer.
- HappyTypist 9y ago
  I've never heard of front end development include graphics design.
  - flor1s 9y ago
    I guess in the company I was working for we valued employees with T-shaped skills (https://en.wikipedia.org/wiki/T-shaped_skills https://en.wikipedia.org/wiki/T-shaped_skills), in which people have one discipline in which they are experts (such as HTML/CSS/JS and the supporting infrastructure) and they have enough experience with the related disciplines (i.e. graphics design, requirements engineering, back-end development) to collaborate with experts in that field.
    - chao- 9y ago
      While that naming sounds a bit too MBA-ish for my ears, it does a good job capturing a concept that I have been trying to pin down for a while now in terms of the types of job candidates that have worked out best for me. Thank you for the metaphor, and for what it's worth, I agree in it being a desirable skill distribution. Incidentally, people at our company who have acquired said combination of wide skill breadth with a specific skill depth, got there because one employer or another (not always us) hired them when they were intent on (or already in the process of) a change of role. For instance, someone with a few years in graphics design who, when given a chance to (or being required to) work with HTML and CSS, found that not only did they like it, they wanted to learn and do more, even if that meant transitioning There are all sorts of questions I have about how that might fit into the arc of someone's career, how it affects salaries, and so on. Furthermore, I do not think it should be the only lens by which to assess people's skills, at the exclusion of all else. It just seems that many of our A-Players, as it were, came into our organization with that sort of skill distribution, or quickly grew to have it.
kuharich 9y ago
Grab is the Southeast Asia rival to Uber. Their stronghold is in Singapore, but they're the market leader in that region. Alibaba is looking to invest in their $1.4 billion upcoming round led by Softbank. I know for a fact that they are creating a technical, iOS development center of excellence in Seattle ...
- flor1s 9y ago
  Or maybe the Southeast Asia rival to Didi Chuxing?
  - kuharich 9y ago
    Excellent point. My American bias is showing ...
sidhuko 9y ago
"At Grab, we use ES2015 (with Babel Stage-0 preset) to enjoy the productivity boost from the syntactic improvements the future of JavaScript provides and we have been loving it so far." You've not been using it that long then! Stay alive and stick with Stage-3
- tracker1 9y ago
  Well, async/await and several other features were held up at stage1/2 for a long while. I found quite a few things very valuable far earlier on... async/await, object rest/spread, class (static) property syntax. Now most of it is stage-3 or in-browser, so not a bad decision, but for a long time, you really wanted to be at stage-0/1 and deal with a bit of pain should things change.
  - sidhuko 9y ago
    Async/await was the pitfall for one project as they weren't just held up but they changed API during experimental implementations. Less concerning now you can write codemods to transform but if you don't own the code it's better to keep your client a little behind and safer.
graphememes 9y ago
This is less for "Large Engineering Teams" and more for beginners who don't know about the current landscape. The second issue I have with this is that it is an opinionated tech stack which can lead to poor choices.
daliwali 9y ago
There's nothing in this guide that couldn't be found on 1000s of other introductory blog posts. This is just "What to Use With React 2017". I find it almost disturbing that front-end jobs around the world have adopted a set of opinionated tools that are so needlessly complex and churn at an amazing rate, and devs themselves have such a cavalier attitude about it. The self-congratulatory praise is deafening.
kayimbo 9y ago
and.... my eyes glaze over.
mrisoli 9y ago
This was a disappointing read, coming from such a large company, looking like a disposable blog post. It makes it sound like front end development is about knowing CSS, react and redux, these are good options of tools for the job, not essential ones, especially when Vue and Angular are still big in the scene. Maybe I'm wrong about my own profession, as some other comments said, it is often blurry and in the past it used to be more related to graphics design even, but for me front end development is about programming, just as full stack but without worrying about business logic that is supposed to rely on the backend. This can include design(as in CSS, colors, grids, fonts, responsiveness), but also worrying about the delivery mechanisms(some API level knowledge, browser vendors), including performance(consider crappy or inconsistent networks).
mstijak 9y ago
For large apps and teams, I would recommend CxJS. CxJS is based on React and offers a more streamlined development experience with a built-in library of widgets and charts, themes (including Material), and other features such as form validation, form layouts, culture-sensitive number and date formatting, optional two-way data binding and much more. Full disclaimer: It's a commercial product and I'm the lead developer. https://cxjs.io https://cxjs.io
duncanmeech 9y ago
Yawn....just another React/Redux fan boy blog.
ng12 9y ago
I'm surprised that Flow is recommended over Typescript. Flow's main strength seems to be the ability to slowly integrate it into a large existing project. Since this guide seems to be targeted at new applications I don't see why Typescript wouldn't be the better choice.
dlwdlw 9y ago
I've always disliked these top down plans that require so much setup and upfront work. The best tools I've worked with are progressive in their discovery and mastery of features without lowering the ceiling too much. Sublime for example has a command palette to just fuzzy type your desired command as a fallback, showing the shortcut key right next to the command as well. Vue also markets itself as having this type of "progressiveness". Reminds me of vim fans. There's always an undercurrent of elitism or hazing where something "hard" must be done to be "worthy" of some sort of goodness.

172 points by yangshun 9y ago

It's an excellent set of advice and resources. Good explanations of why each topic matters and what it includes, with links to a few selected resources for each topic and an estimate for study time. I've already added it to my standard advice for getting started with React. I'm _very_ pleased to note that the guide links to my "(R)Evolution of Web Development" presentation [0] and my React/Redux links list [1], and that a number of the other articles referenced are definitely based on my links list contents too :) (Also, for good measure, I'll toss in a link to my "Intro to React and Redux" presentation here as well [2].) [0] http://blog.isquaredsoftware.com/presentations/2016-10-revolution-of-web-dev/ http://blog.isquaredsoftware.com/presentations/2016-10-revol... [1] https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links [2] http://blog.isquaredsoftware.com/2017/02/presentation-react-redux-intro/ http://blog.isquaredsoftware.com/2017/02/presentation-react-...

acconrad 9y ago

I was hoping this would be a guide on managing architectures, common use case traps for handling things like scalability and state. Instead this is just a long-winded way of recommending an opinionated front-end tech stack with resources to learn those stacks. Was not exactly what I was hoping for.

paradite 9y ago
This guide is more for beginners who just joined or want to join big tech companies. But I can see that your suggestions would make a great "power up as beginners" guide.
- foota 9y ago
  I think parent is asking for a guide for structuring large front end projects for intermediate-experienced front end developers.
  - paradite 9y ago
    Oh, I see. That would also be great.
BigJono 9y ago
Yep, this is just rehashing the same stuff you can find on any one of 1000 other blog posts, articles or pieces of documentation. The current literature on front-end development in React is woefully short on real world case studies. It seems like everyone is building 30k loc throwaways with a 40 library boilerplate and slathering the internet with masturbatory praise for all the tooling and architectural patterns involved. If you try and Google for any actual details about said libraries, it's buried under mounds of beginner tutorials and faux praise. For example, we just made the decision to use ImmutableJS in a project. Everyone else on the team seems to be happy enough just reading a few blog posts about how great it is and then throwing it into the mix. I have a bunch of questions though, where are all the benchmarks? The docs, and everyone else, claims massive speedups from using immutable data structures, but it's never accompanied by any actual metrics, at least as far as my Google-fu gets me. All of our data lists are paginated server side, we're not doing any mass inserts on large data structures anywhere, and I've never noticed a performance problem on anything else I've written with similar requirements, so I find the claim that ImmutableJS is somehow going to speed up our app to be dubious at best. Moreover, every article under the sun craps on about how great it is to "enforce immutability", but nobody seems to be able to tell me when they last encountered a bug due to an inadvertant mutable update, how much time it cost them, or why they're hiring people who make such elementary mistakes in the first place; or if they do, it's some airy parable with no code example of the bug or the ImmutableJS code that could have fixed it.
- z3t4 9y ago
  You don't need a library. Just have a policy that everything should be immutable by default and only turn into mutable objects when optimizing, for example for-loops. The benefit with immutability is not performance (it's actually slower) but manageability and debug-ability. It's easier to reason about code when the variables doesn't change, and you'll get all the variable-states when debugging. Example: var foo = 1; var bar = foo + 1;
  - didgeoridoo 9y ago
    The "Performance" section of Facebook's own React docs has this line at the end: "Immutable data structures provide you with a cheap way to track changes on objects, which is all we need to implement shouldComponentUpdate. This can often provide you with a nice performance boost." What I don't really get is, if you've implemented PureComponent and shouldComponentUpdate wherever possible, how can adding Immutable possibly improve performance? I.e. if your components are ASSUMING their inputs are immutable, how does throwing errors on mutation attempts actually speed things up?
merrvk 9y ago
Yeah thats what i was hoping for as well, if anyone has seen a piece like that i'd love to see it.
celim307 9y ago
Anyone know of a good article/series dealing with this? Tooling is fine and well, but I just got bumped to a lead role, with no one more experienced than me around, and could desperately use some more guidance.
awkwarddaturtle 9y ago
At least it wasn't another rant about how RDBMs suck and how great NoSQL or mongodb is or why can't I just store data in a json file. Baby steps. I try to see the silver lining in every cloud.

darklrd 9y ago

It's a great guide with excellent suggestions along the way. I would suggest adding few links on React Optimization to it. A guide on how to break React components and how to implement store/state once you start to scale would be very helpful. :)

acemarke 9y ago
This guide is meant as an overview of an array of technologies. My React/Redux links list, on the other hand, has you covered :) See the "React Performance", "React Architecture", "React Component Patterns", and "Redux Architecture" sections: [0] https://github.com/markerikson/react-redux-links/blob/master/react-performance.md https://github.com/markerikson/react-redux-links/blob/master... [1] https://github.com/markerikson/react-redux-links/blob/master/react-architecture.md https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/react-redux-links/blob/master/react-component-patterns.md https://github.com/markerikson/react-redux-links/blob/master... [3] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md https://github.com/markerikson/react-redux-links/blob/master...
- andrewjrhill 9y ago
  Your list has been absolutely instrumental in my path towards mastering react/redux. A big thank you for all the hard work. You are multiplying the communities knowledge and we're all improving because of it.
  - acemarke 9y ago
    Thanks! Comments like yours are why I keep working on updating my lists :)
- darklrd 9y ago
  Wow. This is exactly what I was looking for! Thanks a lot for creating and sharing this list.

smt88 9y ago

EDIT: My mistake. I found it. This is incomplete (to the point of being harmful) if it doesn't discuss and assess compile-to-JS, especially TypeScript.

biggestlou 9y ago
There is a section on TypeScript and Flow
- smt88 9y ago
  I scrolled down and searched and didn't find it. Not sure why it didn't work.

partycoder 9y ago

The wide adoption of Flow and TypeScript means that people are starting to realize that explicitly typed code is easier to maintain than implicitly typed code. Hopefully a new EcmaScript version adds the ability to specify types. It's either that or people opting out of JS in favor of wasm based tech in the near future.

tracker1 9y ago
I think it largely falls to the size and discipline of the teams doing the work. I get by pretty well without them, but if I had to coordinate with over 20 other developers working in a single codebase, then I'd have a differing opinion. I'd also be pushing for 100% test coverage as it's FAR easier to do in JS than it is in other languages. Of course, adding types makes it harder again.
- fedlarm 9y ago
  I used to share this opinion as well, until I started working on an internal library that was created by a skilled developer. He had very good test coverage and good quality tests, which turned out invaluable, once I got on board. We tried to move to library towards being fully typed in TypeScript, just to get some experience with TypeScript. Our first thought before starting was, that it would help, but didn't expect it to have a significant impact. During the port to TypeScript (and being strict on typing everything possible), we soon found numerous unexpected behaviors in the code. Some of the issues found, could have been found by a linter, but other things like models changing over time was only found due to adding static types. After this experience I changed my opinion towards the value of static types, from being more than a nice to have feature.

CryoLogic 9y ago

Funny, if you just suggested EmberJS you could cut out a large portion of this guide. Good guide nonetheless for those looking to hack together their own front-end stack.

flor1s 9y ago

Maybe I'm confused, but I always thought front-end development included graphics design. It seems like this guide does not discuss graphics design at all. I don't just mean Photoshop, but also subjects like when/where to use which color, typography, etc. Also this guide contains no information about other product design disciplines such as requirements gathering etc. I was working for a Dutch company a few years ago and our front-end developers worked closely with the graphics designers and the back-end developers to be able to properly do their work. We also had a business analyst who was working more on requirements gathering. In the end the entire team was however responsible for creating a good product for the customer.

HappyTypist 9y ago
I've never heard of front end development include graphics design.
- flor1s 9y ago
  I guess in the company I was working for we valued employees with T-shaped skills (https://en.wikipedia.org/wiki/T-shaped_skills https://en.wikipedia.org/wiki/T-shaped_skills), in which people have one discipline in which they are experts (such as HTML/CSS/JS and the supporting infrastructure) and they have enough experience with the related disciplines (i.e. graphics design, requirements engineering, back-end development) to collaborate with experts in that field.
  - chao- 9y ago
    While that naming sounds a bit too MBA-ish for my ears, it does a good job capturing a concept that I have been trying to pin down for a while now in terms of the types of job candidates that have worked out best for me. Thank you for the metaphor, and for what it's worth, I agree in it being a desirable skill distribution. Incidentally, people at our company who have acquired said combination of wide skill breadth with a specific skill depth, got there because one employer or another (not always us) hired them when they were intent on (or already in the process of) a change of role. For instance, someone with a few years in graphics design who, when given a chance to (or being required to) work with HTML and CSS, found that not only did they like it, they wanted to learn and do more, even if that meant transitioning There are all sorts of questions I have about how that might fit into the arc of someone's career, how it affects salaries, and so on. Furthermore, I do not think it should be the only lens by which to assess people's skills, at the exclusion of all else. It just seems that many of our A-Players, as it were, came into our organization with that sort of skill distribution, or quickly grew to have it.

kuharich 9y ago

Grab is the Southeast Asia rival to Uber. Their stronghold is in Singapore, but they're the market leader in that region. Alibaba is looking to invest in their $1.4 billion upcoming round led by Softbank. I know for a fact that they are creating a technical, iOS development center of excellence in Seattle ...

flor1s 9y ago
Or maybe the Southeast Asia rival to Didi Chuxing?
- kuharich 9y ago
  Excellent point. My American bias is showing ...

sidhuko 9y ago

"At Grab, we use ES2015 (with Babel Stage-0 preset) to enjoy the productivity boost from the syntactic improvements the future of JavaScript provides and we have been loving it so far." You've not been using it that long then! Stay alive and stick with Stage-3

tracker1 9y ago
Well, async/await and several other features were held up at stage1/2 for a long while. I found quite a few things very valuable far earlier on... async/await, object rest/spread, class (static) property syntax. Now most of it is stage-3 or in-browser, so not a bad decision, but for a long time, you really wanted to be at stage-0/1 and deal with a bit of pain should things change.
- sidhuko 9y ago
  Async/await was the pitfall for one project as they weren't just held up but they changed API during experimental implementations. Less concerning now you can write codemods to transform but if you don't own the code it's better to keep your client a little behind and safer.

graphememes 9y ago

This is less for "Large Engineering Teams" and more for beginners who don't know about the current landscape. The second issue I have with this is that it is an opinionated tech stack which can lead to poor choices.

daliwali 9y ago

There's nothing in this guide that couldn't be found on 1000s of other introductory blog posts. This is just "What to Use With React 2017". I find it almost disturbing that front-end jobs around the world have adopted a set of opinionated tools that are so needlessly complex and churn at an amazing rate, and devs themselves have such a cavalier attitude about it. The self-congratulatory praise is deafening.

kayimbo 9y ago

and.... my eyes glaze over.

mrisoli 9y ago

This was a disappointing read, coming from such a large company, looking like a disposable blog post. It makes it sound like front end development is about knowing CSS, react and redux, these are good options of tools for the job, not essential ones, especially when Vue and Angular are still big in the scene. Maybe I'm wrong about my own profession, as some other comments said, it is often blurry and in the past it used to be more related to graphics design even, but for me front end development is about programming, just as full stack but without worrying about business logic that is supposed to rely on the backend. This can include design(as in CSS, colors, grids, fonts, responsiveness), but also worrying about the delivery mechanisms(some API level knowledge, browser vendors), including performance(consider crappy or inconsistent networks).

mstijak 9y ago

For large apps and teams, I would recommend CxJS. CxJS is based on React and offers a more streamlined development experience with a built-in library of widgets and charts, themes (including Material), and other features such as form validation, form layouts, culture-sensitive number and date formatting, optional two-way data binding and much more. Full disclaimer: It's a commercial product and I'm the lead developer. https://cxjs.io https://cxjs.io

duncanmeech 9y ago

Yawn....just another React/Redux fan boy blog.

ng12 9y ago

I'm surprised that Flow is recommended over Typescript. Flow's main strength seems to be the ability to slowly integrate it into a large existing project. Since this guide seems to be targeted at new applications I don't see why Typescript wouldn't be the better choice.

dlwdlw 9y ago

I've always disliked these top down plans that require so much setup and upfront work. The best tools I've worked with are progressive in their discovery and mastery of features without lowering the ceiling too much. Sublime for example has a command palette to just fuzzy type your desired command as a fallback, showing the shortcut key right next to the command as well. Vue also markets itself as having this type of "progressiveness". Reminds me of vim fans. There's always an undercurrent of elitism or hazing where something "hard" must be done to be "worthy" of some sort of goodness.