6 ms·

The only good thing is that the database is available via web calls. The bad thing is that the code to render the text is insane (take a look: https://github.c

by zeveb 10y ago

The only good thing is that the database is available via web calls. The bad thing is that the code to render the text is insane (take a look: https://github.com/WardCunningham/remodeling/blob/master/static/index.html https://github.com/WardCunningham/remodeling/blob/master/sta...). Even the goal of the 'remodel' (really, more of a demolition) is crazy: 'The original wiki rewritten as a single page application.' That's like saying, 'roast beef, now with added concrete and carpet!' I just don't get how someone can think the change is a good idea.

deleted 10y ago
[deleted]
chriswarbo 10y ago
I hate JS single-page apps, but as far as c2 goes, I think the idea is to eventually make it distributed. To make that work requires two parts: - Some way for the page to communicate with other instances (e.g. bittorrent, or whatever, implemented in JS) - Some way to display the results (i.e. a JS renderer) The easiest part is the JS renderer, so it makes sense to implement that first. With a JS renderer, the server side rendering can be thrown away. Now that it's a single page using JS calls to fetch data, it's a much easier target to make distributed: "just" switch out where those calls get their data from. I'm glad such experiments are going on, and don't mind putting up with this awkward in-between phase in the mean time.
- zeveb 10y ago
  Actually, I think that the IndieWebCamp guys have it right with WebMention: http://indieweb.org/webmention http://indieweb.org/webmention A page shouldn't communicate with other instances; servers should. The server can render the result of input from other instances once and display it to readers many times, rather than forcing each reader to rerender it itself. The 'some way to display the results' then becomes … static HTML. I think static HTML is rather easier than a JavaScript renderer. > With a JS renderer, the server side rendering can be thrown away. That's a bit like saying, 'with a single can of soda, you can get rid of running water!' Replacing server-side rendering with client-side JavaScript is strictly worse.
  - chriswarbo 10y ago
    > A page shouldn't communicate with other instances; servers should. That requires a server. The point of c2 is it's a wiki: you can edit the content just by browsing to the URL and clicking a button. Sure, self-hosted static HTML sites are a really good solution to lots of problems; editing wikis isn't one of them. The alternative view is that visiting the page brings up your own personal server, allowing you to participate in the network; it just so happens that the server is written in JS and runs in a browser tab. > The server can render the result of input from other instances once and display it to readers many times This is exactly what decentralising a site is supposed to avoid: wiki is an experiment in collectively owned content; removing central points of contact/ownership is the next step. > > With a JS renderer, the server side rendering can be thrown away. > That's a bit like saying, 'with a single can of soda, you can get rid of running water!' Maybe a better analogy is selling seeds rather than vegetables: you save yourself costs on transport, storage, refrigeration, etc. by offloading a bunch of cultivation work on to your customers. It's exactly the wrong approach if you're trying to run a supermarket. If you're an experimental botanist, and a few specialists keep asking you for produce, it's probably a good idea to save yourself time and money by empowering them with seeds. > Replacing server-side rendering with client-side JavaScript is strictly worse. It's worse, but not strictly so; for the reasons I've listed above.
    - zeveb 10y ago
      > That requires a server. The point of c2 is it's a wiki: you can edit the content just by browsing to the URL and clicking a button. If I want other people to see my edits, then they need a way to know that I made them, which requires some agreed-upon rendezvous point — i.e., a server. > This is exactly what decentralising a site is supposed to avoid: wiki is an experiment in collectively owned content; removing central points of contact/ownership is the next step. So support a federated system, in which one user's server contacts another. Without servers, how will I see your edits when your browser is offline, or simply no longer visiting the page? Your edits will have to live somewhere else — a server (whether it's your server, my server or c2.com's server is beside the point: it's a server). > Maybe a better analogy is selling seeds rather than vegetables: you save yourself costs on transport, storage, refrigeration, etc. by offloading a bunch of cultivation work on to your customers. It's exactly the wrong approach if you're trying to run a supermarket. If you're an experimental botanist, and a few specialists keep asking you for produce, it's probably a good idea to save yourself time and money by empowering them with seeds. I thought the whole point of Ward's Wiki was to be a neat place to discuss computer science & programming — in your analogy, to be the supermarket. Sure, it's a high-tech supermarket, conducting some really neat experiments. If I lost my favourite supermarket because the owner decided to go into experimental botany and didn't bother to pay his supermarket rent, I'd feel similarly upset. > > Replacing server-side rendering with client-side JavaScript is strictly worse. > It's worse, but not strictly so; for the reasons I've listed above. It's strictly worse if one has disabled JavaScript (as everyone who truly cares about privacy & security does): the site no longer works, and one gets no benefits at all.
derefr 10y ago
I get the sense that a wiki was, in spirit, supposed to be simple bit of code to turn a read-only website into something that acted more the way the web was originally envisioned, where every hypermedia document could be WYSIWYG-edited inline in a web browser and then PUT back, or appended to and then the appendment POSTed, without needing anything like a <form> element. Since browsers never did move toward that paradigm (though contentEditable was a half-step), I can understand the desire to re-implement that vision more thoroughly, by essentially implementing a "browser the way it should be" within the browser, and then having that better browser talk to your backend. Sure, you could do it as a full hypermedia-editing-capable browser of its own instead (i.e. another "quick hack", this time in Electron) but doing it as a SPA means not requiring people to download+install your app to edit the site. (Or, you could say, the app is zero-click installed, ephemerally, when you access the site. If other sites used this software by referencing the same SPA JS bundle from the same CDN, it'd give about that effect.)

by zeveb 10y ago

deleted 10y ago

[deleted]

chriswarbo 10y ago

I hate JS single-page apps, but as far as c2 goes, I think the idea is to eventually make it distributed. To make that work requires two parts: - Some way for the page to communicate with other instances (e.g. bittorrent, or whatever, implemented in JS) - Some way to display the results (i.e. a JS renderer) The easiest part is the JS renderer, so it makes sense to implement that first. With a JS renderer, the server side rendering can be thrown away. Now that it's a single page using JS calls to fetch data, it's a much easier target to make distributed: "just" switch out where those calls get their data from. I'm glad such experiments are going on, and don't mind putting up with this awkward in-between phase in the mean time.

zeveb 10y ago
Actually, I think that the IndieWebCamp guys have it right with WebMention: http://indieweb.org/webmention http://indieweb.org/webmention A page shouldn't communicate with other instances; servers should. The server can render the result of input from other instances once and display it to readers many times, rather than forcing each reader to rerender it itself. The 'some way to display the results' then becomes … static HTML. I think static HTML is rather easier than a JavaScript renderer. > With a JS renderer, the server side rendering can be thrown away. That's a bit like saying, 'with a single can of soda, you can get rid of running water!' Replacing server-side rendering with client-side JavaScript is strictly worse.
- chriswarbo 10y ago
  > A page shouldn't communicate with other instances; servers should. That requires a server. The point of c2 is it's a wiki: you can edit the content just by browsing to the URL and clicking a button. Sure, self-hosted static HTML sites are a really good solution to lots of problems; editing wikis isn't one of them. The alternative view is that visiting the page brings up your own personal server, allowing you to participate in the network; it just so happens that the server is written in JS and runs in a browser tab. > The server can render the result of input from other instances once and display it to readers many times This is exactly what decentralising a site is supposed to avoid: wiki is an experiment in collectively owned content; removing central points of contact/ownership is the next step. > > With a JS renderer, the server side rendering can be thrown away. > That's a bit like saying, 'with a single can of soda, you can get rid of running water!' Maybe a better analogy is selling seeds rather than vegetables: you save yourself costs on transport, storage, refrigeration, etc. by offloading a bunch of cultivation work on to your customers. It's exactly the wrong approach if you're trying to run a supermarket. If you're an experimental botanist, and a few specialists keep asking you for produce, it's probably a good idea to save yourself time and money by empowering them with seeds. > Replacing server-side rendering with client-side JavaScript is strictly worse. It's worse, but not strictly so; for the reasons I've listed above.
  - zeveb 10y ago
    > That requires a server. The point of c2 is it's a wiki: you can edit the content just by browsing to the URL and clicking a button. If I want other people to see my edits, then they need a way to know that I made them, which requires some agreed-upon rendezvous point — i.e., a server. > This is exactly what decentralising a site is supposed to avoid: wiki is an experiment in collectively owned content; removing central points of contact/ownership is the next step. So support a federated system, in which one user's server contacts another. Without servers, how will I see your edits when your browser is offline, or simply no longer visiting the page? Your edits will have to live somewhere else — a server (whether it's your server, my server or c2.com's server is beside the point: it's a server). > Maybe a better analogy is selling seeds rather than vegetables: you save yourself costs on transport, storage, refrigeration, etc. by offloading a bunch of cultivation work on to your customers. It's exactly the wrong approach if you're trying to run a supermarket. If you're an experimental botanist, and a few specialists keep asking you for produce, it's probably a good idea to save yourself time and money by empowering them with seeds. I thought the whole point of Ward's Wiki was to be a neat place to discuss computer science & programming — in your analogy, to be the supermarket. Sure, it's a high-tech supermarket, conducting some really neat experiments. If I lost my favourite supermarket because the owner decided to go into experimental botany and didn't bother to pay his supermarket rent, I'd feel similarly upset. > > Replacing server-side rendering with client-side JavaScript is strictly worse. > It's worse, but not strictly so; for the reasons I've listed above. It's strictly worse if one has disabled JavaScript (as everyone who truly cares about privacy & security does): the site no longer works, and one gets no benefits at all.

derefr 10y ago

I get the sense that a wiki was, in spirit, supposed to be simple bit of code to turn a read-only website into something that acted more the way the web was originally envisioned, where every hypermedia document could be WYSIWYG-edited inline in a web browser and then PUT back, or appended to and then the appendment POSTed, without needing anything like a <form> element. Since browsers never did move toward that paradigm (though contentEditable was a half-step), I can understand the desire to re-implement that vision more thoroughly, by essentially implementing a "browser the way it should be" within the browser, and then having that better browser talk to your backend. Sure, you could do it as a full hypermedia-editing-capable browser of its own instead (i.e. another "quick hack", this time in Electron) but doing it as a SPA means not requiring people to download+install your app to edit the site. (Or, you could say, the app is zero-click installed, ephemerally, when you access the site. If other sites used this software by referencing the same SPA JS bundle from the same CDN, it'd give about that effect.)