No impetus like validation from someone you respect to get off your ass and get something you've been putting off done.
To understand this, I have two frameworks I'm using. The first is the concept of boilerplates and the second is the idea of popularity.
While we all like to claim that programming is a unique and a craft in itself, there are a lot of boring bits that we automate away. This is a good thing. Laziness is, after all, a virtue for a programmer. One way we've done this is by creating programs that can generate code for us. This ranges all the way from snippets (e.g. a keychord that inserts a python import guard) to frameworks (e.g. a command that generates most of the code for you and you just fill in the blanks). These things vary on various axes
- Size Snippets are usually quick way to insert a commonly used piece of code like a for loop header. Frameworks might generate several dozen lines of code
- Commitment If I use yasnippet on Emacs, I (and my team) can move away from it at a moments notice. If I use create-react-app, we have to follow its conventions and rules throughout the project. "Whatever a framework does for you, it also does to you"
- Configurability How much can you tweak a snippet? Contrast that with the number of command line arguments for a framework like create-react-app.
- Opinionatedness There's only so much opinion you can have for a small snippet. With a larger framework, there are design decisions which might not sit well with all people. This is also proportional to how passionate people revile or defend tools.
Boilerplates are, on the overall, a solution and not a problem but like all those, they come with compromises. These allow people to
- Speed up their development cycle with common best practices.
- Avoid common (sometimes expensive) mistakes. e.g. using OpenZeppelin rather than writing your own contracts avoids several security problems that are important for custom tokens.
- Done right, a tool can generate just enough code to solve your problem without taking away any power. A reasonable example are parser generators like Ragel or Bison. You can work on the interesting parts and leave the boring bits to the computer
So, on the overall, I think tools like these are necessary as well as useful. It's not right to think of them as "problems".
Another thing that has a bearing on this whole is the size and nature of the users and developers of the language.
It's highly unlikely that a toy language I designed in my own room on a dark night has people complaining about how the tooling for it is sub optimal. On the other hand, I'd bet good money that there's an argument brewing right now about whether you should use Next.js or nwb or whatever else is popular right now on some forum on the internet.
There are two kinds of languages. The ones that no one uses and the ones that everyone complains about.
Large user bases expose a large number of itches. Itchy programmers with an editor and an internet connection will scratch out solutions and put them online. Most of them will be emotionally invested into their own solutions. The end result of this will be, unsurprisingly, a large number of incompatible tools to do the same or similar tasks. To summarize,
high popularity => lots of itches => lots of tools(scratchers)
This is far from an ideal situation and as far as I can see, there are three ways to prevent this.
- One is to reduce the popularity. A smaller, narrower community (e.g. R is targeted towards statisticians , Haskell requires some amount of mathematical interest to truly enjoy etc.). Most developers wouldn't want to do this since they want their tools to be popular.
- A third way is to implement standards so that even if multiple tools exist, they can work nicely with each other and people can use what they want. This is easier said than done and in the real world, standards follow implementations rather than the other way round.
- It was originally a small language used only for the occasional bells and whistles on websites. There were no "front end developers". With the advent of NodeJs, they suddenly got a large number of developers in a single shot. Applications, Frameworks, Tools etc. all of them exploded. In short, *sudden* popularity.
Another relevant factor is that since the whole ecosystem wasn't really "engineered" but sort of organically mushroomed due to several events, there were many holes in it. I think this triggered the Inferior is Better phenomenon which allowed people to participate and the popularity to increase at the cost of creating several (some non compatible) tools.
All this being said, the question is whether this is a "bad thing". I don't think there's an objective answer here. Some people like a polished smooth experience without any choice. Some people prefer a highly configurable, always tweakable environment that they can go on making their own.
A second point is whether it needs to be "fixed"? On the question of boilerplates, there's no fixing that needs to be done. It's a genuine solution for genuine problem and over the years has done much more good than harm. On the question of popularity, there are some fights than can be avoided easily by careful planning and engineering. A good example is rolling in common tools into the standard distribution of a language so that many of these problems are gone. In other words, it's an ongoing evolution and while we might not reach the ideal solution, we'll definitely get better. The poorer tools will fall away due to lack of popularity and the good ones will surface to the top and take over. Just like how git is more or less the "standard" version control tool now.
My final thought is that this is a human problem and not one that can be solved through technology. Decisions of which tool should be used depend on what the developers are comfortable with, whether there is legacy code in the system, how active the development of the tools under consideration are. As for Sidu's original concern, there are always other tools which are better failing which it's an itch that needs to be scratched. 😉
Take advantage of our experience with all of these frameworks and more if you want to quickly build out your own products within budget and without delays. We at Hamon embrace the philosophy of "strong opinions weakly held" when we help our clients build out their software. Drop us an email at firstname.lastname@example.org. We'd be glad to help you out with your requirements.
Much thanks to @Swanand for reviewing a draft of this post and offering suggestions.