What's great is that signals and fd_sets are supported, so it can really tie the web services and the hardware together nicely. I can easily wire up GPIO, for example.
I haven't dug into Microdot yet - but are there similar mechanisms? I love my Lua projects based on TurboLua, but wouldn't mind seeing some python chops get sharpened, same-wise ...
Edit: I dug in, and I guess the things I want are to be found in the python batteries included anyway .. plus, Microdot is a very small tack-on to microPython, and a pleasure to read ..
Right. Microdot just gives you the support to build the web application. This is built on top of the standard asyncio Python library, so you are likely to find good support for most tasks in the ecosystem.
It's important to note that for most small devices that run MicroPython asyncio is the only available method of concurrency.
These devices have no concept of processes, your application is the only thing that runs. Most devices do not support threads, and those that do have really big limitations. Like for example, a device with two cores would allow you to spawn just one thread, to run on the second core and that's it. This is due to the lack of a proper operating system with a scheduler that can move threads in and out of the CPU.
Yes .. alas .. eLua doesn’t natively handle multi-core execution, so any cross-CPU functionality requires custom integration. It is is small, light, and tight as things go - but nevertheless, coroutines and core-specific tasking can yield benefits in the power-consumption stats, too.
I will definitely push microPython for some use where it'll fit ..
I really love this post. The author did a great job with their writeup, and that probably came from a clear presentation.
I'm fascinated by your approach where you used your own temperature and humidity monitors. Apologies if this is in the links in the article, but I wondered how you controlled your heating unit. The reason I ask is that I have a nest device talking to my AC unit, which means I'm locked into the Google ecosystem. It works well, but it doesn't connect to the Home Assistant system for everything else in the house. I would like to remove the Nest dependency, or at least have multiple ways I could start optimizing the power utilization of my AC unit.
Thanks. The smart heating device in question is one that is fairly popular in Ireland, but I believe it isn't sold elsewhere. The brand is Climote (https://www.climote.ie/).
As part of the service, this controller gives you the option to send commands through an app, or by sending SMS (the device comes with a SIM card and gets its own mobile number). The commands would allow you to ask if the heating is running or not, to turn the heating on or off, and so on.
I first implemented the SMS interface with Twilio, but then found that the number of texts you can send to the device is capped. I don't remember what was the monthly allowance, but I reached it in a few days after querying the device every 15 minutes or so 24/7.
I then found a project on GitHub with the reverse-engineered API that the phone app used to send commands. So I then reimplemented the command logic using this API to be able to talk to the controller without limitations.
I'm not familiar with the Nest devices, but I'd suggest you do a search on GitHub to see if someone figured how to reverse-engineer its API.
Nest devices do integrate, sort-of, with Home Assistant. But, the process is to create an "app" inside the Nest + Google home automation ecosystem. It is an absolute mess and there is nothing to be gained by going into that Mordor. I tried to get it working, and gave up, but I would much rather use a device that is "hackable." That device you mentioned looks great, and does not appear to be available outside of Ireland, as you noted. But, I'm going to use that as an inspiration point and see if I can find something similar. Maybe that manufacturer has awareness of a US-based device provider, I'll contact them.
Really appreciate you sharing this work, really fun stuff!
If you're in north America (probably elsewhere, but I can only say for NA) then changing the thermostat is super simple to do. If your system is 24v, which is very likely, then swapping the nest device for something better isn't too complicated. I can't provide a brand recommendation, but I'd find a thermostat that supports homeassistant and has a reverse engineered API available.
Directly controlling the HVAC with a relay board would also be very doable, but is a more involved project.
I installed my nest, and it was indeed very simple. And, it appeared to work with Home Assistant, but like I said, the devil is in the details. It was a very frustrating experience.
The problem is that if I look here I cannot tell the first thing about which device is supported and how well. HA does not have a great filtering system.
I looked at your benchmark article. I would like to see how many requests per second these SoCs with your server can manage on a simple task (printing the current time) - both with http and https.
Yes, I also wanted to comment on the benchmark article[1], because it seems you looked at compute-bound performance rather than rps (requests per second) on simple data. Given that what you made, MicroDot, is a web server, it would make more sense to stress it rather than MicroPython and the SoC, no? That would seem to be more of the purview of the MicroPython and/or SoC devs.
You got it backwards. If I were to release a benchmark for Microdot, everyone would say that it is biased!
The article you are referring to is intended to benchmark microcontrollers running MicroPython. Nothing to do with Microdot.
I'm not really sure what conclusions you expect to reach if you had a Microdot benchmark that gives you a requests per second number. I would not stop using microcontrollers if the number was low, and I wouldn't start more projects if the number was high. I don't really care. It works for the intended purpose.
I think it would be valuable to decide if the performance is sufficient for a desired purpose.
If the performance is insufficient you may need to switch to something written in a compiled language or to a faster platform. That's why the RPS is useful.
This is true for any kind of project, regardless of hardware or software stack. You always need to evaluate the performance for the specific use case you are targeting to make sure it falls in the expected range, and it is your job to do this evaluation as the project owner, because only you know the specifics of your project.
The point I was trying to make in my reply above was that an abstract RPS number, obtained measuring a general purpose web app on a general purpose microcontroller does not mean anything. What matters is your own performance evaluation.
I think there is a fundamental misunderstanding caused by the OP's article. It mischaracterizes your blog post as a performance test of microdot, but as you say, it has nothing to do with it. Still, a baseline, best-case RPS number is a useful number to associate with microdot for various reasons; it cannot, of course, take the place of testing the real application, but what it can do is give implementers and upper-bound on IOPs to a device via HTTP/S. Take that as you will. Microdot is a very cool project, kudos for doing it and sharing it.
You are more than welcome to evaluate Microdot on the specific device you are interested in. It is good to keep in mind that people don't run web apps on microcontrollers because they have good performance. Don't expect any miracles.
I need to measure temperature at multiple points and humidity in my experimental garden shed with a skytherm roof [ http://www.solarmirror.com/fom/fom-serve/cache/30.html ] for passive heating and cooling. Thinking your thermostat code might be 90% of what I need however I don't yet know python. I guess it's easy to understand and modify the code with the help of AI.
I wanted to use MicroPython for this. I have nothing against C, it is a language that I actually know and use for other projects, but I wanted the challenge to try to build something similar to Flask or FastAPI that could run well on small devices.
Numerous comments on the “impossibly small” bit in the title. It makes me wonder if it was put there as a bit of tongue in cheek, less as a brag. E.g. The “it doesn’t have to be that big” Microdot web framework (which I honestly first thought had something to do with Microdot anti theft devices that they put on cars around me).
Elsewhere on HN right now is a post about a dermatologist vibecoding an app for skin stuff. I view the “need/use ai for coding” as an indictment against how complex software development has become. What I think we marvel at is the surprise that sometimes reall can be just that simple. 99% of the people who are using Django/flask/etc don’t really understand how they work under the hood all that well. And so it’s always an “is that all??” moment when we do these “back to the basics” exposé’s where we show that 80% of our needs are covered by something simple and understandable.
> Elsewhere on HN right now is a post about a dermatologist vibecoding an app for skin stuff. I view the “need/use ai for coding” as an indictment against how complex software development has become.
There's a reason why, in the late 90s and early 2000s, people were able to jump out of non-technical careers into development using languages like ASP and ColdFusion. There were some shortcomings of the stacks of the day, but functionally, the ability to meet many business cases really hasn't changed since those days.
... and Excel and Access. So much shadow IT got developed because Excel (+VBA, which is almost as powerful as regular VB6, including calls to the native win32 DLL API) is present everywhere, and Access is pretty widespread as well.
I read somewhere that the number of Excel "programmers" is an order or magnitude larger than all professional programmers in all other languages put together.
I got my start in professional software development by building an multi-user Access shadow-IT database application that made heavy use of VBA. It only worked because it had a couple of active users at any time, and I left that workplace with documentation consisting of a half-page of bullet points. I know for certain that it was still in usage four years after I left, though God know how long it kept operating in the end.
Notwithstanding that shadow IT is the bane of my existence these days, I sometimes need to be reminded of how far a motivated individual can come when they have access to adequate tools and information.
> Elsewhere on HN right now is a post about a dermatologist vibecoding an app for skin stuff. I view the “need/use ai for coding” as an indictment against how complex software development has become
One other way to look at it is that software is realizing enough of the dreams of reusability that cobbling together scripts at such a high level with only the smallest understanding is finally becoming possible. I'm not going full Pangloss here, development is still a massive clusterfuck in many places and probably always will be by its nature, but the frontiers have pushed waaaaay back since I got started.
Reusability is a big part of it, but I also think languages are just a lot more abstract and expressive these days, so fewer lines of code goes further. Empirically, error count is correlated with lines of code, as are hallucinations, so the ideal language for AI coding is the most abstract and expressive language that will get you there.
All these years later, and I can't get over the fact that Flask began as an April fool's joke, making fun of Bottle and other microframeworks. I guess the joke failed completely.
Joke is Python never made it a front end web language given how easy it was for JS to become a backend and how many of these Python frameworks actually copy off JS, even though Python is older and from a perspective - neater…
This makes no sense. Of course it's easier for a language in a browser to release an executable than a language with an executable to be embedded in a browser. Also, why are we even talking about JS?
Brother Ставри, tell me how exactly does JS run without an executable? Sorry you miss the fact JS’s executable was initially bundled with Netscape WHIcH was the executable.
Your argument makes even less sense. Executable or not, the suitability of the language for certain task is what is/was being discussed here.
I’d argue both Python and JS got where they were thanks to early adoption of Perl’s regex (another language) and the fact they are so symbolic in nature.
And we talk about JS here for apparent reasons - the web. Like we talk python most of the time when we talk ML right so?
Sounds like this framework is comparable in size to the original Rails, which clocked in at under 1000 lines of code (microdot is 765 lines per the article).
I don't know if the original Rails would have run on mruby though (if it had existed at the time), and Rails certainly did a lot of things the author of microdot would have considered "dark magic".
It’s great on esp32 with MicroPython. Even has support for server sent events (SSE). Paired with htmx, SSE gives some fun intetactive web experience for iot devices - instant GPIO status indicators etc. Loved tinkering with it. The source code is very readable too.
The last large app I built in CFML (ColdFusion) was based on FW/1, which is a MVC framework in less than 1800 lines (including comments). No external dependencies, but to be fair, the CFML application server bakes in pretty much every dependency that most applications would ever need.
Having pulled down a copy just now, the framework itself is 526 lines of PHP, and the sample site (a newsfeed that pulls from the BBC) is perhaps 300 lines in models and controllers. I use the framework to this day to serve out my blog and other small sites, seems to work well without getting in the way.
Version 2 of Microdot incorporates feedback received from users of earlier releases, and attempts to improve and correct some design decisions that have proven to be problematic.
For this reason most applications built for earlier versions will need to be updated to work correctly with Microdot 2. The Migration Guide describes the backwards incompatible changes that were made.
I'm not sure there's anything "impossible" about how small this is. You don't really need a lot of lines of code to support routes, request and response and nothing else. If anything, 765 lines of code for this is quite a lot.
It also uses libraries for most "extensions" that are available, defeating the purpose and bending the claim that it's 1,700 lines of code including the extensions. Just jinja, one of the dependencies, is 18,000 lines of code. If that counts my Nanodot server which calls flask.app.run() is one line...
To clarify this, note that the extensions are entirely optional, and unlike what you are saying, most do not require any dependencies.
The only two extensions that use dependencies are the one that adds template rendering, and the one that implements secure user sessions.
For templates, you can use Jinja on CPython (where you wouldn't normally have space issues), or the uTemplate library (https://github.com/pfalcon/utemplate) on MicroPython, which is quite small.
For secure sessions, on CPython you have to add PyJWT. On MicroPython you need to add the HMAC and JWT modules from the MicroPython standard library, which are not installed by default. These are also very small.
> I'm not sure there's anything "impossible" about how small this is. You don't really need a lot of lines of code to support routes, request and response and nothing else. If anything, 765 lines of code for this is quite a lot.
How do you explain why virtually all frameworks end up requiring an order of magnitude more LoC?
Not necessarily. For example, some minimal web frameworks actually provide multiple routing strategies because different implementation strategy have tradeoffs.
Are they, though? I mean, is it a feature to make something usable? If you have hard performance constraints and you know what routes you need to suppport, a generic but prohibitively expensive routing strategy can prevent you from using the framework.
Always a nice surprise to find my stuff on the front page. If you have any questions about Microdot, I'm here to answer them!
For my embedded needs, I've relied heavily on TurboLua, which I find really kicks some serious butt:
https://turbo.readthedocs.io
What's great is that signals and fd_sets are supported, so it can really tie the web services and the hardware together nicely. I can easily wire up GPIO, for example.
I haven't dug into Microdot yet - but are there similar mechanisms? I love my Lua projects based on TurboLua, but wouldn't mind seeing some python chops get sharpened, same-wise ...
Edit: I dug in, and I guess the things I want are to be found in the python batteries included anyway .. plus, Microdot is a very small tack-on to microPython, and a pleasure to read ..
Right. Microdot just gives you the support to build the web application. This is built on top of the standard asyncio Python library, so you are likely to find good support for most tasks in the ecosystem.
related: Python has had async for 10 years – why isn't it more popular? - https://news.ycombinator.com/item?id=45106189 - Sep, 2025 (293 comments)
It's important to note that for most small devices that run MicroPython asyncio is the only available method of concurrency.
These devices have no concept of processes, your application is the only thing that runs. Most devices do not support threads, and those that do have really big limitations. Like for example, a device with two cores would allow you to spawn just one thread, to run on the second core and that's it. This is due to the lack of a proper operating system with a scheduler that can move threads in and out of the CPU.
Yes .. alas .. eLua doesn’t natively handle multi-core execution, so any cross-CPU functionality requires custom integration. It is is small, light, and tight as things go - but nevertheless, coroutines and core-specific tasking can yield benefits in the power-consumption stats, too.
I will definitely push microPython for some use where it'll fit ..
I really love this post. The author did a great job with their writeup, and that probably came from a clear presentation.
I'm fascinated by your approach where you used your own temperature and humidity monitors. Apologies if this is in the links in the article, but I wondered how you controlled your heating unit. The reason I ask is that I have a nest device talking to my AC unit, which means I'm locked into the Google ecosystem. It works well, but it doesn't connect to the Home Assistant system for everything else in the house. I would like to remove the Nest dependency, or at least have multiple ways I could start optimizing the power utilization of my AC unit.
Thanks. The smart heating device in question is one that is fairly popular in Ireland, but I believe it isn't sold elsewhere. The brand is Climote (https://www.climote.ie/).
As part of the service, this controller gives you the option to send commands through an app, or by sending SMS (the device comes with a SIM card and gets its own mobile number). The commands would allow you to ask if the heating is running or not, to turn the heating on or off, and so on.
I first implemented the SMS interface with Twilio, but then found that the number of texts you can send to the device is capped. I don't remember what was the monthly allowance, but I reached it in a few days after querying the device every 15 minutes or so 24/7.
I then found a project on GitHub with the reverse-engineered API that the phone app used to send commands. So I then reimplemented the command logic using this API to be able to talk to the controller without limitations.
I'm not familiar with the Nest devices, but I'd suggest you do a search on GitHub to see if someone figured how to reverse-engineer its API.
Nest devices do integrate, sort-of, with Home Assistant. But, the process is to create an "app" inside the Nest + Google home automation ecosystem. It is an absolute mess and there is nothing to be gained by going into that Mordor. I tried to get it working, and gave up, but I would much rather use a device that is "hackable." That device you mentioned looks great, and does not appear to be available outside of Ireland, as you noted. But, I'm going to use that as an inspiration point and see if I can find something similar. Maybe that manufacturer has awareness of a US-based device provider, I'll contact them.
Really appreciate you sharing this work, really fun stuff!
If you're in north America (probably elsewhere, but I can only say for NA) then changing the thermostat is super simple to do. If your system is 24v, which is very likely, then swapping the nest device for something better isn't too complicated. I can't provide a brand recommendation, but I'd find a thermostat that supports homeassistant and has a reverse engineered API available.
Directly controlling the HVAC with a relay board would also be very doable, but is a more involved project.
I installed my nest, and it was indeed very simple. And, it appeared to work with Home Assistant, but like I said, the devil is in the details. It was a very frustrating experience.
The problem is that if I look here I cannot tell the first thing about which device is supported and how well. HA does not have a great filtering system.
https://www.home-assistant.io/integrations/#climate
I looked at your benchmark article. I would like to see how many requests per second these SoCs with your server can manage on a simple task (printing the current time) - both with http and https.
Cheers!
Yes, I also wanted to comment on the benchmark article[1], because it seems you looked at compute-bound performance rather than rps (requests per second) on simple data. Given that what you made, MicroDot, is a web server, it would make more sense to stress it rather than MicroPython and the SoC, no? That would seem to be more of the purview of the MicroPython and/or SoC devs.
1 - https://blog.miguelgrinberg.com/post/benchmarking-micropytho...
You got it backwards. If I were to release a benchmark for Microdot, everyone would say that it is biased!
The article you are referring to is intended to benchmark microcontrollers running MicroPython. Nothing to do with Microdot.
I'm not really sure what conclusions you expect to reach if you had a Microdot benchmark that gives you a requests per second number. I would not stop using microcontrollers if the number was low, and I wouldn't start more projects if the number was high. I don't really care. It works for the intended purpose.
I think it would be valuable to decide if the performance is sufficient for a desired purpose. If the performance is insufficient you may need to switch to something written in a compiled language or to a faster platform. That's why the RPS is useful.
This is true for any kind of project, regardless of hardware or software stack. You always need to evaluate the performance for the specific use case you are targeting to make sure it falls in the expected range, and it is your job to do this evaluation as the project owner, because only you know the specifics of your project.
The point I was trying to make in my reply above was that an abstract RPS number, obtained measuring a general purpose web app on a general purpose microcontroller does not mean anything. What matters is your own performance evaluation.
I think there is a fundamental misunderstanding caused by the OP's article. It mischaracterizes your blog post as a performance test of microdot, but as you say, it has nothing to do with it. Still, a baseline, best-case RPS number is a useful number to associate with microdot for various reasons; it cannot, of course, take the place of testing the real application, but what it can do is give implementers and upper-bound on IOPs to a device via HTTP/S. Take that as you will. Microdot is a very cool project, kudos for doing it and sharing it.
You are more than welcome to evaluate Microdot on the specific device you are interested in. It is good to keep in mind that people don't run web apps on microcontrollers because they have good performance. Don't expect any miracles.
I need to measure temperature at multiple points and humidity in my experimental garden shed with a skytherm roof [ http://www.solarmirror.com/fom/fom-serve/cache/30.html ] for passive heating and cooling. Thinking your thermostat code might be 90% of what I need however I don't yet know python. I guess it's easy to understand and modify the code with the help of AI.
Why did you want the server to use Python? It seems simple enough to be easily be done in bare C.
I wanted to use MicroPython for this. I have nothing against C, it is a language that I actually know and use for other projects, but I wanted the challenge to try to build something similar to Flask or FastAPI that could run well on small devices.
Numerous comments on the “impossibly small” bit in the title. It makes me wonder if it was put there as a bit of tongue in cheek, less as a brag. E.g. The “it doesn’t have to be that big” Microdot web framework (which I honestly first thought had something to do with Microdot anti theft devices that they put on cars around me).
Elsewhere on HN right now is a post about a dermatologist vibecoding an app for skin stuff. I view the “need/use ai for coding” as an indictment against how complex software development has become. What I think we marvel at is the surprise that sometimes reall can be just that simple. 99% of the people who are using Django/flask/etc don’t really understand how they work under the hood all that well. And so it’s always an “is that all??” moment when we do these “back to the basics” exposé’s where we show that 80% of our needs are covered by something simple and understandable.
> Elsewhere on HN right now is a post about a dermatologist vibecoding an app for skin stuff. I view the “need/use ai for coding” as an indictment against how complex software development has become.
There's a reason why, in the late 90s and early 2000s, people were able to jump out of non-technical careers into development using languages like ASP and ColdFusion. There were some shortcomings of the stacks of the day, but functionally, the ability to meet many business cases really hasn't changed since those days.
Not to mention Visual Basic.
... and Excel and Access. So much shadow IT got developed because Excel (+VBA, which is almost as powerful as regular VB6, including calls to the native win32 DLL API) is present everywhere, and Access is pretty widespread as well.
> shadow IT
I read somewhere that the number of Excel "programmers" is an order or magnitude larger than all professional programmers in all other languages put together.
Makes you wonder which is the "shadow IT"!
I got my start in professional software development by building an multi-user Access shadow-IT database application that made heavy use of VBA. It only worked because it had a couple of active users at any time, and I left that workplace with documentation consisting of a half-page of bullet points. I know for certain that it was still in usage four years after I left, though God know how long it kept operating in the end.
Notwithstanding that shadow IT is the bane of my existence these days, I sometimes need to be reminded of how far a motivated individual can come when they have access to adequate tools and information.
> Elsewhere on HN right now is a post about a dermatologist vibecoding an app for skin stuff. I view the “need/use ai for coding” as an indictment against how complex software development has become
One other way to look at it is that software is realizing enough of the dreams of reusability that cobbling together scripts at such a high level with only the smallest understanding is finally becoming possible. I'm not going full Pangloss here, development is still a massive clusterfuck in many places and probably always will be by its nature, but the frontiers have pushed waaaaay back since I got started.
Reusability is a big part of it, but I also think languages are just a lot more abstract and expressive these days, so fewer lines of code goes further. Empirically, error count is correlated with lines of code, as are hallucinations, so the ideal language for AI coding is the most abstract and expressive language that will get you there.
> so the ideal language for AI coding is the most abstract and expressive language that will get you there
...JavaScript? (half joking)
All these years later, and I can't get over the fact that Flask began as an April fool's joke, making fun of Bottle and other microframeworks. I guess the joke failed completely.
Joke is Python never made it a front end web language given how easy it was for JS to become a backend and how many of these Python frameworks actually copy off JS, even though Python is older and from a perspective - neater…
This makes no sense. Of course it's easier for a language in a browser to release an executable than a language with an executable to be embedded in a browser. Also, why are we even talking about JS?
Brother Ставри, tell me how exactly does JS run without an executable? Sorry you miss the fact JS’s executable was initially bundled with Netscape WHIcH was the executable.
Your argument makes even less sense. Executable or not, the suitability of the language for certain task is what is/was being discussed here.
I’d argue both Python and JS got where they were thanks to early adoption of Perl’s regex (another language) and the fact they are so symbolic in nature.
And we talk about JS here for apparent reasons - the web. Like we talk python most of the time when we talk ML right so?
there are some efforts to compile python to webassembly so let's see who will have the last laugh!
I keep following closely, but my point is really about the language adoption as such as a choice for web.
But I’ll cut short with predictions here as more downvotes are always a difficult thing to swallow in the morning. .)
WebAssembly in a browser, is still JS.
Not at all.
Webassembly in the browser would be… webassembly.
Not sure what’s going on in this thread, but I see an unusual high number of low quality comments.
Sounds like this framework is comparable in size to the original Rails, which clocked in at under 1000 lines of code (microdot is 765 lines per the article).
I don't know if the original Rails would have run on mruby though (if it had existed at the time), and Rails certainly did a lot of things the author of microdot would have considered "dark magic".
Microdot is apparently a Python web framework that runs on both CPython and MicroPython.
It is a single 765-line file with routing, JSON handling, cookies, streaming, and TLS. Created to provide a web server for IoT devices.
It’s great on esp32 with MicroPython. Even has support for server sent events (SSE). Paired with htmx, SSE gives some fun intetactive web experience for iot devices - instant GPIO status indicators etc. Loved tinkering with it. The source code is very readable too.
https://github.com/miguelgrinberg/microdot with MIT license
The last large app I built in CFML (ColdFusion) was based on FW/1, which is a MVC framework in less than 1800 lines (including comments). No external dependencies, but to be fair, the CFML application server bakes in pretty much every dependency that most applications would ever need.
I'm reminded of an MVC microframework I put together many years back in PHP: https://github.com/Two9A/BirSaat
Having pulled down a copy just now, the framework itself is 526 lines of PHP, and the sample site (a newsfeed that pulls from the BBC) is perhaps 300 lines in models and controllers. I use the framework to this day to serve out my blog and other small sites, seems to work well without getting in the way.
It looks a lot like Bottle[1] but with MicroPython support.
[1] https://bottlepy.org/docs/dev/
https://github.com/miguelgrinberg/microdot
> Migrating to Microdot 2
You gotta be kidding...
Just needs a community split some flame wars and a personal drama where someone give just their side of a story on a blog post.
it's literally there in the linked readme:
Version 2 of Microdot incorporates feedback received from users of earlier releases, and attempts to improve and correct some design decisions that have proven to be problematic.
For this reason most applications built for earlier versions will need to be updated to work correctly with Microdot 2. The Migration Guide describes the backwards incompatible changes that were made.
I would love to try this on my ESP32-C3 Super Mini, the small web framework on the small WiFi-capable microcontroller.
[dead]
I'm not sure there's anything "impossible" about how small this is. You don't really need a lot of lines of code to support routes, request and response and nothing else. If anything, 765 lines of code for this is quite a lot.
It also uses libraries for most "extensions" that are available, defeating the purpose and bending the claim that it's 1,700 lines of code including the extensions. Just jinja, one of the dependencies, is 18,000 lines of code. If that counts my Nanodot server which calls flask.app.run() is one line...
To clarify this, note that the extensions are entirely optional, and unlike what you are saying, most do not require any dependencies.
The only two extensions that use dependencies are the one that adds template rendering, and the one that implements secure user sessions.
For templates, you can use Jinja on CPython (where you wouldn't normally have space issues), or the uTemplate library (https://github.com/pfalcon/utemplate) on MicroPython, which is quite small.
For secure sessions, on CPython you have to add PyJWT. On MicroPython you need to add the HMAC and JWT modules from the MicroPython standard library, which are not installed by default. These are also very small.
Yeah, it's an over exaggeration to say "impossibly small", it's a pretty normal size for a minimal routing class...
> I'm not sure there's anything "impossible" about how small this is. You don't really need a lot of lines of code to support routes, request and response and nothing else. If anything, 765 lines of code for this is quite a lot.
How do you explain why virtually all frameworks end up requiring an order of magnitude more LoC?
Because they support a lot more features?
I made a similar "framework" in PHP years back as an experiment and it was a couple hundred lines AT MOST.
> Because they support a lot more features?
Not necessarily. For example, some minimal web frameworks actually provide multiple routing strategies because different implementation strategy have tradeoffs.
Not meaning to be pedantic, but supporting multiple routing strategies is textbook ”more features”.
Are they, though? I mean, is it a feature to make something usable? If you have hard performance constraints and you know what routes you need to suppport, a generic but prohibitively expensive routing strategy can prevent you from using the framework.
> I mean, is it a feature to make something usable?
In your own example, having multiple ways of declaring routing is not required to be considered usable.
So, yes.