Well said. There are a million starter projects and examples each with a different mix of tools hooked up all in very different ways with tons of files and config. And lots of them with bugs or out of date.
The problem with the JS world is they can never coagulate around one solution. Everyone has this insatiable desire to roll their own. Next only works because it leaves out a bunch of stuff.
Instead of the examples/ directory they should build a plugin interface and roll out official integrations with lots of tools. This is the closest we would come to Rails.
A big problem is for anything to be successful it had to be similar enough to the last thing. E.g. all the new frameworks that look and feel like React. Every new thing is constrained and sticky taped onto the older thing. So no one can ever step back and ask themselves what the truly ideal thing is.
It’s crazy and impressive how we devs created this fucking huge industry where hundreds of millions was spent to solve a problem that didn’t really exist and actually made things harder and more expensive.
I was thinking the same thing recently. I’ve finally realized that React is painful and overly complex. I just followed the crowd and got too deep. Backbone was elegant and simple. I could step through all the code being executed with my debugger. React is impossible to step through and the error messages are still terrible. It’s like an entirely new programming language and runtime. This “it’s just javascript” bullshit is so far from the reality now.
There is sooooo much you have to think about when writing a good React component with hooks and to ensure it remains performant and is bug free.
I really want to go back to basics. Using as little framework as possible.
I’d much rather something simple that I have full control
over and that I can trace the entire execution with a debugger than all this magic crap.
I don’t even like JSX. I always pass an object in like: ‘<Foo {…fooProps} />’. Would much rather just use a literal js object.
I feel like React is a lot like dependency injection frameworks. The initialization code you would have to write without using one is actually very simple and straightforward.
Is it really that difficult to manually render components as needed? Do we actually need this huge runtime vdom overhead? Or any of these other compilers/transpilers.
Note of caution on point 2. If you still do a lot of coding, this can really impede on your productivity, and break you out of any flow state.
When an employee asks you a question, you will feel like you don't want to be abrupt and will find yourself taking a few minutes each time.
I find a lot of the time employees will come with questions they could have asked over slack/chat that would have not broken my flow, and could be resolved quickly with a link, etc.
Its much better to develop a consensus on how to best use productivity tools asynchronously, and optimise your flow.
E.g.
- Instead of walking over - ask on slack first.
- If something is less urgent, link to Trello card/Github issue/etc. with more details.
On Slack, using the right channels/rooms is important too. Serendipity and collaboration from overheard conversations is really really important. Physically overhearing discussions that you could weigh in on can save huge amounts of time and catch problems early on, but can be a distraction. In flow/with headphones you lose this ability to overhear. Having public chat rooms you can monitor regularly is the best. Avoiding employees private messaging each other is the goal.
I want to stress that this is much more easily said than done.
- A lot of programmers gain immense satisfaction from writing nice code, and getting into "flow". There will be less of this, and you have to rewire your reward system and vicariously experience this through your team. If you already get more satisfaction from shipping and having users use your product/module/apis rather than how elegant your code or apis are, then you are heading in the right direction.
An earlier comment on this page sums up the goal:
> Your satisfaction changes from being happy that you've polished some nice bit of code to being happy that you've shipped a product and successfully run a group, and gained the admiration of the people on your team and in your company. Competence is it's own reward.
- You must prepare yourself to watch others implement things you would love to do yourself, in a less-optimal, and less-clean way than you might have. Its harder if the codebase is your baby that you wrote from scatch. Instead of coming out of a project with new skills, new familiarity with modules, code that you could open-source, satisfaction from having written nice modular, maintainable and testable code, you will only have the satisfaction of the hitting a deadline.
- Coding less allows more time for you to ask your team what they need, think about what they need but don't realize, and get that for them.
- Giving feedback is an art. You want to keep a positive, upbeat repore with your colleagues. If you empathize too much about how the developer will feel when you deliver criticism you will end up doing it less and not being as honest. Finding the right words will make it easier for yourself to deliver, and will create less tension.
- Hiring people like yourself who write code similar to you will make life much easier - but often you have to money-ball your team, and make do with what you have.
- Creating an atmosphere where employees can all talk about problems, and personal mistakes, without feeling judged by their peers is important. Encourage everyone to acknowledge their failings, and identify improvements. "What did everyone learn this week/sprint? What could you do better?". As soon as employee holds back, everyone will start because they will fear they are underperforming. If someone is falling behind, others in the team should be thinking how they can assist their colleague, rather than looking at it as an opportunity to stand out. Standups are great for this. Make sure its not only one person asking for help at the standup.
The problem with the JS world is they can never coagulate around one solution. Everyone has this insatiable desire to roll their own. Next only works because it leaves out a bunch of stuff.
Instead of the examples/ directory they should build a plugin interface and roll out official integrations with lots of tools. This is the closest we would come to Rails.