I'm pretty sure all four are internally consistent.
When it comes to solution approaches there is no universal model to consistency ("All models are wrong, but some are useful", remember).
What is important is that once you are equipped with the mental model that is appropriate for the framework/library that everything is predictable.
The Principle of Least Astonishment (POLA) isn't an unassailable law; it fails to acknowledge that an individual's level of surprise is directly correlated to their past individual experience. So what level of "majority experience" is required for POLA to be valid?
JavaScript is most despised because it isn’t some other language. If you are good in some other language and you have to program in an environment that only supports JavaScript, then you are forced to use JavaScript, and that is annoying. Most people in that situation don’t even bother to learn JavaScript first, and then they are surprised when JavaScript turns out to have significant differences from the some other language they would rather be using, and that those differences matter.
[Douglas Crockford, JavaScript - The Good Parts, 2008; p.2]
For decades JavaScript has aggravated developers worldwide because it didn't meet the expectations set by their first or favourite language. That didn't stop JavaScript from "eating the world". If JavaScript surprises you then your "mental model of JS" is faulty.
Similarly when switching between frameworks/libraries it should be expected that adjustments to one's mental models have to be made. (OK, that part sucks but that's the cost of doing business.) Ideally any tool should adopt the internal consistency model that allows it to operate the most efficiently and effectively as an end product (i.e. "in production").
That said every effort should be made in the documentation for that tool to lay bare the optimal mental model so that developers don't have to waste time "being surprised" during the on boarding process.
There is a reality that all abstractions/models are imperfect but I dislike being reminded of it in such an obvious way. I never feel I can choose one, yet I think the most important part is choosing. And it's one of those things where certain options feel more correct to me, but I dislike the implications. And in so I end up just disliking all the options.
The truth is this example is such a small piece of the overall puzzle so it doesn't matter much. But just enough when you have to explain to someone why you made the specific choice.
I guess I have some thoughts on that. I think DX is overvalued, but I think the focus on it from tool builders isn't. Honestly it is why all of this stuff exists. Even Qwik. Otherwise go vanilla over some PHP or whatever. I generally say UX over DX, but the truth is there is always some way to make better performance, some lower level you can go, but the challenge is making it accessible.
Even if the focus is too far, it's a very hard place to step back from. Almost table stakes to have that DX story. I don't see unless we hit something critical for that to change. So it won't, for now. More solutions continue to get more complicated. It's concerning to me.
I think there are steps in the right direction, though. I haven't used Solid, but IMO Svelte (despite being a variation on the theme of complex local tool stacks and compiling to rather than authoring browser compatible code) is a few degrees different in a good way, especially if you used Rollup instead of Webpack (or use SvelteKit, now). The design and results seem to make fewer extreme tradeoffs between UX and DX. There's definitely still a big ol' industry wide problem, but this next generation of things slowly gaining prominence give me some hope. 'Course, I've said that before and it's still, um, the way it is, mostly.
I'm not allergic to build steps obviously, and I think they achieve things otherwise basically impossible. That new tooling might hide the complexity but it doesn't change the nature of it.
My concern about complexity is more on SSR/Hydration/Compilation side. It is exceedingly hard to achieve what we want without more advanced compilers. Solid compiles but only JSX, just like React and most historical JS frameworks. There is something nice there from the portability standpoint and that there is a clear division between JavaScript and your DSL. You can pick it up use as much or as little as you want and slice it however you want.
What seems to be coming is that we will need compilation to re-order end user code. This troubles me. Svelte, React Forget, Marko, Qwik.. maybe soon Solid.. I've been trying to see if there is another path without handing the keys over. But where I am right now it looks unlikely. So I'm going to attack it piecewise.
So it isn't about build step existing. But figuring out how we can make sense of the code we write. Is it still JavaScript? Maybe the answer is it shouldn't be and we need all encompassing DSLs but I have to ask the question.
On the positive performance is getting some attention again which is good. But it's 2 sides of the same coin.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Really?
I'm pretty sure all four are internally consistent.
When it comes to solution approaches there is no universal model to consistency ("All models are wrong, but some are useful", remember).
What is important is that once you are equipped with the mental model that is appropriate for the framework/library that everything is predictable.
The Principle of Least Astonishment (POLA) isn't an unassailable law; it fails to acknowledge that an individual's level of surprise is directly correlated to their past individual experience. So what level of "majority experience" is required for POLA to be valid?
[Douglas Crockford, JavaScript - The Good Parts, 2008; p.2]
For decades JavaScript has aggravated developers worldwide because it didn't meet the expectations set by their first or favourite language. That didn't stop JavaScript from "eating the world". If JavaScript surprises you then your "mental model of JS" is faulty.
Similarly when switching between frameworks/libraries it should be expected that adjustments to one's mental models have to be made. (OK, that part sucks but that's the cost of doing business.) Ideally any tool should adopt the internal consistency model that allows it to operate the most efficiently and effectively as an end product (i.e. "in production").
That said every effort should be made in the documentation for that tool to lay bare the optimal mental model so that developers don't have to waste time "being surprised" during the on boarding process.
「If JavaScript surprises you then your "mental model of JS" is faulty.」
LOL
There is a reality that all abstractions/models are imperfect but I dislike being reminded of it in such an obvious way. I never feel I can choose one, yet I think the most important part is choosing. And it's one of those things where certain options feel more correct to me, but I dislike the implications. And in so I end up just disliking all the options.
The truth is this example is such a small piece of the overall puzzle so it doesn't matter much. But just enough when you have to explain to someone why you made the specific choice.
The "why" is important and should be clearly documented so that there are no mental gaps in the puzzle.
Also more and more personalities like Miško Hevery and Stefan Judis are expressing concern about the current hyper-focus on DX.
Rust gave us the notion of "Zero Cost Abstraction". Perhaps we need more "Zero Cost DX".
I guess I have some thoughts on that. I think DX is overvalued, but I think the focus on it from tool builders isn't. Honestly it is why all of this stuff exists. Even Qwik. Otherwise go vanilla over some PHP or whatever. I generally say UX over DX, but the truth is there is always some way to make better performance, some lower level you can go, but the challenge is making it accessible.
Even if the focus is too far, it's a very hard place to step back from. Almost table stakes to have that DX story. I don't see unless we hit something critical for that to change. So it won't, for now. More solutions continue to get more complicated. It's concerning to me.
I think there are steps in the right direction, though. I haven't used Solid, but IMO Svelte (despite being a variation on the theme of complex local tool stacks and compiling to rather than authoring browser compatible code) is a few degrees different in a good way, especially if you used Rollup instead of Webpack (or use SvelteKit, now). The design and results seem to make fewer extreme tradeoffs between UX and DX. There's definitely still a big ol' industry wide problem, but this next generation of things slowly gaining prominence give me some hope. 'Course, I've said that before and it's still, um, the way it is, mostly.
I'm not allergic to build steps obviously, and I think they achieve things otherwise basically impossible. That new tooling might hide the complexity but it doesn't change the nature of it.
My concern about complexity is more on SSR/Hydration/Compilation side. It is exceedingly hard to achieve what we want without more advanced compilers. Solid compiles but only JSX, just like React and most historical JS frameworks. There is something nice there from the portability standpoint and that there is a clear division between JavaScript and your DSL. You can pick it up use as much or as little as you want and slice it however you want.
What seems to be coming is that we will need compilation to re-order end user code. This troubles me. Svelte, React Forget, Marko, Qwik.. maybe soon Solid.. I've been trying to see if there is another path without handing the keys over. But where I am right now it looks unlikely. So I'm going to attack it piecewise.
So it isn't about build step existing. But figuring out how we can make sense of the code we write. Is it still JavaScript? Maybe the answer is it shouldn't be and we need all encompassing DSLs but I have to ask the question.
On the positive performance is getting some attention again which is good. But it's 2 sides of the same coin.