3 ms·

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 loo

by shime 12y ago

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.

h1karu 12y ago
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 https://en.wikipedia.org/wiki/Semantic_Web http://www.w3.org/standards/semanticweb/ http://www.w3.org/standards/semanticweb/
Smudge 12y ago
> 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.
scient 12y ago
I actually believe rendering the presentation layer on the server side is preferable as it first off is (at this date) cheaper and it also allows for much better control over the presentation. Sending static content to the client is imho much more desirable than doing any kind of logic on the client side, potentially introducing more vulnerabilities. I don't really get the whole hype about microservices and thick clients. Most use cases for microservices i've seen end up as a fragmented and hard-to-deploy collections of applications that benefit very little from the decoupling. Building out API based communications between apps instead of using an actual database leads to new and silly problems, especially related to transactional data and so on. I've yet to come across a convincing example of why splitting your average webapp into microservices is a good idea, or why using repository pattern for persistence allows you to write much better code. I think it doesn't matter which kind of framework or tools you are using, its up to you, the engineer, to write decoupled code in a way that you want. I think that a lot of engineers are not able to do that properly, and they are looking for tools or guidance that would somehow solve the problem for them (like the whole MongoDB and designing proper schemas thing was at some point).

by shime 12y ago

h1karu 12y ago

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 https://en.wikipedia.org/wiki/Semantic_Web http://www.w3.org/standards/semanticweb/ http://www.w3.org/standards/semanticweb/

Smudge 12y ago

> 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.

scient 12y ago

I actually believe rendering the presentation layer on the server side is preferable as it first off is (at this date) cheaper and it also allows for much better control over the presentation. Sending static content to the client is imho much more desirable than doing any kind of logic on the client side, potentially introducing more vulnerabilities. I don't really get the whole hype about microservices and thick clients. Most use cases for microservices i've seen end up as a fragmented and hard-to-deploy collections of applications that benefit very little from the decoupling. Building out API based communications between apps instead of using an actual database leads to new and silly problems, especially related to transactional data and so on. I've yet to come across a convincing example of why splitting your average webapp into microservices is a good idea, or why using repository pattern for persistence allows you to write much better code. I think it doesn't matter which kind of framework or tools you are using, its up to you, the engineer, to write decoupled code in a way that you want. I think that a lot of engineers are not able to do that properly, and they are looking for tools or guidance that would somehow solve the problem for them (like the whole MongoDB and designing proper schemas thing was at some point).