July 12th, 2024

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

Mesop, a Python UI framework for AI apps, now supports Web Components. This allows fine UI control, JS library use without complex toolchains, and aims to reduce front-end fatigue. Mesop plans to enhance support with React integration and open-source components.

Read original articleLink Icon
Is Mesop and Web Components the cure to Front-end fatigue?

Mesop, a Python UI framework focused on building AI apps, has introduced experimental support for Web Components. This integration aims to provide developers with fine-grained UI control and the ability to utilize existing JS libraries without the need for complex build toolchains. By leveraging web standards supported by modern browsers, Mesop aims to minimize front-end fatigue caused by the constant churn in the front-end ecosystem. The framework prioritizes simplicity and rapid prototyping, allowing developers to create custom components with minimal front-end knowledge. Moving forward, Mesop plans to enhance its web component support by providing guides for integrating React components and fostering an ecosystem of open-source Mesop web components. While the effectiveness of Mesop and Web Components in alleviating front-end fatigue is yet to be fully determined, they offer a promising alternative to traditional front-end development complexities.

Related

Google no longer developing Material Web Components

Google no longer developing Material Web Components

Material Web is a library of web components based on Material 3 for creating attractive and accessible web apps. Components are in maintenance mode, seeking new maintainers. Visit the Material Web GitHub for details.

Google no longer developing Material Web Components

Google no longer developing Material Web Components

Google has ceased active development of Material Web Components (MWC) and shifted focus to its internal Wiz framework. MWC is now in maintenance mode, with engineers reassigned. Angular Material remains available.

New Web Development: Or, why Copilots and chatbots are bad for modern web dev

New Web Development: Or, why Copilots and chatbots are bad for modern web dev

The analysis critiques Copilots, chatbots, and React for web development, citing slow sites, complex code, and high costs. It advocates for a shift to browser APIs, CSS, and HTML for better performance and lower expenses. Transition challenges include finding developers skilled in vanilla JavaScript. Organizations are urged to prioritize simplicity, efficiency, and core web technology training.

HTML-ivating your Django web app with Htmx, AlpineJS, and streaming HTML

HTML-ivating your Django web app with Htmx, AlpineJS, and streaming HTML

The video discusses concerns over the prevalence of single page applications online, promoting traditional server-based websites. It recommends Django over React, demonstrating fast website creation and speed optimization techniques.

Show HN: A JavaScript UI library for imperative JSX

Show HN: A JavaScript UI library for imperative JSX

The @matry/dom npm package introduces a web framework for imperative JSX, aiming to enhance UI engineering by offering a more imperative approach compared to React. It provides control over rendering and flexibility in UI design. Developers are cautioned against using it in production before version 1.0.0.

Link Icon 8 comments
By @Etheryte - 3 months
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.
By @willchen - 3 months
We posted on Show HN 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 - 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!

By @gavmor - 3 months
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!

By @metalrain - 3 months
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.
By @not_your_mentat - 3 months
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.
By @rapind - 3 months
The end of my frontend fatigue was to get away from Javascript and it's doctrine of churn.