I have a suggestion: why not create a feature request that is specific to this new ‘website view’ that you have in mind, and let other community members pitch in with comments/ideas.
Plus, create feature requests where you see opportunities for improvement with existing Fibery views.
I think a generic topic like ‘Frontend is essential!’ is inevitably going to mean many different things to different people, so we will end up talking at crossed purposes.
This conflict with all fibery public statements…and even if that true, internal tasks need frontend 
Ill do that once the concept fully developed for me…
But this whole post explaining why fibery team need to think of frontend strategicly especially there is many suggestion about all fibery frontend components and the plan to build mobile / home page / website redesign … all these relate to lack of stratigic frontend plan.
May i ask a question? Why do fibery team decided to provide some information in the main site as fibery workspace (ie api, public roadmap, etc), and some as website (ie. Blog post, home page, etc)??
Yes, internal tasks need a ‘frontend’. That’s why we have tables, boards, lists, timelines, maps, feeds, documents, whiteboards, etc.
But they are views intended primarily to support processes involving ‘internal users’ e.g. I need a kanban of tasks, I need a timeline of my projects, I need a table of assets, I need an internal wiki, etc.
They do not support very well the processes where external users are involved, e.g. a public facing website, a customer support chat function, a blog, a marketplace, an email marketing platform, etc. It’s not what the Fibery views are designed for.
The information shown in the roadmap is based on data that is stored in our own internal Fibery workspace - we are exposing information that already exists by virtue of the development work we do. It made sense to share a space, rather than use a separate tool for our public roadmap (even though there are tools that exist for that purpose).
The user guide / api docs were previously hosted in dedicated tools/sites but we moved them to an internal space so that it was easy for many people to make improvements/corrections whilst staying in the tool they already spend most of their time in (= the Fibery workspace).
The public Fibery site indeed shows that Fibery is bad at serving as a CMS/website tool, but we live with the drawbacks for the benefits that exist from doing so.
If someone is not already using Fibery, then I wouldn’t recommend it as a tool for public facing sites.
If that is how our public-facing material comes across, then we are not doing a good job with our marketing 
Please show us where we are leading people astray 
Fibery does aim to replace many tools (spreadsheets, documents, task managers, CRM etc.) but it can never be the one tool that will replace everything, and we are not currently focussing on the use cases that you indicated were important to you.
It’s not to say it won’t happen
I know WordPress is old tech at this point, but would an official Fibery integration/plugin resolve this “lack of front-end” problem? Not that it’s really a problem, more an annoyance to the users in this thread
see while we are open this health discussion … softr started their backend.
that’s same approach is seeing from most of those ALL-IN-ONE tool they either start from frontend and then backend or from backend to the frontend … this whole discussion is needed for fibery near future!! and i hope fibery think of this strategically …
