Hi All,
For the past few months we have been working hard on the upcoming Wappler 8, which we call Wappler Next internally.
Wappler 8 is still in development and isn't available to try yet. We hope to launch the beta soon so you can try it for yourselves. In the meantime, I am sharing these development previews so you can see our progress and help shape the details.
Today I want to start sharing what we have been building. There is a lot I am excited to show you, and I think the best place to begin is with something you will see every time you open a project: the new Activity Workspaces.
Your first look at Wappler 8: Update selected in the Application Map, its API connections in view, and related work open in the editor tabs.
Built with this community
Before getting into the screenshots, I want to say thank you.
So much of Wappler has grown out of the conversations we have here. You share the projects you are building, tell us where something gets in your way, suggest improvements and help each other find solutions. That gives us a very practical understanding of what matters when you are working on a real application.
Our Wappler Ambassadors ( @wappler_ambassadors ) are a big part of that too. Their experience, involvement and continued feedback mean a great deal to us. Having a community this passionate about the product is something I never want to take for granted.
We have put months of work into Wappler 8, and the experience you have shared with us over the years is very much part of the thinking behind it. I am proud of how it is coming together, and it feels good to finally start showing it to you!
Rebuilding Wappler from the ground up
There is a great deal of work behind these screenshots. We are rebuilding the Wappler desktop application from the ground up, using modern technologies and a new architecture that gives us a much stronger foundation for the future.
That means rethinking how the interface is built, how projects are understood, how information is shared between the tools and how background work is handled. It is a major investment for our team, and one I am very excited about. We can bring everything we have learned from years of building Wappler with you into this new foundation.
Technologies such as Electron, TypeScript and Lit are part of that work. What matters most to me is what they allow us to deliver: an application that feels responsive, consistent and comfortable to work in, with room to keep growing.
Our own UI framework, built around Wappler
We have created a new shared UI framework for Wappler's workspaces and editors. Panels, trees, libraries, property controls, tabs and toolbars all belong to the same system.
This gives us a common foundation for usability and accessibility. Keyboard navigation, focus behavior, readable controls and the way panels respond as you work can be addressed in the shared components and carried across the application.
It also means that improving a property control or a navigation pattern can benefit several workspaces together. For you, the aim is a familiar experience as you move from editing a page to working on a server action or configuring your project.
Project intelligence working in the background
Another important part of the rewrite is the project intelligence behind the interface.
We have been building background indexing services that read the project's source and bring related information together. Pages, routes, layouts and server actions have connections that are easy to lose track of when you look at each file separately. The Application Map is one visible way of bringing those connections into view.
The same underlying information can support navigation and contextual editing tools, so different parts of Wappler can work from a shared understanding of the project. Much of that work happens behind the scenes. You see its value when the relevant information is there where you need it.
Performance measured throughout development
Performance has been a major focus throughout this work. We are continuously benchmarking startup, project switching, indexing and editor interactions as we develop. Those measurements help us find unnecessary work and catch regressions while the new application is taking shape.
We have designed startup so the Wappler interface can appear while project services continue preparing in the background. I want opening Wappler to take you straight into the interface, without sitting through a preloader before you can begin. We are putting the same care into making project switching feel immediate and bringing back the editors and working context that belong to each project.
There is also a lot happening around extensions and project preparation. Relevant extension definitions are loaded on demand, and the extensions, project files and dependencies needed for a workflow can be prepared as they are needed. That helps us keep the initial experience focused while still making the right tools available for the project you are working on.
Clear progress while work continues
Background work should still be understandable. We have been building a notification center and progress toasts so you can follow tasks such as project preparation, dependency installation and runtime operations without losing your place in the editor.
A toast gives you a quick update, while the notification center gives you a place to return to the activity and its details. This connects with Monitor, where services, logs and terminals have their own workspace.
These are just some of the developments underneath the new interface. There is much more I want to share, but I wanted you to see how much care is going into the foundation as well as the visible workspaces. It is what makes this next chapter of Wappler so exciting for me.
A workspace for what you are doing
Think about a typical session in Wappler. You might start by checking your project configuration, then work on a page, follow a Server Connect action, look at your database and check what is happening when the application runs.
Each of those activities needs a different set of tools and a different view of the project.
With Wappler 8, we are bringing those tools together into Activity Workspaces. You choose the activity from the rail on the left, and the workspace brings together the navigation, editing area and contextual tools for that part of your work.
The idea is simple: when you are building a page, your attention should be on that page. When you are configuring your application, you should be able to see how its settings and resources fit together. The interface should help you stay with the task you are working on.
A first look around
The rail gives each activity a recognizable name, icon and color. I want to explain the purpose of each one, because the way these workspaces relate to each other is a big part of the idea.
The activity rail stays within reach while the navigator follows the workspace you are using.
Build: work on the application
Build is where you work on your pages, components, Server Connect actions and source files. It is the place you will return to when you are adding a feature, changing a page or working through the logic behind it.
One of the developments I am particularly excited about is the new Application Map. It gives you a visual way to explore the project, find a page or action and open the right editor. I want the connection between the application as a whole and the detail you are editing to feel much more natural.
Your HTML and Server Connect editors belong here, with the tools that make sense for each. We will take a proper tour of those editors in the next articles.
Setup: understand how the project is configured
Setup brings your project configuration into one workspace. General settings, deployment targets and providers have their own places, with a visual view of how the application is configured. I have prepared a separate first look at Setup alongside this article so we can explore it a little further.
This is where you look at the choices behind the application: its frameworks, backend settings and connections, as well as the configuration for the environments you work with. The aim is to make those choices easier to find and their relationships easier to understand.
Setup brings the different parts of your project configuration into view.
Data: work with the information behind your application
Data focuses on the database side of your project. Tables, relationships and queries are closely connected, so they benefit from a workspace where you can concentrate on that part of the application.
You might be looking at how customers and orders relate, checking the structure of a table or working through the query that supplies a page. Data provides that database-focused view, while Build remains the place for the page or Server Connect action that uses it.
I will share more of the visual database work in a separate article. There is plenty there that deserves a closer look.
Design: shape the visual identity
Design has a different focus from building an individual page. Its purpose is the visual identity shared across the application: themes, styles and the choices that make different screens feel like they belong together.
Think about the difference between editing a button on one page and deciding how buttons should look throughout your project. Having a dedicated place for the broader design choices helps make that distinction clearer.
The Design workspace is separate from the visual Design mode inside the HTML editor. You will still work visually on your pages in Build. I will return to the wider Design workspace in a future preview.
Git: follow changes and project history
Git gives source control its own destination. Its purpose is to help you review what has changed, work with branches and understand the history of your project.
That is a different activity from editing a page or action. When you are reviewing a set of changes, you want to see how they fit together across the project. Giving that work its own space is part of making the overall workflow easier to follow.
We will look at the details of the Git workspace in a later article.
Monitor: see what is happening as the application runs
Monitor brings the running side of the project into focus. Services, output, logs and terminals belong here, so you have a place to look when you want to understand what the application is doing.
For example, you might make a change in Build and then check the service output in Monitor. Or you might start by investigating a runtime problem and return to the relevant code or action once you know where to look.
Setup describes how the application is configured; Monitor is concerned with what is happening while it runs. Keeping those purposes clear is useful, especially as projects grow.
Deploy: bring the application to its destination
Deploy is the workspace for publishing and delivery. Its purpose is to bring together the work involved in taking the application you have been building and getting it to the intended destination.
This connects naturally with Setup. You define the target and its configuration there, then Deploy is where the release activity belongs. I want that relationship to be understandable when you move between developing, reviewing and publishing an application.
There will be a dedicated look at Deploy and its workflows as this series continues.
Projects: find the project you want to work on
Finally, Projects gives you a place to find, open and manage your projects. Many of you work on several applications, so returning to the right project is an important part of the experience too.
The other workspaces organize the activity within a project. Projects helps you choose which project you want to work with in the first place.
From the application to the detail
Here is another glimpse of Build, this time looking at the Contacts area of our Projects HQ example.
Explore an application area, see its connections and open the page or action you want to work on.
What I like about this is the connection between the overview and the actual work. You can start with the application, find a page or backend action, then open its editor to make your changes. Files and source code are still part of the experience, with a more visual way to navigate alongside them.
We are also putting a lot of care into how the workspaces feel together. Navigation, libraries, properties and editor controls should feel familiar as you move between different parts of your project. Those details matter when you spend hours building with a tool.
More to share, starting now
This is the start of a regular series here in Request For Comments as we work toward the first public preview release. After today's introduction, I plan to share new articles on Tuesdays and Thursdays, with both included in our Friday morning newsletter. I want to give you a closer look at the work, explain the ideas behind it and hear how they fit the way you build applications.
Alongside this introduction, take a look at Meet Setup: your project configuration, connected. Next, I want to take you through Build and the Application Map, followed by closer looks at the HTML and Server Connect editors. There are also some very nice improvements around contextual insertion, blocks and data bindings that deserve their own articles.
For now, I would love to hear this: which everyday task currently makes you jump between the most panels, and what are you trying to accomplish? A real example from one of your projects would be especially useful.
I am also interested in whether these boundaries make sense to you. If there is a task you would naturally look for in a different workspace, tell me which one and why. That kind of feedback helps us see the interface through the projects you are actually building.
Which workspaces would you most like me to explore in more detail? You can choose up to two.
- Build, the Application Map and visual editors
- Setup, settings and targets
- Data, schemas and queries
- Design, themes and styles
- Git and source control
- Monitor, services and logs
- Deploy and publishing
- Projects and project management
Thank you for being part of this. I am really looking forward to sharing more of Wappler 8 with you over the coming weeks.