[mrinterweb]

By what I've seen I like the spirit of Lotus, but I sense a movement away from complete web frameworks to pure API back-ends with the emergence of great single page JS frameworks like Ember. One ruby one that I like is https://intridea.github.io/grape/. One interesting node API framework I mean to try is http://loopback.io/.

[fuadksd]

That's a trend indeed (and personally I like it pretty much).

But lotus has a view component that allows you to do stuff """just like rails""" (many quotes intended). That's the beauty of it: it's modular and not opinionated, so you can pick an mix the tools you want to compose in order to suffice your needs.

[awj]

Yeah, lotus looks like it could do a good job at letting you share/extend models and other bits of code between a Rails-like html server and a pure api server. Maybe those two things are the same server, different modules in the same server, or different servers sharing libraries. Choice is up to you since lotus looks like it can cleanly do both.

[shime]

Yes, I also think that the future of backend development is micro services communicating over defined HTTP API endpoints or other message protocols.

If you look closely, rendering presentation layer on the server side and then sending it to the client is a hack and we've been doing it for a long time. It's time for changes.

[Smudge]

> If you look closely, rendering presentation layer on the server side and then sending it to the client is a hack and we've been doing it for a long time. It's time for changes.

From the view/presentation layer's perspective, it shouldn't matter where the rendering happens, and as a programmer working on these systems I'm tired of baking assumptions about the data layer into the view layer.

I actually think there's a best-of-both-worlds solution that we'll converge on at some point, which is this:

We have the option of rendering in both locations with the same code.

This allows the initial render to be offloaded to the server (so that the app's initial state is totally established and can be sent along with the app itself in a single HTTP request), and then subsequent rendering updates could happen mostly client-side (fetching only the raw data from the server where necessary).

This allows the JS-everywhere crowd to build their entire app as if all logic is running in-browser (with only a basic API on the server), but it appeases the more old-fashioned developers who want to be able to construct mappings between URLs and actual HTML documents (that don't have to be spun up and re-constructed using client-side scripting). There's obviously a huge debate here as to whether or not the latter is worth it, but I'd say it would be nice if only so that I don't need to have a flash of unloaded content or a "loading" indicator before the app is ready to be used.

I also don't like having to use PhantomJS to scrape data from a website that could very easily consist of HTML documents instead of a blob of JS, but that's probably not enough to affect most people's opinions.

[h1karu]

Single page web apps are broken for a lot of the most important purposes that the worlds largest and most important web-apps need to fulfill. For example how could Wikipedia function as a single page app since it wouldn't be consumable by screen readers and robots of various shapes and sizes ? That's just one example, but there are many. What about the semantic web ? microformats anyone ?

Google isn't the only search engine out there so the fact that you can use a crutch to let google crawl your site doesn't fix the problem.

https://en.wikipedia.org/wiki/Semantic_Web http://www.w3.org/standards/semanticweb/

[joevandyk]

You could easily use Lotus as an API server.