I created this tool with a very odd necessity: I hate animations and overlay ;). I would like to have access to the website data directly and build my own interface, but for this, I would have to have access to the information only. I know that the website could expose an API, but WDR feels much more natural and easy (try to do a `fetch` on the page and get the JSON instantly).
Now that I have built and have played around a bit, I don't see how can I build a website in any other way.
For me, the website's information is important, not the design. WDR exposes that.
I like the idea of separating the content from the presentation, although working with JSON directly to create the content, to me, is not fun.
Did you play around with just using markdown directly and embedding html tags in that in a similar way to format the page? I can't imagine myself intentionally writing web content using JSON. I'd probably have some other format up front that would be converted to JSON, but at that point I may as well just write some static page generator to create the html.
I think it is early to make more conclusions, but I had to adjust my way of thinking to work with WDR. We are so accustomed to thinking data+markup that it is hard to imagine any other way. So, I started to create the JSON data without thinking about the design at all. "What information I would like to see on this page", and I created the JSON thinking only on that. It turns out, creating the render afterward was much easier and faster (and pleasant). It is, at least for me, a new way to think about the page.
This makes a lot of sense and I agree with this need! I want to throw in a healthy dose of skepticism about whether your solution can address that need -- only because I hope that hearing it early can increase your chances of success!
I think a hard problem ahead would be how to convince other people to also adopt this framework, and how to make sure that people are using the same JSON keys to mean the same thing. I'm a little skeptical that this can happen on its own, because we've already tried a standard that was supposed to designed to convey just the content of the website without the presentation -- HTML.
I'm curious how you plan to prevent your JSON format from being (ab)used for presentation purposes, where people add extra content to make the page display a certain way. And if you have a plan, is this plan feasible using HTML as well?
>I think a hard problem ahead would be how to convince other people to also adopt this framework, and how to make sure that people are using the same JSON keys to mean the same thing.
At first, I was thinking to use some kind of general schema, but those things never work. So I decided something much simpler: the render determines the schema. This is an important aspect that I am working on. If you choose some specific render, your JSON will have a specific shape. For example, if the render is for a landing page, the JSON could be something like "about", "products", "team", etc. (never <section>, <h1>, etc...). But it is too soon to tell I'm still thinking about it.
(but an interesting corollary is that the render could be also a program with the "config" part. It would be an alternative to website builders. Every render would be a different WB tailored for the website)
> I'm curious how you plan to prevent your JSON format from being (ab)used for presentation purposes, where people add extra content to make the page display a certain way. And if you have a plan, is this plan feasible using HTML as well?
I don't have a plan for that yet, and it will be difficult because we are accustomed to mixing data+markup. But I think the mindset is to stop thinking the website for just the browser. The website could be information first, presentation later.
Honestly, I think letting people include their own code is good, people will always want to do things that you couldn't have imagined yet, and for their own good reasons.
However, you need to make sure the platform can eventually catch up with the de-facto standards people are coming up with, so that people don't keep having to keep on re-inventing these wheels. As a comparison, see how JavaScript features evolved from jQuery and Underscore features.
> But I think the mindset is to stop thinking the website for just the browser.
I agree. I'd suggest that you think through how you can convince people to stop thinking about the website as just for the browser.
In the last decade, many people might have thought that the rise of the mobile web would made web developers separate presentation from content. But instead of using the same HTML with different stylesheets, what actually happened is every major website started maintaining two completely separate websites, one for web and one for mobile! I'd recommend thinking about why this happened, to make sure your framework doesn't nudge people down the same route.
Now that I have built and have played around a bit, I don't see how can I build a website in any other way.
For me, the website's information is important, not the design. WDR exposes that.