Show HN: Open-source StackOverflow-like service | Hacker News Reader

Show HN: Open-source StackOverflow-like service

paizaqa.herokuapp.com

Kudos for effort, but for the life of me I cannot understand why the hell is "load empty shell of a page and then asynchronously fetch bits and pieces of content, ruining the UI along the way" is so prevalent these days.

I know how you feel. I live in Mexico now, and the internet connections in these parts are terrible. It's given me a whole new perspective after coming from cheap 100 mbit back home. Sometimes I get confused with pages like this, only to later realize that the main content wasn't loaded yet.

Can be fixed pretty easily with a "loading..." message, but I guess no ones going to fix something they don't know is broken (since the developer will be using fast internet)

That's how a basic angular.js app with client side templating works if it has to fetch the the data from the server using AJAX calls.

A common optimization would be to preload the served javascript with the initial AJAX results. This still means rendering the content on the client side, but the content isn't fetched asynchronously. Another optimization is to actually render all the DOM elements in advance on the server, and only use client side rendering for updates.

This, I assume, is all done because 99% of web sites are trivially done with server-side HTML generation and that is not hipstery enough.

It's not a matter of being "hipstery", the drawback is that each time you refresh the view you have to resend all the markup. You're increasing the total amount of data that's going back and forth between the browser and the server. By sending the markup once and then dynamically populating it you can have much faster transitions between objects that use the same view.

What you really want to do is provide progressive enhancement where the first thing a user sees is usable and then more features become available without disrupting whatever the user has started doing (e.g. don't reflow the page while they're trying to read or browse). One way to achieve this is rendering the initial view on the server side and then doing updates via AJAX request but this has meant writing your rendering code twice, once on the server side and once on the client side. This is a reason that node.js and isomorphic JavaScript in general have become so popular.

Oh give me a break.

> ...the drawback is that each time you refresh the view you have to resend all the markup. You're increasing the total amount of data that's going back and forth between the browser and the server.

For like 99.9% of applications this is a non-issue. For crying out loud, StackOverflow itself has been doing server-side rendering since day one and is still heaps and bounds more usable than WhateverTheHellIsTrendingOnHn.js-based single page isomorphic rich web applications.

It might be my age showing, but, while completely agreeing with you on "progressive enhancement all the way", I find that too freakin' much resources nowadays are spent doing and re-doing and re-inventing something that was working fine in the first place.

I completely agree. I settled on using sockets.io for the small pieces of my website that can benefit from the realtime aspect of Angular and friends. It's shocking how little code you need to make an awesome 'modern' website. All pages load in under 200ms on first load and I can mostly stick to what I know.

There's not a lot of love for server-side generated content in the start up community right now, but it makes things a lot easier most of the time.

And better.

"Server-side HTML generation"... literally each word in this phrase shows how bad things are now in 99% of websites and - what's even worse - we still have to somehow follow these things for some sucky search engine bots that still don't run JS (yandex and other crap).

Let's begin from the end: generation. With a proper presentation layer, we wouldn't have to generate anything. We have data (from the server and/or local in-browser storage) and presentation modules, and we just feed data right into these modules on demand.

Next: HTML. In an ideal situation, we wouldn't touch any raw HTML string at all. Presentation modules, in effect, are responsible for DOM rendering of the page parts they are in charge of. And proper partial rendering usually doesn't involve innerHTML and other raw hacks (well, maybe for quickly clearing element contents, it will do). No escaping hell and other "fun" things.

Next: server-side. Screw all the dogmatic rules that the presentation layer must run on a server. The server should be responsible for handling all non-view logic providing the API for the client to communicate with (from simple AJAX/REST to something more complex like WebSockets) and serving our scripts and assets as fast as possible with proper caching headers, that's all.

This model, if applied wisely, will just make everything easier. I'm in the process of writing an article on it. But as I see Angular in this stack, this particular implementation doesn't show any sign of wisdom. :) Kill the overkill and keep it simple, stupid.

> Another optimization is to actually render all the DOM elements in advance on the server, and only use client side rendering for updates.

Which is, you know, how the web is supposed to work.

Was. 15 years ago.

You can use ng-if="results" for your result div and this will only display the div only when the $scope.results have got the values from AJAX call

Isomorphic/universal React just about solves this. Taken all the way, you get the full UI and clickable navigation links before any javascript loads.

It's also a totally reasonable pattern to template the constant UI parts of the page in the backend (and not have to necessarily fetch user sessions in the frontend), and then just render the fun bits with React. The user isn't going to get a literal blank page this way. I think this is a pretty happy medium actually.

Or progressive enhancement.

Are you on GPRS? Cause the page loads fine even on 7Mbit 3G (HSPA).

The problem is it's still quite raw and full of demo-stuff. Not in the way it loads.

Although... yes, isn't Angular a bit overkill here?

It's terrible indeed, and it works only if javascript is enabled.

Why would anyone disable it these days?

And, how to make it is available here:

Building a QA web service in an hour - MEAN stack development(3)

http://engineering.paiza.io/entry/2016/03/10/115345

The article is missing what I think is one of the most important parts, and that's the reasoning behind using a MEAN stack instead of a more classic approach using a standard back-end language like Ruby, Perl or Python, because I honestly fail to see how this is easier than using a framework like Django or RoR.

Thank you for your feedback!

For me, the most important part is the language. I can use JavaScript for client side, server side, and database. There is no context switching related to language like Ruby, JavaScript, SQL. (And, the way of thinking related to that like asynchronous and synchronous.)

It is especially helpful for startup or prototyping where small team build everything.

Then you should definitely give a try to Meteor framework (https://www.meteor.com/). Using it, we have built and run a production-ready service + Android app for a local flower shop delivery-messengers in about 5 days.

Askbot (https://askbot.com) is also open source and you can create you QA forum "in a minute" (sic).

No seriously, the askbot guys have been for a long time on the field, great app.

they have there source code pretty well hidden, can't find any link to source on Home / Developers / Contact page. So they may no longer want it to be open source.

https://github.com/ASKBOT/askbot-devel askbot creators believe that if someone does not know to google askbot source code he shouldnt get the code :)

StackOverflow has already often served me but sometimes I think what we really need would be some place where some people fluent in languages/frameworks could showcase best practices/mini howtos giving a little bit more context.

More than half the questions I ask on there are not "How do I do something", but "How do I do something WELL"

I've been procrastinating a long time to write an article similar to this. I've been using the generator since v1.x.x. Nice write up!

I even wrote a rails console-like equivalent for the older version[1]. Didn't get time to write a new one though. Will be a good addition to the generator I think.

[1]: https://gist.github.com/manu29d/ced4a558abf2fa654bff

The problem isn't displaying the pages. It's the rating and asshole management system for the questions and replies. How does that work?

I think you mean "Q & A" and QA. QA = "Quality Assurance".

Thank you for pointing out! I just changed the article's "QA" to "Q&A". Now, the title is:

Building a Q&A web service in an hour - MEAN stack development(3) http://engineering.paiza.io/entry/2016/03/10/115345

I think you mean "and not QA" and not "and QA". :) But I agree, it should be "Q & A".

Isn't StackOverflow open source?

User content is under a free license (and dumps are provided), but the engine is proprietary.

There are a few alternatives: http://meta.stackexchange.com/a/37953

Originally their software was available as download to third parties (but without sources AFAIK), but it no longer is.

Not as far as I'm aware.

Technical improvements were only one part of what made SO great. If you want to compete with them, then you have to figure out how to prevent posts like this one from lasting more than 5 seconds on the site:

http://paizaqa.herokuapp.com/questions/show/56e1a5872c8dfa03...

we have osqa http://www.dzonesoftware.com/products/open-source-question-a...

Clicking "ask question" kills the browser back button... Beware!

Thank you for your pointing out ! I just fixed it by adding "$location.replace()".

Also, there was a issue on Social Login, I also fixed the issue.

Awesome! Cool concept btw

What's the real issue is:

Do you even know that this is invalid and the proper tag is called just <nav>? Do you know that <title> must not be empty in the initial page? Do you know that custom attributes must start with data- (not ng- or ui-)?

Did you even check your page with http://validator.w3.org?

Care to explain why this was downvoted?

I honestly don't understand how did the authors manage to make a skeleton (!) page not passing validation. Even <title> is empty when it must not be so.

Is it because of Angular? Well, if a framework forces you to write invalid HTML (tags, attributes, whatever), it sucks, no matter what.

I don't understand Ruby. Is there an easy guide for deploying to Heroku?

Reply on news.ycombinator.com