4 ms·

I honestly do not wish to bash on the implementer, but it's an absolute disgrace what they did to c2.com. It feels like an April Fool's joke.

rcarmo 9y ago
The archived copy linked to elsewhere on this thread loads and renders _much_ faster than c2, which ironically requires me to disable my ad blocker to actually load.
zeveb 9y 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 9y ago
  [deleted]
- chriswarbo 9y 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 9y 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 9y 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 9y ago
- derefr 9y 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.)
deleted 9y ago
[deleted]

rcarmo 9y ago

The archived copy linked to elsewhere on this thread loads and renders _much_ faster than c2, which ironically requires me to disable my ad blocker to actually load.

zeveb 9y 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 9y ago
[deleted]
chriswarbo 9y 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 9y 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 9y 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 9y ago
derefr 9y 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.)

deleted 9y ago

[deleted]