5 ms·

First, I welcome any project that enriches a software ecosystem, and this project no doubt does just that. However, I have two points which will deter me from u

by harel 2y ago

First, I welcome any project that enriches a software ecosystem, and this project no doubt does just that. However, I have two points which will deter me from using this (or any python->html/js framework) in a commercial production project: 1. It silos front end development in Python world. It might be great if your entire team are and always will be Python devs, but what happens when you want dedicated from end developers? What happens when you need to deviate out of what the framework gives you in a front-end context? What happens when you need to eject from "python" into a dedicated front end environment? All your front end code is now written in Python. Worst, you now might even have JavaScript code embedded inside Python code. I keep hearing "CoffeeScript" in the back of my mind... 2. Any python project using FastAPI (which is fantastic), flask, etc. and is growing in scope, will ultimately build Django. For example, FastAPI (which is great), has SqlModel (which is awesome) which makes SqlAlchemy less sucky and more like Django. Start to factor in all the other batteries we got used to getting with Django, and it starts adding up. If the project is smallish in scope and well defined to know it will stay such, sure it's a valid and excellent choice. The same applies here - unless batteries are included, or this is (as suggested in a comment) available as a Django app, you'll end up building Django.

jph00 2y ago
Regarding (1), I think you might be misunderstanding how FastHTML works. If you want to write JS code in FastHTML, then you can just do that. But you can focus entirely on using it for the bits it works well for. For instance, I wrote a little app (https://word2md.answer.ai/ https://word2md.answer.ai/ ) which lets you copy/paste from MS word, and converts it to Markdown. I found that there's some nice existing JS code for cleaning up MS Word markup, so I used that on the client side, and used server-side python code for converting that to markdown. Here's the Python code, which is just plain python in a regular python file: https://github.com/AnswerDotAI/word2md/blob/main/main.py https://github.com/AnswerDotAI/word2md/blob/main/main.py And here the JS code, which is just plain JS in a regular JS file: https://github.com/AnswerDotAI/word2md/blob/main/wordpaste.js https://github.com/AnswerDotAI/word2md/blob/main/wordpaste.j... Regarding (2), I've heard the same basic argument nearly every time I've tried to create anything new, and I've heard it apply to lots of other people's projects too. Yes, if there's an existing product that's pretty good already, then it's likely the new thing won't be as good in every way. I don't think that's a reason to not try to make something better, however. I like Django a lot, have used it since its very early days, and I'm friends with one of the founders of it -- it's an amazing project. But it's not perfect, and hopefully it's OK if some people want to try different things too.
- harel 2y ago
  Regarding 2, I completely agree. A good existing project is no argument against new projects in the same space. It was more an observation (and very current experience of me reworking a fastapi project to Django+ninja because it simply grew in scope enough to merit it). Regarding 1, I get it, although I do like my ends to be separate. Maybe it's a question of aesthetics and therefore completely subjective.
mixmastamyk 2y ago
1. These folks on such a project will otherwise need to deal with templates with Python in them. Inside out or outside in, there’s some complexity. Linted, formatted, optionally typed Python is likely going to be more maintainable than html templates in the long run and is one of the easier langs to pick up. css/js can be linked separately. I don’t see any limitations that would prevent one from using a template on a new page. I recently looked into these kind of html builder libs, pioneered by dominate. “htpy” was the only one where I was impressed with the source code.
- harel 2y ago
  I just don't see how a project beyond a small website can benefit from having it's front end generated in such a way. Once you grow beyond the "website" with simple interaction your front end becomes it's own universe. Coupling it all in the back end never ends well despite all good intentions. That has been my personal experience so far, so mileage varies etc. As an aside, HTML is formatted in a very visual way in my opinion. The tag syntax makes it clear to visually identify blocks and layout elements. You lose this when you describe the layout in Python.
  - pelme 2y ago
    In our company, where htpy was born, we are building a highly interactive application with htpy combined with Alpine.js+htmx. We have a couple of thousands lines of htpy code in production right now. We stick all HTML generation code into components/x.py or components.py files to keep it separate from other code. It is easy to grasp the structure. We use type hints so it is clear what data different components expect. "Goto defintion" just works so it is easy to navigate the code. I agree about that HTML looks better with tags and it takes a bit of getting used to the python syntax. If something like JSX was possible in Python with all the tooling working, that would be great.
  - idf00 2y ago
    > Once you grow beyond the "website" with simple interaction your front end becomes it's own universe I think this has been a major failing/pain point of web-dev that this MUST be the case. However, I think fastHTML for me is going to fix that. Naturally there is no approach that is ideal in every case, but for a ton of them fastHTML I think works. I've built several things with fastHTML and am very optimistic. As far as the visual identification, I think python is just as clear to see visual blocks as HTML, but comes with many additional refactoring options (that you can choose when it makes sense to use for your use-case). Try playing with https://h2x.answer.ai/ https://h2x.answer.ai/ and putting in some HTML code and see how it looks in python. Maybe you'll disagree, but I find it quite refreshing.
nprateem 2y ago
That's always the problem with these things. You can no longer leverage the bigger ecosystem (e.g. just copy HTML templates from libraries), and I can probably count on no fingers the number of decent designers I've met who knew python. So as soon as you want to grow your team you'll end up with a split. Still, for projects that are only likely to stay small it might be fun. But then you'll have to remember how it works after coming back from your day job that uses a more mainstream framework.
- dvngnt_ 2y ago
  > decent designers I've met who knew python i don't know many designers who can program at all? is it really needed?
- yawaramin 2y ago
  > You can no longer leverage the bigger ecosystem (e.g. just copy HTML templates from libraries You can definitely do this with FastHTML: https://h2x.answer.ai/ https://h2x.answer.ai/
deleted 2y ago
[deleted]

by harel 2y ago

jph00 2y ago

Regarding (1), I think you might be misunderstanding how FastHTML works. If you want to write JS code in FastHTML, then you can just do that. But you can focus entirely on using it for the bits it works well for. For instance, I wrote a little app (https://word2md.answer.ai/ https://word2md.answer.ai/ ) which lets you copy/paste from MS word, and converts it to Markdown. I found that there's some nice existing JS code for cleaning up MS Word markup, so I used that on the client side, and used server-side python code for converting that to markdown. Here's the Python code, which is just plain python in a regular python file: https://github.com/AnswerDotAI/word2md/blob/main/main.py https://github.com/AnswerDotAI/word2md/blob/main/main.py And here the JS code, which is just plain JS in a regular JS file: https://github.com/AnswerDotAI/word2md/blob/main/wordpaste.js https://github.com/AnswerDotAI/word2md/blob/main/wordpaste.j... Regarding (2), I've heard the same basic argument nearly every time I've tried to create anything new, and I've heard it apply to lots of other people's projects too. Yes, if there's an existing product that's pretty good already, then it's likely the new thing won't be as good in every way. I don't think that's a reason to not try to make something better, however. I like Django a lot, have used it since its very early days, and I'm friends with one of the founders of it -- it's an amazing project. But it's not perfect, and hopefully it's OK if some people want to try different things too.

harel 2y ago
Regarding 2, I completely agree. A good existing project is no argument against new projects in the same space. It was more an observation (and very current experience of me reworking a fastapi project to Django+ninja because it simply grew in scope enough to merit it). Regarding 1, I get it, although I do like my ends to be separate. Maybe it's a question of aesthetics and therefore completely subjective.

mixmastamyk 2y ago

1. These folks on such a project will otherwise need to deal with templates with Python in them. Inside out or outside in, there’s some complexity. Linted, formatted, optionally typed Python is likely going to be more maintainable than html templates in the long run and is one of the easier langs to pick up. css/js can be linked separately. I don’t see any limitations that would prevent one from using a template on a new page. I recently looked into these kind of html builder libs, pioneered by dominate. “htpy” was the only one where I was impressed with the source code.

harel 2y ago
I just don't see how a project beyond a small website can benefit from having it's front end generated in such a way. Once you grow beyond the "website" with simple interaction your front end becomes it's own universe. Coupling it all in the back end never ends well despite all good intentions. That has been my personal experience so far, so mileage varies etc. As an aside, HTML is formatted in a very visual way in my opinion. The tag syntax makes it clear to visually identify blocks and layout elements. You lose this when you describe the layout in Python.
- pelme 2y ago
  In our company, where htpy was born, we are building a highly interactive application with htpy combined with Alpine.js+htmx. We have a couple of thousands lines of htpy code in production right now. We stick all HTML generation code into components/x.py or components.py files to keep it separate from other code. It is easy to grasp the structure. We use type hints so it is clear what data different components expect. "Goto defintion" just works so it is easy to navigate the code. I agree about that HTML looks better with tags and it takes a bit of getting used to the python syntax. If something like JSX was possible in Python with all the tooling working, that would be great.
- idf00 2y ago
  > Once you grow beyond the "website" with simple interaction your front end becomes it's own universe I think this has been a major failing/pain point of web-dev that this MUST be the case. However, I think fastHTML for me is going to fix that. Naturally there is no approach that is ideal in every case, but for a ton of them fastHTML I think works. I've built several things with fastHTML and am very optimistic. As far as the visual identification, I think python is just as clear to see visual blocks as HTML, but comes with many additional refactoring options (that you can choose when it makes sense to use for your use-case). Try playing with https://h2x.answer.ai/ https://h2x.answer.ai/ and putting in some HTML code and see how it looks in python. Maybe you'll disagree, but I find it quite refreshing.

nprateem 2y ago

That's always the problem with these things. You can no longer leverage the bigger ecosystem (e.g. just copy HTML templates from libraries), and I can probably count on no fingers the number of decent designers I've met who knew python. So as soon as you want to grow your team you'll end up with a split. Still, for projects that are only likely to stay small it might be fun. But then you'll have to remember how it works after coming back from your day job that uses a more mainstream framework.

dvngnt_ 2y ago
> decent designers I've met who knew python i don't know many designers who can program at all? is it really needed?
yawaramin 2y ago
> You can no longer leverage the bigger ecosystem (e.g. just copy HTML templates from libraries You can definitely do this with FastHTML: https://h2x.answer.ai/ https://h2x.answer.ai/

deleted 2y ago

[deleted]