Why are many of the biggest web frameworks in dynamically typed langs?
11 comments
> just want to know what makes a good web framework.
Personal opinion. A framework is an architecture in a box so that you, the developer, do not have to make as many decisions. Normally when developers are asking such questions they are seeking easiness: https://github.com/prettydiff/wisdom/blob/master/Easiness.md
Personal opinion. A framework is an architecture in a box so that you, the developer, do not have to make as many decisions. Normally when developers are asking such questions they are seeking easiness: https://github.com/prettydiff/wisdom/blob/master/Easiness.md
what makes a good web framework
Use.
Static or dynamic is just theory. Users don’t care. Customers don’t care. Investors don’t care.
The only people who care are people who would rather argue than build. People who want to be judged by their opinions rather than utility.
Sure, a person may have good reasons for preferences about them. But those are their preferences not someone else’s. They only matter insofar as you are working with them for money, fame, or goodwill.
In the end building is a lot of work and no choice avoids that. Maybe one will mean more gets done with the same amount of hard work. Maybe it doesn’t.
Either way the best way to avoid the hard work of building is by not building. Good luck.
Use.
Static or dynamic is just theory. Users don’t care. Customers don’t care. Investors don’t care.
The only people who care are people who would rather argue than build. People who want to be judged by their opinions rather than utility.
Sure, a person may have good reasons for preferences about them. But those are their preferences not someone else’s. They only matter insofar as you are working with them for money, fame, or goodwill.
In the end building is a lot of work and no choice avoids that. Maybe one will mean more gets done with the same amount of hard work. Maybe it doesn’t.
Either way the best way to avoid the hard work of building is by not building. Good luck.
The only thing that I can think of about dynamic languages is fast-paced development and productivity; in other words, deliver an MVP within hours, if you are an experienced user of <X> framework of your choice.
With a static typed programming language, there's always a cost of compilation time and expected problems with linking libraries.
I cannot tell you how many times I have started a project with a specific cause to solve a particular problem, only to find myself trapped in a massive trap of unknown, cryptic error messages in C++ madness that I had to decipher...until I have realized I have completely forgot what I was even doing!
Now with a dynamic language, I solve all my problems in no time, I deliver a prototype quite fast, and whenever speed is necessary, I can always fix it in multiple ways, for instance what Python currently offers me; in other words, I optimize my performance only when it becomes a bottleneck.
With a static typed programming language, there's always a cost of compilation time and expected problems with linking libraries.
I cannot tell you how many times I have started a project with a specific cause to solve a particular problem, only to find myself trapped in a massive trap of unknown, cryptic error messages in C++ madness that I had to decipher...until I have realized I have completely forgot what I was even doing!
Now with a dynamic language, I solve all my problems in no time, I deliver a prototype quite fast, and whenever speed is necessary, I can always fix it in multiple ways, for instance what Python currently offers me; in other words, I optimize my performance only when it becomes a bottleneck.
> With a static typed programming language, there's always a cost of compilation time and expected problems with linking libraries.
I have developed tons of applications in both Java and Ruby.
There was never a time when I thought "damn, all those hours I'm wasting due to compilation". Never. With a good IDE compilation happens completely transparent in the background during the development process.
If you really have substantial overhead from compilation another language will not solve your underlying issues.
I have developed tons of applications in both Java and Ruby.
There was never a time when I thought "damn, all those hours I'm wasting due to compilation". Never. With a good IDE compilation happens completely transparent in the background during the development process.
If you really have substantial overhead from compilation another language will not solve your underlying issues.
Those are older frameworks, back then dynamic typing was seen as a positive. But if you're building a graphql service with nodejs most likely you'll also use typescript for that.
IMO this is probably because most of these frameworks started with Ruby on Rails as an inspiration.
Using a compiled language to develop a webapp has a pretty horrible workflow, i.e. needing to recompile and restart a binary to see any change. Of course, that can be mitigated/automated-away in several ways, but it's still a tension.
WebAssembly may bring change here. See the recent HN discussion on emerging Gui libraries in Rust: https://news.ycombinator.com/item?id=35722681
how do you debug/profile webassembly?
Depends in what language you are developing. Tool support is being added everywhere. Here's Chrome WebAssembly support described: https://developer.chrome.com/blog/new-in-devtools-114/#wasm
Web sites tend to have either a lot of static content to serve, or are an interface to database queries of various sorts.
In both of these scenarios, the complexity isn't derived from writing algorithms and data structures that "go wrong" (which static types can help a lot with) but from gluing together the two ends - taking an HTTP request, making it do the thing with the database, and then returning a response. That's the genesis of the LAMP stack - Linux, Apache, MySQL, PHP. Four pieces that just need a little bit of scripting and configuration to turn into an app.
And at the outset, a lot of the benefit of using PHP or Perl was just in having some useful string handling that wouldn't cause a buffer overflow, and being able to test in production by editing the script instead of deploying new binaries. Cheap webhosts would always provide PHP because it kept the deployment so simple. But SQL injection attacks were common and data loss frequent, and a lot of framework features were built on those kinds of challenges - methods of safely handling user input, features for maintaining accounts and login sessions, unit testing, ORM, database migration, and so on. Since they mostly stay in the request-response framing and SQL is leaned on to handle the inner workings of the data, these are things that end up having relatively short, disposable code paths, which if they complexify into something needing more processing, can be offloaded into a fast native-code process that just does the inner loop. I think that approach keeps dynamic languages in the mix - the debugging can be compartmentalized, and so can the bits that need high performance - so it's mostly about features, defaults, deployment. None of the frameworks end up being a perfect fit after the app gets big, but they help start it on a course with some underlying structure. If you go big on the framework you'll have more defaults imposed on you, which can be convenient, but spending a lot of time evaluating them isn't as important as getting the frontend and the database right.
I've been doing some coding with the Symbol blockchain lately and it's served as a helpful comparison, because Symbol has a unique approach that does a lot of framework-like and database-like chores without the use of smart contracts: it persists data, it allows you to update the data's state and review previous versions, it lets you search by various parameters, and, of course, it transfers custody of data between accounts, implements access controls, and allows various kinds of transactions with atomicity. In many cases, the app can exist in client Javascript and access the chain over REST. I started off thinking I would have a Flask app, and now am just writing a single HTML file with everything inlined apart from the SDK used for building transaction data - the framework part of it evaporated. Which is great - fewer dependencies. The limitation is, well, it's a blockchain, and the type of data worth storing on a blockchain is the "wants to be shared widely with an expensive consensus" kind.
In both of these scenarios, the complexity isn't derived from writing algorithms and data structures that "go wrong" (which static types can help a lot with) but from gluing together the two ends - taking an HTTP request, making it do the thing with the database, and then returning a response. That's the genesis of the LAMP stack - Linux, Apache, MySQL, PHP. Four pieces that just need a little bit of scripting and configuration to turn into an app.
And at the outset, a lot of the benefit of using PHP or Perl was just in having some useful string handling that wouldn't cause a buffer overflow, and being able to test in production by editing the script instead of deploying new binaries. Cheap webhosts would always provide PHP because it kept the deployment so simple. But SQL injection attacks were common and data loss frequent, and a lot of framework features were built on those kinds of challenges - methods of safely handling user input, features for maintaining accounts and login sessions, unit testing, ORM, database migration, and so on. Since they mostly stay in the request-response framing and SQL is leaned on to handle the inner workings of the data, these are things that end up having relatively short, disposable code paths, which if they complexify into something needing more processing, can be offloaded into a fast native-code process that just does the inner loop. I think that approach keeps dynamic languages in the mix - the debugging can be compartmentalized, and so can the bits that need high performance - so it's mostly about features, defaults, deployment. None of the frameworks end up being a perfect fit after the app gets big, but they help start it on a course with some underlying structure. If you go big on the framework you'll have more defaults imposed on you, which can be convenient, but spending a lot of time evaluating them isn't as important as getting the frontend and the database right.
I've been doing some coding with the Symbol blockchain lately and it's served as a helpful comparison, because Symbol has a unique approach that does a lot of framework-like and database-like chores without the use of smart contracts: it persists data, it allows you to update the data's state and review previous versions, it lets you search by various parameters, and, of course, it transfers custody of data between accounts, implements access controls, and allows various kinds of transactions with atomicity. In many cases, the app can exist in client Javascript and access the chain over REST. I started off thinking I would have a Flask app, and now am just writing a single HTML file with everything inlined apart from the SDK used for building transaction data - the framework part of it evaporated. Which is great - fewer dependencies. The limitation is, well, it's a blockchain, and the type of data worth storing on a blockchain is the "wants to be shared widely with an expensive consensus" kind.
I have no experience in building big web apps and I would like to learn one of those big frameworks that come with a lot out of the box. Kind of curious to try Phoenix because Elixir seems fun and tooling around it seems good. On the other hand, I can’t really imagine not having types, so I’m thinking maybe I should try Spring boot with Kotlin instead (type system seems really nice).
Anyone has some thoughts on this? Not looking for general static/dynamic typing discussion, just want to know what makes a good web framework.