1 Like
As per my last post, @marten and myself are Admins. Marten is the people person and I do the technical stuff on the server. Both of our category groups have only ever been used for support and never promoted a single thing, ever.
We pay for this forum for the benefit of all and have never abused the trust or asked anyone else to contribute. It is not a political statement or in competition with any other forum.
All the developers who are moderators are listed in the screenshot below. There is no agenda here and no secrecy. Perhaps you would like to become a moderator? Perhaps you would like to declare your interest in working for Chillidog who has a clear interest in RW? This is all just ridiculous but if you want to make accusations, particularly about me who I thought you knew, then I will post for transparency.
7 Likes
“WebView” (a generic name, but that’s the name it has) is already deprecated. It has been for several years. The replacement on macOS is WKWebView.
WebKit, the framework, is not deprecated.
WKWebView is a much more secure browser view. And since security is one of Apple’s top-line features these days, they want to strongly encourage developers to go to WKWebView.
Unfortunately, like many of Apple’s security technologies, they’ve made things more secure simply be removing access to many things.
Stacks has used WebView (the old one) for the edit-mode user interface since Stacks v1.0. We make use of a barely documented and often overlooked C-based API to the DOM. In English it means that there’s a super-fast, low-level way to communicate with web pages.
The security implications of this are nearly moot as Stacks Edit-Mode doesn’t support Javascript or even linking.
That said, I was among the first to get excited about WKWebView – and to try it out. Unfortunately in WKWebView there is no way to interact with the DOM (the document object model – the web page renderer) except through Javascript. Enabling Javascript really does affect security. I requested (I’m sure with a great many others) of a way to interact without JS – and WKWebView did deliver a feature. I can now enable JS just for my stuff – but keep JS off for the content being displayed. However JS is still almost 100x slower – yes TWO ORDERS OF MAGNITUDE slower – than the old C-based API.
I’ve since found some more direct ways to pipe in data in large chunks (Web Sockets are pretty amazing), and better ways to implement the JS updates (fewer updates, bigger chunks). This nearly closed the gap. Nearly, but not quite.
But there’s no getting around the speed differential. Even with months of work and careful optimization, it’s still substantially slower than the old way.
For this reason I hold on to these updates and wait patiently until the 3rd or 4th day of WWDC in June of each year, when new WebKit details are released. Then I chat with Brady Eidson on twitter, a friendly WebKit developer, to see if the old WebKit will be included for another year.
While the old way is faster and available I will continue to use it. When it becomes unavailable I’ll be ready with the necessary change well before macOS ships, months later in the fall.
I’m not sure if Apple will remove it soon. As always, I hope for the best and prepare for the worst. :-)
Of course, I’ve told RealMac this all this when they asked – even just recently. I doubt they’ve forgotten. I’m not sure why they’ve chosen to include this. I guess FUD (Fear, Uncertainty, and Doubt) is just an easy way to make people worry. I hope you folks are smarter than all that.
:-)
10 Likes
I hope you folks are smarter than all that.
No worries, most of us are ;)
1 Like
It’s also laid out pretty clearly in the About - RW4ALL page (but who would ever think to look at the About page to find out what a site was about)
1 Like
Fascinating - I always thought WKWebView was running a low-level language like Swift & not js - no wonder you had to spend so much time to optimize :)
Maybe there’s a swift version or something similar coming in the future - (crosses fingers)
Later,
Bill
Stack-Its
Very unlikely.
The JS engine in Safari (and all browsers) is an entire walled off runtime that doesn’t have direct access to memory (because JS doesn’t do that) and doesn’t have access to the file system (because browsers don’t do that).
Native binaries in Swift, C, C++, Obj-C all have full access to memory and the file system in the normal old Unix way (POSIX). That makes them very dangerous.
The old WebView contained a C API and JS. This means it exposes the safe runtime to the unsafe runtime. The security people call that an “attack surface” and security folks, when they have an inherently unsafe thing (like a browser engine that will view pages from untrusted sites on the net) often talk about “reducing the total attack surface.” The old WebView, with the C API has a large attack surface.
The one caveat here is something called WebAssembly: WebAssembly - Wikipedia
WebKit now supports web assembly and this essentially lets you compile native code into the low level runtime engine inside the browser. This is pretty close to native speeds – running safe walled garden that JS lives in.
The challenge for web assembly is how to use it for something pragmatic. Currently I think there is only support for some system libraries to compile C, C++, and Rust.
Frustratingly the output to the DOM – and all interactions to the web page at all – must pass through JS.
So with web assembly the situation is no better. You still must pass through the very very slow JS DOM manipulation functions. And no browser has any plans to change that.
The other option would be a private build of WebKit. Perhaps with JS removed entirely. It seems quite feasible, but I think Apple would not allow it in the App Store. They’re pretty strict at only allowing WKWebView now.
So when I do a build of Stacks5.app for the Mac App Store it will always be with the new WebSockets WKWebView solution (among quite a few other things like updaters, that are disallowed in App Store builds).
Isaiah
1 Like
My hope is that both RW9 and Stacks5 will be available as a trial/demo so that users can ensure that their existing sites can translate over to RW/Elements, or that the Stacks5 interface works as designed.
I can see the appeal of both solutions, with RW9/Elements it sounds like they will try to replicate some of the more fundamental stacks into their base product. From an end-user perspective this provides a ‘one-stop shopping’ experience. If there are any issues, there is only one developer/product to deal with.
Conversely the free-wheeling stack developers in Stacks5 can provide more esoteric tools for those users with more complex environments.
If I have a criticism of the existing stacks environment it is this;
If a stacks developer decides to drop out of the business, it can leave their users hanging, and if those stacks later break then it can cause financial issues to the end-user.
To this end, I would like to see a ‘Certificate of Continuity’ program, where developers can certify within the Stacks5 app, that if they drop out of the business - or are unable to continue - that they have made arrangements to pass support for their existing stacks to another developer.
1 Like
Your final idea is great, but I suspect unrealistic.
Most… Not all, but I suspect most, Devs and their stacks drop out because the venture is no longer cost effective. Ie. They are making no money. Getting another Dev to take over development of such a stack is going to be challenging to say the least.
If on the other hand that dev is dropping out for other reasons and their stacks are still making money, or have the potential to make money, you normally find someone steps in.
This situation isn’t unique to RW.
3 Likes
Looking at this from a different perspective - RW9 is a new product. It’s leveraging it’s name but to all intents and purposes it’s a new app. It has (by design) closed the doors to previous developers unless they put a shitload of work in so users can carry on (this will be contentious and the shills will bite) and now it wants to shine by itself. Nothing wrong with that. Good luck to them, him. It does look like a money grab, it probably is. RW has not changed very much in it’s various incarnations, small upgrades at best for 50 bucks or so. I’m looking forward to the revelation that is RW9, I’m curious what will be on the table. Probably same as previous upgrades - fuck all. However I’m hopeful.
But, and there’s always a but, the whole ecosystem was never RW, it was stacks. I wish Dan all the luck in the world but this is a folly.
3 Likes
Looking back at previous versions, Rapidweaver without Stacks would have been like Photoshop without plug-ins. The combination gave casual users like me unprecedented power. Their upcoming divorce is something I dread. I wish that all parties would realize that users are the innocent children of this divorce. If both parties can’t figure out how to settle things amicably, I (and probably a lot of other people) will just go somewhere else. I don’t care who’s right, who’s wrong, who’s better, who’s worse, or who started it. I don’t have the time or interest to take a side, so I won’t be upgrading either product. You guys can argue all you want, even if it means that you divide and destroy the market for what were two great products. Sorry, but I have work to do.
3 Likes
Apparently there are new developments on Realmac’s stance on the whole situation
Source:
2 Likes
The key word used twice in all of that is “think”.
Sounds like stuff has to line up before any work gets started. We are already in June!
2 Likes
Me too, All my sites are stacks built.
I’m rather late in following all this news, and in all likelihood this will push me to moving my sites to Blocs.
2 Likes
I’m sorry but what is it that you are trying to accomplish by stating that? Could you at least elaborate a little on your statement and your rationale?
There are two sides to all arguments. Sadly, some responses from the community have been quite unkind.
Stacks app v1 and Rapidweaver 9 elements v1 are all going to be works in progress and release dates may well not be this year. This means site breakages in the initial period after release are going to be inevitable. Both will be immature products and take time to bed in and iron out problems.
Blocs has been going for a while and become quite mature. Rather than going through the hassle of this split and the potential headache this creates, moving platforms seems far more likely for me personally.
2 Likes
By all means jump to Blocs, it’s a great product.
But don’t get caught up in the rush to something new, just cus it’s new. RW8 and S4 will continue to work for some time to come. So it should be more than possible to sit on your hands until the new iterations are working perfectly (as perfectly as anything works in the RW world!).
5 Likes
I’ve had Blocs for quite a while but never used it to build a site, only demos for myself. I’ve waited for it to mature and now with an iPad app on the horizon (very helpful for me) and the situation with RW and Stacks, these will probably give me a push in the Blocs direction. I’m not going to redevelop all my sites, but may try a couple and see how it goes.
I certainly don’t want to be in a position where some stacks will only work with Stacks app and others with RW as some developers have already stated will be the case with their stacks.
1 Like