A company I worked for in 2001 used chucked streaming to provide search results. The search results were collected by performing live searches in parallel (server side) with multiple partners and then aggregated into a single stream of chunked content. Basically the HTTP connection was kept open until all searches were complete, which would take a few minutes. The results were pushed incrementally to the browser as soon as they were available
This worked surprisingly well. They started with almost pure HTML with the results split into multiple tables to produce what looked like a single table of results. The only drawback was that the columns needed fixed width so that they would align properly.
After a while they switched to a Javascript based solution with dynamic filters. They used the same backend streaming engine to output chunks of Javascript code inside <script>-tags, which called a global "addResult(...)" method to update the state. If the search was cached, it would first render HTML code server side, which was then "hydrated" by the javascript code if needed.
Later it was replaced with a standard XHR polling mechanism.
It is interesting to look back at what we had to do that is trivial with today's technology.
Auto CrLf is a terrible thing that can change the meaning of programs. Source control shouldn't be changing the contents of files (though a hook to format wouldn't be bad necessarily).
Any language that allows string literals to wrap lines without normalizing it. Like C# or F#. Anything with HERE docs might do it, but Ruby and Python seem to normalize.
> If you use their vals IntelliJ will syntax highlight it as an error in red for the simple reason that it's non-compliant with the Java language spec.
There's a free plugin that adds Lombok support to Intellij. You will be able to use getters/setters/builders etc. as if they were compiled.
Builders etc. work fine, it's the vals that are permanently underlined in red, even with the plug in. It compiles OK with vals, but still highlights it as an error in red in the editor.
You recommended a Javascript library that was maintained for 8 years. I consider that a good recommendation. Backbone and Angular have only been around for half that (yet)
To put things in context. The oil industry is producing 20% of the total GDP of Norway and 50% of all exports. It's very important and it will be painful when it ends, but Norway will not be much worse than other European countries when the oil runs out.
This worked surprisingly well. They started with almost pure HTML with the results split into multiple tables to produce what looked like a single table of results. The only drawback was that the columns needed fixed width so that they would align properly.
After a while they switched to a Javascript based solution with dynamic filters. They used the same backend streaming engine to output chunks of Javascript code inside <script>-tags, which called a global "addResult(...)" method to update the state. If the search was cached, it would first render HTML code server side, which was then "hydrated" by the javascript code if needed.
Later it was replaced with a standard XHR polling mechanism.
It is interesting to look back at what we had to do that is trivial with today's technology.