I've read about some principles for a front end developer, and here is some comments from me.
Cannot agree more, this is the spirit of engineer, if not only for front end developers.
This is a principle of design or constructor, over design is always here. Overthinking complex to show skills is a waste.
DRY is something like weak version of tech specification. I'll prefer specification as good thing. If something like solution or function or UI or some lines of code are made as a specification, I will leave it in one place and won't repeat it anymore. On the other hand, if some logic or business are changing too often, it's OK to repeat it for a while, since no-one knows what the specification will be. On a higher viewpoint, this is the point why a company will start some similar projects in slightly different domains. Something called horse racing. But at the very end, this will be only one winner which will turns to the specification. It will tough and pain for other candidate to adapt it.
This is another principle to handle complicated problems, though how to divide and conquer is a tough question.
I'd like to think about DSL as a great thing, HTML or XML could be thought as a DSL. It's nothing bad for such a term of tech, only when or how to use it. As a question, DSL could grow up very dramatically. It turns hard to read, maintain, test and extend. As a first thought. Graphic UI could be used to describe DSL. It's the idea of low code development platform, another example is that developer could use tools like storyboard in XCode to deal with DSL describes iPhone UI. It's the intuitive way to think how to solve this problem, but as the DSL grows up, graphic UI couldn't solve it all, and the UI will turns into mess. Same question turn out, hard to ready, maintain, test and extend. The second thought is something called secondary development solution, which will turn DSL into specified code. As an example, for front end, the solution will turn the DSL into JSX / CSS / HTML. Usually, this a one-way journey. And it's very hard to elevate the readability and extendibility. The key of how to think about it, is the word DOMAIN in DSL. Every DSL has a limitation. Developers should think ahead if the scenario meets the restriction. And the DSL designer should make it clear how to classify whether the DSL should be use. It's hard to forsee whether a platform or a DSL meets some requirement. DSL could only solve 70% maybe 80% of all problems in a specified domain. But the value DSL creates is hard to ignore. As for ToB scenarios, DSL is quite potential to rule it. For example there could a DSL to describe a recruitment, like the steps need to proceed, emails need to send, approvers, interview arrangement etc. To help corps without recruitment system but with different recruit flow to build a online system.
First post in english, anything good or bad, please let me know.