The irony of Weweb components: they CAN'T be edited with their Editor - WHY?

[thijs]

Hi all - let me share something about the big elephant in the room AND a suggestion to make it better:

Weweb’s core product is it’s Editor… so the more confusing I find the components Weweb provides:

Weweb’s ready-to-go components might help you to get started quickly - but they’re (near) impossible to modify with the Editor. Every time you use a component, you CAN’T LEARN from it, you CAN’T PROPERLY MODIFY it - so you’re stuck with boiler plate (oh and perhaps AI will do the magic, again bypassing the basic elements within the Editor). This approach doesn’t help the user - and leaves him/her guessing how to create it with the basic elements in the Weweb Editor.. how ironic is this?

It’s almost like Weweb doesn’t believe in it’s own Editor - by choosing the route of making components with custom Javascript (and pointing to AI to further customize it).

Also - I just watched one of Weweb’s showcase video’s, and again the irony: the Weweb interviewer complimented the user on slick design, and the answer he got: YES, I HAVE THE ENTREPENEUR PLAN, SO WEWEB TEAM MADE IT CUSTOM FOR ME - WTF?!

SUGGESTION to Weweb:

What I recently did was create my own calender, with FEW BASIC divs/text/icon-elements (and the default ‘Date’ plugin for formulas) and few actions to make it fully functional. Nothing special, but the more I was able to make it look slick/integrated with the overall custom design of my webapp.

So honestly I would expect Weweb’s components to be similarly created as my calendar - which would ALLOW THE USER TO FULLY CUSTOMIZE WITH THE WEWEB EDITOR.

Please help me understand: WHY doens’t Weweb provide components in this elementary way to prove the value of its Editor??

[Broberto]

You can fork WeWeb’s components and edit them either with AI or by hand (code)

[Joyce]

Hi @thijs

I’m not sure I understand.

The idea is that we try to provide native elements that do a great job out of the box for 80% of use cases and styling requirements but give builders the flexibility they need to add features that will cover the remaining 20% use cases/styling requirements.

That way, we can avoid overloading the Editor with rarely used settings and options and keep things fairly intuitive (though we have a lot of work to do to improve intuitiveness in some cases!)

So with the Calendar example, there are kind of 3 edition options:

1. You drag and drop the Calendar element on the page and edit it inside the WeWeb editor based on the style properties and settings that are available natively. Should cover 80% of use cases though I would say our Calendar element is probably one of the native elements that needs the most love from us at the moment!

2. If the native style options and settings you need are too limited for you but you have limited coding knowledge, you can select the element and then prompt WeWeb AI to add the style options or settings you want so that, for future stying editions, you can continue to edit via no-code in the editor.

3. If the native style options and settings you need are too limited for you and you have coding knowledge, you can fork our native components and tweak the code (including adding no-code props) directly inside the WeWeb editor like @Broberto suggested.

Does that make sense?

[thijs]

@Joyce

ative style options and settings you need are too limited for you and you have coding knowledge, you c

Hi @Joyce ,

Thanks for your response - I understand what you’re saying, but that is also my point:

I built the example calendar with the reason to have (a simple start of) a full screen calendar with lots of details (dynamic lists) and functionalities. And unlike Weweb’s components, I built this from scratch with Weweb’s basic elements (div / text field / icon) to have sight and control of every detail within the Editor itself (without having to rely on AI or coding experience). To my disappointment, building this from scratch is the only way I see fit to have full control over its design and functionalities.

Reason for this post: at first sight, the Weweb calendar component seems like a good start for my project, but again I see it’s this custom thing wrapped in one line in the tree-view of the Editor that can only be changed with AI or coding experience.
In all reasonableness, I can’t take this as a starting position for my project. So for me the only feasible way to evolve my little calendar into the full fletched calendar I’m looking for. I think Weweb has a great chance to shine here, but is missing the point.

And if I can built such a simple calendar with basic components, why would Weweb not (want to) provide such simple -and timeless- components (that can help save the time to think through how to make it)? My experience is that the vast majority of components can be made with the most basic elements (such as div/textfield/actions).

If Weweb would provide such components in a way that it can be fully specified (in tree-view) by the Editor, than its users can learn from its structure/design/logics - and really use it as a basis to further work on.

In my opinion, Weweb Editor should be suitable to present the full structure of its components and facilitate manually editing of these components. I think most developers/creators that care about the finishing touch of their webapp will run into the limitation of current components.

I understand the current situation with the reasoning of catering to the 80%. But perhaps the remaining 20% are your long-term users/supporters - that look for full customization (without reliance on AI or coding). So far, Weweb Editor has helped me to create some great things - and still I don’t know how to code.. that’s impressive.

Also, I would understand if the Editor has limitations to what it can to in regards of producing performant components from its basic elements. By asking my question I expected that performance might have been a point of consideration (but so far, I haven’t heared that to be the case).

[Joyce]

@thijs

And if I can built such a simple calendar with basic components, why would Weweb not (want to) provide such simple -and timeless- components (that can help save the time to think through how to make it)? My experience is that the vast majority of components can be made with the most basic elements (such as div/textfield/actions).

If Weweb would provide such components in a way that it can be fully specified (in tree-view) by the Editor, than its users can learn from its structure/design/logics - and really use it as a basis to further work on.

Aaaah ok, got it!

Yeah, it’s something the product team explored quite a lot but I can’t remember all the reasoning for how we arrived at the current elements.

@thijs

By asking my question I expected that performance might have been a point of consideration (but so far, I haven’t heared that to be the case).

Hehe, yeah, the performance of the element in the published app is definitely one of the considerations (I’m guessing performance in the editor as well). I thought about mentioning it in my previous answer but I don’t have the technical knowledge to explain exactly how our approach improves performances.

What I do know is that, for the Datagrid for example, it required a lot of iteration on our side to make it handle thousands of lines seamlessly and I don’t think it would have been possible to do that while exposing the elements that make up the Datagrid itself.

In any case, really fair point! I’ll pass it on to the product team. It could be interesting to see how template builders like Karl and JP approached this in the marketplace, what obstacles they faced, and what we could learn from them.

.

[thijs]

Thanks @Joyce , I’m looking forward to the outcome