3 ms·
To me, this kind of 'magic' is definitely a double-edged sword. For the people that are familiar with the framework, I assume it makes it much nicer to write co
by mckirk 4y ago
To me, this kind of 'magic' is definitely a double-edged sword. For the people that are familiar with the framework, I assume it makes it much nicer to write code and to reason over it (at the above-framework level), since there's no boilerplate to write or understand.
But as someone who often has to jump into unknown codebases and get up-to-speed quickly, I've certainly been confused by framework magic before, which makes it almost impossible to reason 'up' from the concrete implementation of e.g. a request handler. Since the keywords to grep for aren't explicitly mentioned in the handler anywhere and the 'dispatch' side of things is hidden under mountains of abstraction, you usually have to resort to tutorials to understand what the hell is going on, and even then the codebase might use some extra-magical properties of the framework that aren't clear to anyone that isn't at home within it.
So it could be argued that this magic saves you code in exchange for a need for more documentation, at which point you might just be better off being more explicit in your code -- at least explicit enough so things remain greppable.
- nicoburns 4y agoI agree with this: > So it could be argued that this magic saves you code in exchange for a need for more documentation, But not this: > at which point you might just be better off being more explicit in your code Reason being that you only need to add documentation once (for the framework), and then you can have cleaner more readable code for every project using it. Yes, there’s magic enabling it, but shouldn’t need to worry about how it works if it’s well documented enough. And if you really need to know then you can read a post like this one which explains it.
- mckirk 4y agoThat is a fair point. I guess it basically comes down to preference: Should code be essentially self-explanatory, without needing to resort to external documentation to understand, or can frameworks be terse to the point of being a kind of DSL? I suspect most low-level programmers prefer the former ("It's all right there"), while dynamic-language coders feel comfortable with the latter ("I only want to be explicit where it's absolutely necessary.") As another top-level comment pointed out, Rust is interesting because it attracts both kinds of programmers, so it's no wonder the question of which approach to go with for a Rust framework isn't a trivial one to answer.
- kirse 4y agoBut as someone who often has to jump into unknown codebases and get up-to-speed quickly I'm not sure how long you've been in development but eventually you just learn to "expect magic" with frameworks and after awhile they all blur together. Show me the docs on the decorators, the pipeline, how it handles global context etc and it's all pretty much the same core concepts repeated across different languages. To your later point, yes, frameworks should be a terse DSL. I expect a framework to make good "magic" assumptions that enable me to benefit from packaged functionality that would often be more verbose in lower-level implementations. without needing to resort to external documentation to understand That's not a thing. RTFM. Or a good code inspection tool if you really hate docs.
- junon 4y agoWhat an assertive take that couldn't be more subjective and counter to what many (including myself) have experienced.
- kirse 4y agoYour ability to pop open vscode and slap some JS in it to start a web-server in a few lines is the product of decades of SW frameworks that have made thousands of assumptions along the way to increase expressive power while tucking complexity under the hood. Feel free to provide a counter-example vs a generic statement.
- runevault 4y agoYou just presumed everyone is a JS dev. Despite how hard it is trying to take over the world but not everyone writes javascript.
- cercatrova 4y agoSame as in this Rust example then. The Axum example is basically the same as its equivalent in JS. I've also seen similar abstraction in Python (Django, Flask), Ruby (Rails), Elixir (Phoenix) etc.