Earlier quoted context omitted.
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 progressiv…
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 WhateverT…
Show HN: Open-source StackOverflow-like service
41–50 of 51 posts
Re: Show HN: Open-source StackOverflow-like service
#42Earlier quoted context omitted.
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.
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.
Re: Show HN: Open-source StackOverflow-like service
#43Askbot ( 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.
Re: Show HN: Open-source StackOverflow-like service
#44Askbot ( 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.
Re: Show HN: Open-source StackOverflow-like service
#45Kudos 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.
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?
Re: Show HN: Open-source StackOverflow-like service
#46Kudos 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.
It's terrible indeed, and it works only if javascript is enabled.
Re: Show HN: Open-source StackOverflow-like service
#47Earlier quoted context omitted.
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 serv…
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.
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.
Re: Show HN: Open-source StackOverflow-like service
#48Earlier quoted context omitted.
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 serv…
> 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.
Re: Show HN: Open-source StackOverflow-like service
#49Do you even know that this is invalid and the proper tag is called just ? Do you know that 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?
Re: Show HN: Open-source StackOverflow-like service
#50The 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.