Observations of RapidWeaver Elements Private BETA

[handshaper (Robin Mair)]

Since I purchased a Pro subscription on July 26, 2024, to test and contribute to the initial release of RW Elements, a significant amount of work has been accomplished. Reflecting on my experiences with Elements, I’m struck by the progress made in the past three months.

To test Elements, I slowly ported one of my existing Classic sites to Elements. The site I chose to use was created with Foundry 3, which made it stress-free. Of course, the original site was created with Stacks and probably would only have been possible with Stacks.

Porting this site was hampered by the need for some fundamental components in Elements, but I continued. Where I needed functionality, I either ignored it for a later date or cobbled something together with a custom component and an amalgamation of existing components. The lack of functionality certainly did not severely hamper the process but made it a little more tedious.

Early on, it became evident that the workflow in Elements was markedly different from that in Stacks. Initially, this difference posed a challenge, but it soon became clear that the Stacks approach was more cumbersome. The lack of an interactive preview in Stacks was a significant obstacle. This unexpected difference in workflow was a key learning from my testing experience.

Quickly, I realized that I could not continue to be productive in Classic/Stacks after playing with Elements, even though Elements was a long way from being finished.

Despite the significant roadblocks in Elements that still need fixing, it’s a pleasure to work with the app. The team’s dedication to doing the right thing, despite being pulled in many directions, is commendable. The distraction of the allure of what I’ll call the ‘Gucci’ features, the eye-catching features that captivate users, slowed things down. Focusing on locking down the core features first would have allowed us to thoroughly test and solidify the core, a strategy that would have made more sense.

But we are where we are, and the team has now focused on the core features to bring the app closer to a public BETA release. This was a wise decision. I’ll happily settle for a solid app with missing features if it allows me to build a reasonable website with less effort.

This is where Elements will shine; building a website in the app is fun! The workflow feels much less tedious than Classic/Stacks and is more intuitive. There is a learning curve, but there always will be with a new app. Once I better understood the underpinnings, learning how to leverage the app was easier.

Much progress has been made on Elements since this process began, and I am confident we will end up with something that will meet or exceed our needs.

After three months with Elements, I can confidently give it a thumbs-up. I will now wait for the missing functionality and the chance to publish my ported site someday.

There is much left to be done before we see v1, but at least I’m bullish on getting there.

[Bruno (Bruno Le Penven)]

Hi @handshaper I stopped “testing” Elements for over two months now because doing-undoing-learning to do differently-starting over-etc got the better of me. Totally agree, the focus on catch-… didn’t help. I see a change in approach, which is good. So I’m eagerly awaiting the Public Beta to finally try building a site with Elements and finally find out if it’s right for me.

[Bartje (bart vosters)]

I fully agree with your analysis. Once you start working with Elements (even though it’s still in a rough beta version), it’s hard to go back to RW Classic with stacks. I paused testing over the last few weeks, waiting for the new beta with the reworked components and text editor. I want to rework my existing sites with Elements as soon as possible; I just hope that many stacks I use for specific purposes (such as retrieving data from Google Sheets) will be quickly converted to Elements. Because currently, this is the biggest drawback for me: there’s no visibility at all on what will happen with components from third-party developers or where that direction will go.

[Bruno (Bruno Le Penven)]

The rapid conversion from Stacks to Elements will not happen quickly in my opinion. On the one hand because it is obvious that Stacks developers have been pushed towards the exit, on the other hand because the model that is not clearly announced as a subscription for developers (so that they have access to the Elements API and can sell their creations to others, with a sort of Apple Market, we know the story of royalties) is not going to attract many I fear, in any case not the best unfortunately. I would very much like to be contradicted and I would appreciate just as much to be proven wrong because I believe this is where the future is played out in the first instance (AI seems to be relegated to a second phase which for me is downright nonsense given the situation). Yeah, I know my posts haven’t been very optimistic lately, unlike my usual supportive nature, but seeing the mistakes and seeing that the course is being maintained despite everything doesn’t make me wildly optimistic.

[trinube (Kim)]

@Bartje

I just hope that many stacks I use for specific purposes (such as retrieving data from Google Sheets) will be quickly converted to Elements.

I’ve been using ChatGPT a lot lately on a software project I’m doing. On a whim I thought I’d ask it about retrieving data from Google Sheets.

I have no idea if this code is valid or would work (I don’t use google sheets), but I suspect given a few tries and pumping any errors back in would likely get you a working solution:

To create a custom component in Rapidweaver Elements that retrieves data from a Google Sheet and displays it in a grid format, you can use a combination of Google Sheets API and JavaScript for fetching data, then use HTML and CSS to display the data in a grid.

**Here’s a step-by-step guide to create this custom component:**

**Step 1: Set Up the Google Sheet**

	1.	Go to Google Sheets and create or open the sheet you want to use.
	2.	Make the Google Sheet public or share it with “Anyone with the link” to allow access to the data:
	•	Click on File > Share > Share with others.
	•	Set “Anyone with the link” to Viewer.
	3.	Copy the Google Sheet ID from the URL. It will look something like this:
	
	https://docs.google.com/spreadsheets/d/GOOGLE_SHEET_ID/edit#gid=0
	
	**Step 2: Use the Google Sheets API to Get Data**

Google Sheets provides a public JSON feed for your data if your sheet is shared publicly. You can retrieve this data using an API URL structured like this:

https://spreadsheets.google.com/feeds/cells/GOOGLE_SHEET_ID/1/public/full?alt=json

	•	Replace GOOGLE_SHEET_ID with the actual ID of your sheet.
	•	The /1/ part refers to the first sheet in your document. If you have multiple sheets, change this number accordingly.

**Step 3: Create a Custom Component in RapidWeaver Elements**

Below is a basic JavaScript and HTML setup for fetching data from the Google Sheets API and displaying it in a grid format.

HTML Structure and JavaScript Code:

<div id="data-grid"></div>

<script>
// Google Sheet ID
const sheetId = 'YOUR_GOOGLE_SHEET_ID'; // Replace with your actual Google Sheet ID

// URL to fetch Google Sheet data
const apiUrl = `https://spreadsheets.google.com/feeds/cells/${sheetId}/1/public/full?alt=json`;

// Function to fetch and display Google Sheets data
async function fetchGoogleSheetData() {
  try {
    const response = await fetch(apiUrl);
    const data = await response.json();

    // Get the entry list from the JSON response
    const entries = data.feed.entry;

    // Create an array to store the data in rows and columns
    const gridData = [];
    entries.forEach((entry) => {
      const row = parseInt(entry.gs$cell.row) - 1;
      const col = parseInt(entry.gs$cell.col) - 1;

      if (!gridData[row]) {
        gridData[row] = [];
      }

      gridData[row][col] = entry.gs$cell.$t;
    });

    // Generate the HTML for the grid
    let gridHtml = '<table border="1" cellpadding="10" style="width: 100%;">';
    gridData.forEach((row) => {
      gridHtml += '<tr>';
      row.forEach((col) => {
        gridHtml += `<td>${col || ''}</td>`; // Add cell data or empty string if undefined
      });
      gridHtml += '</tr>';
    });
    gridHtml += '</table>';

    // Display the grid on the page
    document.getElementById('data-grid').innerHTML = gridHtml;

  } catch (error) {
    console.error('Error fetching Google Sheet data:', error);
    document.getElementById('data-grid').innerHTML = 'Failed to load data.';
  }
}

// Call the function to fetch and display data
fetchGoogleSheetData();
</script>

**Step 4: Customize CSS for Grid Styling**

To enhance the look of your grid, you can add some custom CSS inside the <style> tag:

<style>
  #data-grid {
    margin: 20px 0;
  }

  #data-grid table {
    border-collapse: collapse;
    width: 100%;
  }

  #data-grid table, #data-grid td, #data-grid th {
    border: 1px solid #ddd;
  }

  #data-grid td, #data-grid th {
    padding: 8px;
    text-align: left;
  }

  #data-grid tr:nth-child(even) {
    background-color: #f2f2f2;
  }

  #data-grid tr:hover {
    background-color: #ddd;
  }

  #data-grid th {
    background-color: #4CAF50;
    color: white;
  }
</style>

**Step 5: Integrating into RapidWeaver Elements**

	1.	Add a Code Element: In Rapidweaver Elements, add a Custom HTML element or a similar component that allows you to paste custom code.
	2.	Paste the HTML, JavaScript, and CSS from the above steps into this custom code element.

**Step 6: Testing the Component**

	•	Publish the page or preview it within RapidWeaver.
	•	Ensure that the data from the Google Sheet is properly loaded and displayed in the grid.

**Notes:**

	•	Ensure that the Google Sheet is set to be publicly accessible to allow the data to be retrieved via the API.
	•	The structure above uses JavaScript’s fetch() API to asynchronously retrieve data from Google Sheets and dynamically display it in a table format on the page.
	•	You can further customize the grid with more advanced styling or formatting logic based on your needs.

This will give you a responsive, real-time data-driven grid on your RapidWeaver page, directly pulling from Google Sheets. 

All this to say I think everything which could be done in Stacks will eventually finds its way into Elements.

[jscotta (James Scott Anderson)]

I think that this is going to be the way. Access to data sources through published API’s is going to make custom Components very useful. And using GenAI to analyze the API and then make the needed Component would be a killer custom Component feature.

[Bartje (bart vosters)]

I followed your suggestion and started using ChatGPT. I use it regularly, but never for Elements because I thought it would be too difficult for someone like me who knows nothing about coding. In less than half an hour, I had a rough first version that actually displayed data from a Google Sheet file in Elements. This makes Elements even more interesting because now you can try out a lot of things on your own. It certainly won’t work for everything, but it does open up new possibilities

Let’s see if we can get data directly from Jotform without the need to export it to Google Sheets first, as was required with RW Classic. This would streamline the process, bypassing the need for a Google Sheet as an intermediary.

[pumpkin (Fynn)]

@Bruno

The rapid conversion from Stacks to Elements will not happen quickly in my opinion. On the one hand because it is obvious that Stacks developers have been pushed towards the exit, on the other hand because the model that is not clearly announced as a subscription for developers (so that they have access to the Elements API and can sell their creations to others, with a sort of Apple Market, we know the story of royalties) is not going to attract many I fear, in any case not the best unfortunately.

And there I was thinking that developers would be happy about another market that can create more income. That of course needs some work and effort to learn the new API . I’m not a developer, but isn’t that what developers do?

[Bruno (Bruno Le Penven)]

Yes, but under what conditions? That’s the question I think, when we realize that those who were expected to go there are no longer going and/or are no longer even there, including those who participated in the early days of Elements. Added to this is the interest that there will be for such a market with AI. It is not uninteresting to look at Claude to see that the space for add-on developers for Elements is going to be extremely limited when we see what non-developers can do with Claude right now. So for those who like to have fun and make Claude chat with Perplexity and Chatgpt, I think there are a lot of games that already exist. When Agentic “frees” its agents, we won’t even need to play anymore, we’ll watch them play. Hey, that reminds me of a Seinfeld sketch about football fans. They watch the game on TV and when their team wins they shout “we won we won.” Seinfeld, calmly, looks at them and says: “No! They won, you watched.” I don’t know if my subluminal message is getting through here?

[Flash]

I think the opening post summarizes things the best for me. Yes, version 2 will likely make a positive difference.

Many people don’t like betas, so it’s way too early to judge its success or failure.

Also, let’s not forget, this is a business. It is something that is built over time. Any business is about trust. Trust is earned and I feel RM is slowly earning that trust which will build the business. Building the business will show 3rd party dev. that there is an ecosystem. This will create momentum that will build the business. This is the way it works.

My number one point, it’s WAY too earlier to pass judgement. The game hasn’t even started yet.

[thominator (Thom Hogan)]

I agree with most of the original post.

The thing I don’t like about Stacks is that became one of two things: buy into someone’s foundation and its stacks, or sort through a huge number of reinventing the wheel stacks and getting them to work together. Elements has neither of these issues. It’s Elements, HTML, and Tailwind, period, which is a much cleaner and direct approach.

I’d like to think that developers actually develop, not redevelop.

There is an existential problem with Elements that hasn’t been finalized yet. And that’s the boundary line between what Elements does, and how others can extend it. Sometimes I see the Elements team working on things that aren’t all so foundational (though I’ll admit that has turned up some things they needed to rework). The fact that we don’t have fully working text, linkage, and a few other basic things is frustrating for those of us trying to use the beta to prototype designs as opposed to trying to beta things that might be saleable components.

I’d like to say the team say “nothing new being added until all the foundational elements are fully developed” and race to a real beta. What we’ve been using is really alpha. But it is what it is, so we (mostly) wait as we just play with what we’ve got.

As for the “rapid conversion from Stacks to Elements will not happen quickly,” that sort of depends upon who you are and your viewpoint. If you’re a RWC user who sells site designing to clients, no, you’re not likely to change quickly. The client doesn’t know/care what you’re using, and you’ve got too much invested time in what you’ve built.

However, I’d bet that RWC sees a rapid decline once Elements appears. Creating a new site (e.g. new client work) is going to be easier, faster, more direct, and involve fewer external parts (foundations, stacks, etc.). That would be even more true if Realmac hired someone to do the kind of manual/book I made my career on. The current “manual” is for geeks who already understand where they’re starting, where they’re headed, and what they eventually need. Elements is good enough to appeal to a far broader audience, but they’ll have a bit of a problem getting started, I’ll guess.

[handshaper (Robin Mair)]

My final observation about Elements is that the one thing that has really disappointed me has been the fact that RM has left some potential developers hanging. This happened when they abandoned their Stack conversion support.

One developer I have talked to whose stacks I use has told me about his experience trying to bring his stacks to Elements. He ended up abandoning his efforts due to lack of support. This was a blow to me as his stacks would have been one of three I consider essential to the success of my sites if built with Elements.

I hope in the not too distant future RM will show us how they plan to attract and retain developers that can provide more obscure components than those provided natively. I think it is unsustainable to think RM can provide all of these components. Whereas some of these developers have expertise that could be leveraged to help round out Elements.

A simple example would be some sort of form component like the Formsnap stack. You cannot build a successful wesbite without a contact form. Sure RM could provide one, but if it is anything like the one provided in Classic it is not likely to meet the demands of more modern contact forms.

I’ll continue to root for RM, but I would really like to see some effort to reach out to developers that want to move to Elements and who can bring value to the platform.

[Bartje (bart vosters)]

The ease of generating code with AI and creating a custom component myself is incredible. As I mentioned, I know nothing about coding or programming and had no idea what properties were, among other things. In less than an hour, I had a working version that retrieves data from a Google Sheet using input fields. I set up four fields via properties (API Key, Sheet ID, sheet name, and cell range to be displayed)…. Now, I just need to add some CSS code to adjust the layout based on the theme, and I don’t have to wait for a third party to make this possible. I never thought I’d be able to accomplish this.

[Bartje (bart vosters)]

An hour later, and I have a fully functioning custom component

[trinube (Kim)]

Nice! Would like to see the resulting page.

[Flash]

This is a great example of what can happen when RM was no longer held back by legacy code and compatibility. In my opinion, they created something special here. I know Dan says that a lot, I just happen to agree based on the evidence.

[handshaper (Robin Mair)]

I hate to say this but I’m going to have to bow out of testing this private BETA for the foreseeable future. I have been very bullish on the whole process. But I have finally reached my breaking point.

Trying to get anything done involving RESOURCES is an absolute nightmare. Every time I try to do anything involving resources Elements crashes. In the last ten minutes it has crashed five times. I can’t get much done without access to resources, especially if I want them to be remote.

So I will be suspending my testing until I hear that resources have been given some attention. I realize there are probably other things that have higher priority at this time. As far as I’m concerned this is one of the fundamental tent pole functions of an app like Elements. This should just work and if it does not it should be fixed before anything else, with the possible exception of text editing.

What a bummer.

[Bartje (bart vosters)]

I continued experimenting and now have everything set up so you can easily specify which data from the Google Sheet should be retrieved, how the header and row content should look (background color, text color, border thickness, border color, etc.), and you can even choose which columns to hide, the order of the columns, and the maximum number of rows to display. Initially, there was an issue with placing two components on one page, but that was resolved by providing a unique name for each component. For me, this is the perfect replacement for the Live Data Stack from 1LD that I use in RWC to achieve the same. You can see the result in the screenshot as well. Don’t mind the horrible color combination, but this shows what you can achieve by customizing it yourself.

[trinube (Kim)]

It’s pretty amazing that 24 hours ago you were hoping someone would port a stack over and now you have a functional, free component you can add to or modify at will. Very well done.

I can see a lot of collaboration between people in the future with the more advanced things being left to the 3rd party developers. Teach a man to fish…

[dan (Dan C.)]

This is really great, and it’s lovely to see customers getting as excited about this feature as we are. Once you start building components (and understand how it all works), the possibilities it opens up are endless — It’s also incredibly empowering to be able to build your own custom solutions whenever needed!

I really think custom components, are going to end up being one of the killer features in Elements.