> I've only had to time to take quick look, but I'm impressed at how clean the code looks.
Good to know that it's somewhat readable for people who are not me!
> I could be wrong, but it actually looks smaller in size than Arc's version, but with more features.
It's still smaller and it does have file upload, but there's a lot of news.arc features missing before this one is usable.
> > not a general purpose cms (link to 'The CMS Trap')
> That's me. I'm that guy - lol (well not quite but close).
I read a blog post about Wagtail, a Python CMS, and wanted to try it out. Once up and running, it has a user login/registration form, but you literally can't post anything, because it's more like a CMS framework or something (or maybe that is what CMS really means?). To me that embodied 'The CMS trap'.
> Between, no JS, Free Software and the above I'm getting that you and I have very different goals :)
Yea, good to hear different opinions here.
Ok, so I'm not totally against JS, and I'm using it myself for other stuff. I think I'm just really pro progressive enhancement, and it's sometimes the first thing to go. For example, I don't think HN has a reason to not allow voting w/o JS. I think there's a bit of a tendency to use way too large and slow JS frameworks, but I'm interested in ClojureScript now because it seems to be all about eliminating dead code and optimizing.
> I read a blog post about Wagtail,....because it's more like a CMS framework...
Yeah neither Drupal nor Wagtail sound remotely appealing to me. A CMS, in general terms, is just that: a Content Management System. Now that's pretty broad with lots of room for products which are both good and bad.
Personally I'm interested in the Business Intelligence space where people build Apps, only I'm targeting companies who wish to empower their Business Analysts (or specifically the blue to 'purple people') to build apps and streamline inefficient IT processes.
I'm not sure if BI apps are considered a CMS or not, but when I read that 'trap' article I couldn't help but relate.
> I think I'm just really pro progressive enhancement, and it's sometimes the first thing to go.
Well progressive enhancement is not, not using JS.
Progressive Enhancement is pretty much the opposite of Graceful Degradation. In GD you fallback to allow lesser technologies to handle the workload, where PE is starting with limited functionality and build up incrementally to gracefully handle the workload. JS is often what is used to achieve PE.
> I think there's a bit of a tendency to use way too large and slow JS frameworks, but I'm interested in ClojureScript now because it seems to be all about eliminating dead code and optimizing.
All I can say here is that automation and the benefits that comes from that will have a cost. Your product/app/page will contain larger files which do some amount of work for you.
Developers have a tendency to see 'frameworks' from a maximal code efficiency perspective, but frameworks really are all about lessening the $ cost, the work burden, time to market and the operational maintenance. The argument is always "If you're building a blog you shouldn't need a framework." And that's true, but most frameworks are not built for making blogs, they're built for greater things - however if said framework makes it easier for person A to do thing X, even if it's just a blog then, really, it's hard not to see it happening (even though developers don't like to see it).
Frameworks, really, are for when large tailor made products become nightmares to manage, that's when they become the go to "solution" and start to shine. Modern day web development has a lot of pitfalls and will require a skillset that not everyone has. Not everyone can make dynamic apps that don't get bogged down by limiting factors like the DOM tree (cluster fuck), rendering/paint (bottle-necks), and single threaded environments (the async data gotcha's). Frameworks can help with all this, but it's at a cost. The file size is bigger, it's not Free Software, it uses JS and you have the potential to be caught-up in a CMS trap.
> Well progressive enhancement is not, not using JS. Progressive Enhancement is pretty much the opposite of Graceful Degradation.
> So, graceful degradation is the practice of building your web functionality so that it provides a certain level of user experience in more modern browsers, but it will also degrade gracefully to a lower level of user in experience in older browsers. This lower level is not as nice to use for your site visitors, but it does still provide them with the basic functionality that they came to your site to use; things do not break for them.
If it is assumed that voting is part of the basic functionality of HN, then HN does PE wrong by breaking it when there's no JS. It's a relatively recent change to HN and Anarki doesn't suffer from that issue.
Yet it's neat that HN uses JS to prevent page reloading on voting. I'm just doing no JS at all on my own project here to make sure I don't accidentally rely on it, because I don't really trust myself to use it in moderation.
> Frameworks can help with all this, but it's at a cost. The file size is bigger,
Yea, they're beneficial, but heavy. HN front page: 62K. HN search: 1.19M. Did they really need Angular for that search input form? That's where ClojureScript looks promising though: Their `helloworld` example is just 20K.
Obviously you're more into graceful degradation than progressive enhancement.
My idea of graceful degradation is falling back to a message that says "sorry, not going to happen!" :)
So, obviously, I'm more into progressive enhancement than graceful degradation.
> ClojureScript looks promising though...
Well to be fair, ClojureScript is not a full fledged framework; It is a framework, but really it's more of a compiler with some library functions. Reagent , for example, is a library that bridges the gap between ClojureScript and React. So I'm not sure it's fair to compare ClojureScript to these full fledged frameworks... you're still correct though, in that ClojureScript alone can produce apps with a smaller footprint.
That said & just to compare, last time I checked, React and Elm are appx. 42-45kb, Angular is 90kb. So HN search, obviously need to add their own code to bring it in at 1.19M.
My app, written in pure Clojurescript, is currently at 90kb minified. I hope to bring that down, but chances are the first release will actually be a little larger.
> What parts/features do you want to take from each, and why do you think they should coexist in a single product?
DropBox/WeTransfer/Google Drive/OneDrive is just what people use to send larger files. I'm not a fan of those sites, but I have observed that people I know find Filezilla and FTP very intimidating. There's some other free apps for this, but either they're in PHP or they're too complicated to install or use or hack on. Droopy works good for this, so as a start I just cloned what Droopy does; just to check whether Racket/SQLite is fast enough for this use case. (It is)
I like RSS as an idea and the fact that most sites have RSS feeds, but I think it's underappreciated by non-techies, who think that Facebook or Twitter are the only place you can "follow" stuff. For friends of mine to even consider using RSS for anything, I think it needs to be more accessible. I use Newsbeuter for reading RSS but I would never recommend it to non-techie friends, and it has some annoying bugs: Sometimes text is missing, podcast download is flaky at best so I have to copy the url out at get it with curl, and the interface becomes unresponsive when there's many feed items. So I'm thinking of giving it a try to make a web-based RSS reader that encourages sharing and that at very least I'd enjoy using myself. I think this would fit naturally with a News-style app, basically just having RSS feed items being shown alongside other people's posts, but perhaps tweaking the ranking in a way that external feeds don't overshadow local content (assuming that external feed items are votable). Some non-techies have shown me the Feedly app, which (I think) uses RSS, and (I presume) has some kind of social recommendation system, so I just think it would be nice with a free/libre web app doing something similar.
Then, the HN/Lobsters part is basically about having a minimalist web forum with tree structure replies and well thought out ranking algorithms and spam handling, instead of this thoughtless phpBB-style newest-first unstructured mess. One thing Lobsters does right here is that it notifies you when someone replies to a comment of yours. On HN it's possible for someone to reply and you just won't notice because it's so deeply buried in old threads. But I like all the different ways you can sort/view the content on HN.
Also, I've had some painful episodes trying to back up Wordpress sites. It's not pleasant, because there's little distinction between code and content which is stored in a mish-mash of database entries and folders. WP barfs all over the disk. That's something HN does right, because all the content is in the `www` folder. But, then file upload to HN is not really a realistic thing.
So I'm just trying to mix-and-match things I like from different software. A lot of ideas. Haven't gotten far yet! But I guess it's ok to share work-in-progress here.
If I didn't have dockerphobia and mild JS-intolerance, I'd probably just be running Mastodon or something.
> 2. Are you building a file transfer service? Or are you imagining that people will want to share files on a HN-like website? I'm not sure why that would be a common use case.
File upload wouldn't make sense on HN, Arc Forum or Lobsters, and I get that it's entirely on purpose that it's not present on those sites.
But I've been hosting a News site, and those of my friends who use it often submit links to something they've put on Dropbox or Google Drive, so I'm simply observing that this use case is present and that file upload is missing on my site. Perhaps it's because it's a different type of exchanges: a guitarist uploading a recording of a Charlie Parker solo, an artist uploading a drawing, etc.
Well, perhaps I should be using $CRAPPY_PHP_CMS_WITH_FILE_UPLOAD instead of News, but why can't I have well-structured content and file uploads at the same time?
It's also about future extensibility, ways of presenting these file uploads that I haven't thought about yet. I do occasionally write PHP for money. I don't have a very high opinion of that language, and I'd rather make something from scratch in Racket than write it as a Drupal plugin. Given the relative quantities of Drupal plugins and Racket web apps, that might be an unpopular opinion, but it shouldn't seem too strange on this forum. I'd prefer to make custom interactive web sites by extending a code base in Racket rather than PHP.
It's actually also for the use-case of being off-the-grid, yet needing to send/receive files to people in the same room, but not being able to find a USB stick. That situation happens surprisingly often for me. A zero-config web app is useful here because everyone have a browser on their computer (whereas not everyone have FTP / SSH / SMB).
> 1. Are you trying to build an RSS reader? Or do you want to support RSS versions of pages on your site?
I plan to do both. Building a social RSS reader integrated in a News-like app. And this News-like app would provide RSS feeds in the same way Anarki does. I image it wouldn't be too difficult.