4 ms·

Is Mesop and Web Components the cure to Front-end fatigue?

12 points by willchen 2y ago

willchen 2y ago
We posted on Show HN https://news.ycombinator.com/item?id=40567327 https://news.ycombinator.com/item?id=40567327 ~a month ago and got a ton of great feedback. Since then, we've made a lot of updates to Mesop, including adding support for web components which allows you to write custom JS and wrap existing JS libraries. We've also fully re-designed our home page at https://google.github.io/mesop https://google.github.io/mesop - with many more code examples and demo, which hopefully shows how Mesop is different than some of the other Python UI frameworks out there. As always, appreciate any feedback about the project. Thanks!
- deleted 2y ago
  [deleted]
- ofrzeta 2y ago
  You've also pivoted a bit into AI? :) Personally I find that unfortunate because that's not what you actually do (even though many people at Google might use the framework for this) and it's distracting.
metalrain 2y ago
Fatigue problem isn't solved by having more technology, it's about human condition. There is always push/pull between doing new things vs keeping things same.
Etheryte 2y ago
Web components are a nice idea if you squint hard enough, but architecturally they're inadequate for solving the problems modern frameworks and libraries address — that's why you see them used nearly nowhere. I think needless to say that the answer to tooling fatigue is not more new tooling. As someone who's spent way more time working on frontend applications, libraries and tooling than is good for anyone's hairline, I would say the main thing we really need is time. There is clearly a best practices converging across the tooling landscape, best ways to solve common problems etc, but we're not quite there yet. But I can see it in the distance if I squint.
- willchen 2y ago
  Any particular parts that you feel are inadequate with web components? Web components aren't a panacea but they have definitely come a long way in the past decade.
- jauntywundrkind 2y ago
  > but architecturally they're inadequate for solving the problems modern frameworks and libraries address Such as? Do you think these are inherent limitation? Is it possible to get to an "adequate" place with webcomponents alone? Or with web component based frameworks or libraries? > that's why you see them used nearly nowhere Little companies you have have heard of using webcomponents extensively: YouTube, many Google properties, GitHub. Personally I'm hella sad that this industry doesn't make new js frameworks like they used to. It now takes a Microsoft or a Facebook's name recognition for people to pay attention. And where-as before many people tried, devs in the React age see themselves not as capable web makers, but as downstream React craftsmen; we don't recognize in ourselves that we create & shape our development experience, are less trying to find what works for us & more trying to adopt & use existing tools. I feel similar but different in this summation: > the main thing we really need is time. There is clearly a best practices converging across the tooling landscape, best ways to solve common problems We lack the range of experience. Time yes, but more so, there aren't visible enough pokers in the fire. And a lack of a strong blogging culture where every effort gets chatted up & considered by the broader mind. We don't really know what limitations or downsides there are; most folks haven't tried or seen many other tries. (Shout out to niw-inactive Catalyst web component library, which I hope some day comes back. The action / target system rocks, very similar to CommamdFor/InvikerAction work that's been chunking along. https://github.com/github/catalyst https://github.com/github/catalyst https://github.com/whatwg/html/issues/9625#issuecomment-2115718679 https://github.com/whatwg/html/issues/9625#issuecomment-2115... )
rapind 2y ago
The end of my frontend fatigue was to get away from Javascript and it's doctrine of churn.
deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
gavmor 2y ago
Lit and web components are cool, but "front-end fatigue" is no more real than "Python fatigue," since every technology has drawbacks. Yes, I have forgotten the pain of "bundling," as vite, Typescript, and bun are lightyears past grunt, gulp, and webpack. These days, to play with GPU-enabled toys, I am more often struggling with venv and [mini|ana]conda. The long and short of it is that DX continues to evolve across ecosystems. Mesop's API is... interesting. It seems to replace all REST/CRUD/MVC abstractions with some kind of RPC, which is a perfectly valid way to structure a program. Certainly it saves Python devs from having to learn that corner of the web domain and its pattern language which, hey, may be pasé? Especially in a world of notebooks? I can imagine this will open up fruitful partnerships with Web Component developers and also give Python devs an entry point into web UI paradigms, so it's certainly a positive for eg GenAI R&D. That phrase "front-end fatigue" is just sticking in my craw. Where do Python devs get off complaining of "fatigue" over one layer of the stack or another? Data migrations can be just as tricky. God knows infra tooling is more tedious than anything re: node_modules. Must be some kind of selecting bias. Who is understaffing all these Python shops? Is it academia? Are even private AI R&D departments wary of over-investing in ephemeral interfaces? For testing, at least, I suppose they are. Maybe this is related to the reasons why game devs split art and mechanics for as long as possible. But at the same time, I can't help but feel we're letting Bret Victor down in some way. Anyway, while I can easily see Mesop elevating demo day, I struggle to believe it will facilitate agile product development which, hey, might not be where the money is at, these days!
- willchen 2y ago
  Thanks, yeah describing Mesop API as essentially a UI over RPC is a good analogy and is basically what's happening under the hood [1]. I guess one funny thing is that I actually identify as a FE developer more than a Python developer :) I've been doing FE for much longer than Python and agree that there's warts on both sides (and no language/ecosystem is perfect). For me, a lot of the FE fatigue comes from all the inherent challenges with developing client-side applications (e.g. the necessity of bundling/minifying for optimizing performance, transpiling for legacy browsers) so I don't say this to throw stones at the other side but simply to point out my own fatigue having dealt with this complexity for years. Right now Mesop is definitely more focused on the demo use cases, but we're also trying to push the limits of the kinds of apps you can build in Python so it doesn't have to be something you throwaway when you want to deploy a scalable app. [1] https://google.github.io/mesop/internal/architecture/#life-of-a-mesop-request https://google.github.io/mesop/internal/architecture/#life-o...
not_your_mentat 2y ago
I'm not too keen on another Google dependency. You gentlefolk have a tendency toward customer screwery and killing the things I rely on. It simplifies Google products right out of my decision making.

12 points by willchen 2y ago

We posted on Show HN https://news.ycombinator.com/item?id=40567327 https://news.ycombinator.com/item?id=40567327 ~a month ago and got a ton of great feedback. Since then, we've made a lot of updates to Mesop, including adding support for web components which allows you to write custom JS and wrap existing JS libraries. We've also fully re-designed our home page at https://google.github.io/mesop https://google.github.io/mesop - with many more code examples and demo, which hopefully shows how Mesop is different than some of the other Python UI frameworks out there. As always, appreciate any feedback about the project. Thanks!

deleted 2y ago
[deleted]
ofrzeta 2y ago
You've also pivoted a bit into AI? :) Personally I find that unfortunate because that's not what you actually do (even though many people at Google might use the framework for this) and it's distracting.

metalrain 2y ago

Fatigue problem isn't solved by having more technology, it's about human condition. There is always push/pull between doing new things vs keeping things same.

Etheryte 2y ago

Web components are a nice idea if you squint hard enough, but architecturally they're inadequate for solving the problems modern frameworks and libraries address — that's why you see them used nearly nowhere. I think needless to say that the answer to tooling fatigue is not more new tooling. As someone who's spent way more time working on frontend applications, libraries and tooling than is good for anyone's hairline, I would say the main thing we really need is time. There is clearly a best practices converging across the tooling landscape, best ways to solve common problems etc, but we're not quite there yet. But I can see it in the distance if I squint.

willchen 2y ago
Any particular parts that you feel are inadequate with web components? Web components aren't a panacea but they have definitely come a long way in the past decade.
jauntywundrkind 2y ago
> but architecturally they're inadequate for solving the problems modern frameworks and libraries address Such as? Do you think these are inherent limitation? Is it possible to get to an "adequate" place with webcomponents alone? Or with web component based frameworks or libraries? > that's why you see them used nearly nowhere Little companies you have have heard of using webcomponents extensively: YouTube, many Google properties, GitHub. Personally I'm hella sad that this industry doesn't make new js frameworks like they used to. It now takes a Microsoft or a Facebook's name recognition for people to pay attention. And where-as before many people tried, devs in the React age see themselves not as capable web makers, but as downstream React craftsmen; we don't recognize in ourselves that we create & shape our development experience, are less trying to find what works for us & more trying to adopt & use existing tools. I feel similar but different in this summation: > the main thing we really need is time. There is clearly a best practices converging across the tooling landscape, best ways to solve common problems We lack the range of experience. Time yes, but more so, there aren't visible enough pokers in the fire. And a lack of a strong blogging culture where every effort gets chatted up & considered by the broader mind. We don't really know what limitations or downsides there are; most folks haven't tried or seen many other tries. (Shout out to niw-inactive Catalyst web component library, which I hope some day comes back. The action / target system rocks, very similar to CommamdFor/InvikerAction work that's been chunking along. https://github.com/github/catalyst https://github.com/github/catalyst https://github.com/whatwg/html/issues/9625#issuecomment-2115718679 https://github.com/whatwg/html/issues/9625#issuecomment-2115... )

rapind 2y ago

The end of my frontend fatigue was to get away from Javascript and it's doctrine of churn.

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

gavmor 2y ago

Lit and web components are cool, but "front-end fatigue" is no more real than "Python fatigue," since every technology has drawbacks. Yes, I have forgotten the pain of "bundling," as vite, Typescript, and bun are lightyears past grunt, gulp, and webpack. These days, to play with GPU-enabled toys, I am more often struggling with venv and [mini|ana]conda. The long and short of it is that DX continues to evolve across ecosystems. Mesop's API is... interesting. It seems to replace all REST/CRUD/MVC abstractions with some kind of RPC, which is a perfectly valid way to structure a program. Certainly it saves Python devs from having to learn that corner of the web domain and its pattern language which, hey, may be pasé? Especially in a world of notebooks? I can imagine this will open up fruitful partnerships with Web Component developers and also give Python devs an entry point into web UI paradigms, so it's certainly a positive for eg GenAI R&D. That phrase "front-end fatigue" is just sticking in my craw. Where do Python devs get off complaining of "fatigue" over one layer of the stack or another? Data migrations can be just as tricky. God knows infra tooling is more tedious than anything re: node_modules. Must be some kind of selecting bias. Who is understaffing all these Python shops? Is it academia? Are even private AI R&D departments wary of over-investing in ephemeral interfaces? For testing, at least, I suppose they are. Maybe this is related to the reasons why game devs split art and mechanics for as long as possible. But at the same time, I can't help but feel we're letting Bret Victor down in some way. Anyway, while I can easily see Mesop elevating demo day, I struggle to believe it will facilitate agile product development which, hey, might not be where the money is at, these days!

willchen 2y ago
Thanks, yeah describing Mesop API as essentially a UI over RPC is a good analogy and is basically what's happening under the hood [1]. I guess one funny thing is that I actually identify as a FE developer more than a Python developer :) I've been doing FE for much longer than Python and agree that there's warts on both sides (and no language/ecosystem is perfect). For me, a lot of the FE fatigue comes from all the inherent challenges with developing client-side applications (e.g. the necessity of bundling/minifying for optimizing performance, transpiling for legacy browsers) so I don't say this to throw stones at the other side but simply to point out my own fatigue having dealt with this complexity for years. Right now Mesop is definitely more focused on the demo use cases, but we're also trying to push the limits of the kinds of apps you can build in Python so it doesn't have to be something you throwaway when you want to deploy a scalable app. [1] https://google.github.io/mesop/internal/architecture/#life-of-a-mesop-request https://google.github.io/mesop/internal/architecture/#life-o...

not_your_mentat 2y ago

I'm not too keen on another Google dependency. You gentlefolk have a tendency toward customer screwery and killing the things I rely on. It simplifies Google products right out of my decision making.