So my first question is: is it really a framework? Or is it a library? And how can you tell?
A rule of thumb I picked up from somewhere is that "you call libraries, frameworks call you". Which is pithy and easy to remember, and sounds true so :shrug:.
I've decoupled the rendering from the game logic to the point where it could be separated out into its own external standalone library. It provides a set of traits you can implement for your game's types which fully handle creating the canvas element, mounting your app to it, and handling clicks. All you need to do is plug in the drawable widgets and it organizes your layout for you.
I'm so hazy on Rust right now that I can't even tell whether this is calling my code or I'm calling it!
Does any sufficiently large project end up with its own highly decoupled bits of logic like this?
Only if it's done right! But decoupling the logic doesn't mean that you've built a framework - you can architect your code around, say, MVC, without it being a 'framework'. So much of what you've said is really just the proper architecting of a project - keeping concerns separated.
You can write a nice UI library that describes and solves your problem domain - and I'm a big fan of building a language 'up' to meet the problem; writing a DSL (domain specific language) that I can use to solve my problem in.
I guess I think it's a framework when
it solves a ridiculously generic problem (like building a web server + database + etc..)
Haha, right, right, don't say the "F" word around David :)
Good point - "framework" is likely not the correct word to apply to this solution. It sits around where React sits, but for a canvas - view layer only, but handles the view entirely.
It's a bit of both, though - I call it when I implement these traits (interfaces) for my types, but then it takes over and manages the entry point - it has some setup code that runs before everything else, and then manages the whole lifecycle of the running application, calling my code when needed to re-render. That's what makes it feel like a framework to me. I refactored away my own app's entry point, and now this separate apparatus handles those details.
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.
Oh Ben, oh why oh why oh why ;)
Why You Shouldn't Use A Web Framework
David Wickes ・ Jul 26 '18 ・ 4 min read
So my first question is: is it really a framework? Or is it a library? And how can you tell?
A rule of thumb I picked up from somewhere is that "you call libraries, frameworks call you". Which is pithy and easy to remember, and sounds true so :shrug:.
I'm so hazy on Rust right now that I can't even tell whether this is calling my code or I'm calling it!
Only if it's done right! But decoupling the logic doesn't mean that you've built a framework - you can architect your code around, say, MVC, without it being a 'framework'. So much of what you've said is really just the proper architecting of a project - keeping concerns separated.
You can write a nice UI library that describes and solves your problem domain - and I'm a big fan of building a language 'up' to meet the problem; writing a DSL (domain specific language) that I can use to solve my problem in.
I guess I think it's a framework when
Haha, right, right, don't say the "F" word around David :)
Good point - "framework" is likely not the correct word to apply to this solution. It sits around where React sits, but for a canvas - view layer only, but handles the view entirely.
It's a bit of both, though - I call it when I implement these traits (interfaces) for my types, but then it takes over and manages the entry point - it has some setup code that runs before everything else, and then manages the whole lifecycle of the running application, calling my code when needed to re-render. That's what makes it feel like a framework to me. I refactored away my own app's entry point, and now this separate apparatus handles those details.