5 ms·

I think that the main argument presented in this blog -- "avoiding splitting" is wrong :Splitting the development into frontend and backend is essential for de

I think that the main argument presented in this blog -- "avoiding splitting" is wrong :Splitting the development into frontend and backend is essential for developing maintainable code for large projects. Having a well defined communication api between backed and frontend defines responsibility for front end and backend developers and also enable better (j)unit test cases. The communication overhead and associated documentation is beneficial in the long run as the code that is produced will be better understood by all , not just the lone developer; it also makes code reviews easier and allows new developers to take over existing code base when necessary. It is immature to think developers will only feel pride in their when they own the entire codebase, the ui-to-db stack; The idea that "Lovingly crafted aesthetics in a codebase is key" is silly; code needs to be testable, well documented and highly optimized and re-usable.The "jostling of positions" are design discussions and they are important part of the software development cycle. I like Clojure and I am interested in learning ClojureScript but this blog post makes a poor case for it.

rubiquity 11y ago
Agreed. The client-server abstraction is one of the very best in the history of computing. I don't know why so many people are trying to do away with it.
- jeremiep 11y ago
  The article doesn't mention doing away with client-server architectures but rather the separation of frontend and backend programmers which is indeed very harmful.
  - rubiquity 11y ago
    I think trying to write your apps in this way hides the underlying client-server architecture.
    - reitzensteinm 11y ago
      I've written a clj/cljs app with source sharing, and there are many downsides. Tooling, lack of progressive enhancement, debugging, download sizes. I feel the benefits are worth it for my use case, but it's not all roses. But hiding the client server architecture is just a bizarre criticism to me, because it's not at all what writing one of these projects is like, and I'm not sure how you're even getting that impression. The degree to which you share code depends on how much functionality you are replicating, and is code that you would literally be cut paste porting if you were using another toolset. Or just avoiding writing altogether, like speculative updates. Just because you can theoretically attempt an antipattern doesn't make a tool bad; you can write shit in any language. And many do.
- woah 11y ago
  It's not an abstraction, it's an accidental byproduct of physical hardware placement.
  - rapind 11y ago
    Client server is about having more than one consumer that needs to share and mutate the same data. In other words, collaboration. In general the pattern doesn't care where the hardware is located. Remote hardware just accentuates issues that are only obvious due to high latency. A local system for example could get away with a less sophisticated locking mechanism... until it doesn't.
warfangle 11y ago
Having a well defined and documented API is not an artifact of splitting development roles between front and back end. There are many, many projects out there with split roles that have terribly defined and ill-documented server interfaces. It's an artifact of having competent developers, be they full stack or not.
bryanlarsen 11y ago
Sure, any large code base needs to be modular, but why impose an arbitrary split? We've got a large Node.js codebase. Some of the code runs only on the server, some runs only on the client, but the majority runs on both. Our code is split into modules for functional reasons.
- manishsharan 11y ago
  The split between backend and frontend is not arbitrary; it is based on client-server paradigm and it has worked well.
  - jeremiep 11y ago
    They're talking about the split of programmers, not of concerns. The client-server model is definitely here to stay but having separate groups of people handling each side is a sure way to greatly lower the quality of the product.
    - jbergens 11y ago
      You mean that one needs competent developers? That is nothing new. At least a few of the developers should now both languages and sides.
  - javajosh 11y ago
    I'm not sure why you're getting downvoted, because you're right. To be more specific, server code has very different responsibilities than client code, not to mention very different runtime characteristics (e.g. servers are both trusted and under total central control, unlike clients). To say that the client/server split is "arbitrary" is rather silly. (That's not to say I'm not a fan of an end-to-end language. Meteor shows what you can do with this. Maybe ClojureScript can do this, but with a better language.)
    - bryanlarsen 11y ago
      We have lots of code that runs on both the server and the client. It has the same responsibility whether it's run on the server or the client.
bryanlarsen 11y ago
Splitting teams along the API boundary is a sure way to get crappy API's. To get good API's you need to dogfood the API. In other words the team that writes the server side should be writing at least one of the clients consuming the API.
- tracker1 11y ago
  I'll go a step farther... the consuming API client should be in a different language/idiom than the server-side implementation (assuming multiple languages are going to be used in your environment). Too often I try to access Java or PHP web services from .Net, where the tooling is very strict, and it just falls apart. Or I'll have to use something via JS that is just excessively painful to use in practice for no good reason. I've also seen time and again layers of indirection or other design patterns used without any consideration of why they are being used in that instance. You don't have to hide your data tier behind factories of repositories. You don't have to make everything an interface. If you aren't going to test anyway, make the code as simple as possible. I tend to favor only adding complexity if it makes those complicated pieces easier to use in practice, and even then not all the time. Sorry for the rant, I just see time and again certain levels of complexity without flexibility or consideration for why.
  - tiwazz 11y ago
    > Too often I try to access Java or PHP web services from .Net, where the tooling is very strict, and it just falls apart. Or I'll have to use something via JS that is just excessively painful to use in practice for no good reason. On the other hand trying to use anything from .NET land that implements WS-Security from PHP or Java is also exceedingly painful. I recently had to integrate very similar APIs from 5 different companies into an internal application... One used an HTTP(s) REST API written in PHP, it used mod_auth and I was done in 30 minutes. One used SOAP with some custom extensions, I hacked around a bit with the PHP SOAP classes and was done in a few hours. One used WS-Security, and after a few days of hacking around I ended up using Netbeans' tooling to generate a Java client that could consume the service and forward the results to PHP. Another used a (more recent) version of WS-Security and the same trick wouldn't work, so I contacted their support who admirably tried to create a java client to consume the service, gave up, and created a regular SOAP bridge for us to use. One company is still trying to get our AD credentials set up with their vendor software that uses Biztalk somehow (they've been scarce on the details) after two months of waiting. RESTful services in PHP and Java may not have a pretty GUI configuration tool, but they are much simpler to get working than SOAP and any of the MS extensions in my experience.
qzcx 11y ago
The one thing that I don't understand about his argument is why having dedicated QA is bad? Having QA doesn't mean you shouldn't test your own code, but you have blind spots when it comes to testing your own code. It is easy to make assumptions about how your code should work.
- pbowyer 11y ago
  The post has a good core, but is wrapped in opinions like this which detract. I agree with you entirely: I produce my best code when I test everything, and then someone else tests and discovers the parts I excluded from 'everything'.
bad_user 11y ago
That's a nice myth, however in practice what happens is exactly the opposite, mostly because people lose sight of the whole picture and end up super specialized on small pieces of the puzzle. This is what happens in corporations, where the whole reason for why projects succeed is because of the invested resources, work still being done on the model of the Egyptian pyramids, with thousands pushing large bricks. There's a reason for why micro-services that don't start as a monolith are failing - people have this impression that micro-services are imposing clearer boundaries, which is of course wrong.
- imsofuture 11y ago
  The danger of having people who aren't specialized is just as great as the danger of having people too specialized. Backend and frontend concerns are completely different, and it's fiction that you can simply wave those concerns aside and write the same sort of software anywhere in your stack.
  - bad_user 11y ago
    I disagree and I think that treating the frontend and backend as different concerns is one cause for the big balls of mud we end up with. For example, many treat the backend as if it doesn't require design or taste for good user experience and many treat the frontend as if it doesn't require solid engineering. They are wrong of course.
manishsharan 11y ago
(apologies for replying to my own comment, but I want to highlight some reasons by division of labour between backend and frontend development work is important). Typically, backend developers need to have specialized knowledge of the enterprise security system which needs to be invokoked for authorization requests. Also the backend developers need to worry about availability/clustering issues. They also have to be familiar with caching subsystems in place , observe or predict the api requests patternt and implement caching strategies. They have to deal with a 'different scale' of concurrency issues than normal ui devs. The there is the issue of api versioning: there will be clients/user who will not upgrade and the backend development team has to figure how to support multiple versions of the same API. Then there is the issue of deployment and packaging: not every development shop lets developer push deployment into directly into production.Then there is the issue of database queries : you will have to optimize those heavily in consultation with your database admin. If you are using JVM, you have to optimize that for your application. The frontend development work has its own set of equally vexing challenges. There is no doubt that any competent developer can handle all these tasks but it won't be the kumbaya singing utopian happy habitable code paradise that this blogger is seeking. Division of labor between backend and frontend is a life saver for developers. I would actually want to go home and not spend my life in this "habitable" place.
- jbergens 11y ago
  I agree that there things work differently on the server and on the client but the lines are getting blurred. For example, you might not need api versioning if you only write a SPA application, there is usually some caching on the client also and it seems to increase, the concurrency problems are starting to show up in the clients (promises and callback hell) and sometimes you want to duplicate a lot of the security things to the client to give faster feedback and a more dynamic gui. Database queries are probably mostly done on the backend but there might be queries in some rest format in the client that are sent to the server and there might be IndexedDb queries instead.
mikerichards 11y ago
You're right, but current agile dogma frowns on that. I think a lot of us like being a "full stack" developer too. It's part of our ego that we like going from our procs to the css
jimbokun 11y ago
I think Clojure owes much of its success to the acceptance of using multiple languages in the same project. Maybe breaking off a small piece of functionality in a Java project to try implementing in Clojure. Maybe implementing a service with a REST API in Clojure accessed from clients written in other languages. So I find it a little ironic, and maybe short sighted, to hear "write everything in one language" used as an argument for using Clojurescript.
- jbergens 11y ago
  I agree, if the one language idea really starts to be followed everywhere it is probably javascript that will win. There is almost nothing in this article explaining why clojurescript is or could be a better choice.
deleted 11y ago
[deleted]

rubiquity 11y ago

Agreed. The client-server abstraction is one of the very best in the history of computing. I don't know why so many people are trying to do away with it.

jeremiep 11y ago
The article doesn't mention doing away with client-server architectures but rather the separation of frontend and backend programmers which is indeed very harmful.
- rubiquity 11y ago
  I think trying to write your apps in this way hides the underlying client-server architecture.
  - reitzensteinm 11y ago
    I've written a clj/cljs app with source sharing, and there are many downsides. Tooling, lack of progressive enhancement, debugging, download sizes. I feel the benefits are worth it for my use case, but it's not all roses. But hiding the client server architecture is just a bizarre criticism to me, because it's not at all what writing one of these projects is like, and I'm not sure how you're even getting that impression. The degree to which you share code depends on how much functionality you are replicating, and is code that you would literally be cut paste porting if you were using another toolset. Or just avoiding writing altogether, like speculative updates. Just because you can theoretically attempt an antipattern doesn't make a tool bad; you can write shit in any language. And many do.
woah 11y ago
It's not an abstraction, it's an accidental byproduct of physical hardware placement.
- rapind 11y ago
  Client server is about having more than one consumer that needs to share and mutate the same data. In other words, collaboration. In general the pattern doesn't care where the hardware is located. Remote hardware just accentuates issues that are only obvious due to high latency. A local system for example could get away with a less sophisticated locking mechanism... until it doesn't.

warfangle 11y ago

Having a well defined and documented API is not an artifact of splitting development roles between front and back end. There are many, many projects out there with split roles that have terribly defined and ill-documented server interfaces. It's an artifact of having competent developers, be they full stack or not.

bryanlarsen 11y ago

Sure, any large code base needs to be modular, but why impose an arbitrary split? We've got a large Node.js codebase. Some of the code runs only on the server, some runs only on the client, but the majority runs on both. Our code is split into modules for functional reasons.

manishsharan 11y ago
The split between backend and frontend is not arbitrary; it is based on client-server paradigm and it has worked well.
- jeremiep 11y ago
  They're talking about the split of programmers, not of concerns. The client-server model is definitely here to stay but having separate groups of people handling each side is a sure way to greatly lower the quality of the product.
  - jbergens 11y ago
    You mean that one needs competent developers? That is nothing new. At least a few of the developers should now both languages and sides.
- javajosh 11y ago
  I'm not sure why you're getting downvoted, because you're right. To be more specific, server code has very different responsibilities than client code, not to mention very different runtime characteristics (e.g. servers are both trusted and under total central control, unlike clients). To say that the client/server split is "arbitrary" is rather silly. (That's not to say I'm not a fan of an end-to-end language. Meteor shows what you can do with this. Maybe ClojureScript can do this, but with a better language.)
  - bryanlarsen 11y ago
    We have lots of code that runs on both the server and the client. It has the same responsibility whether it's run on the server or the client.

bryanlarsen 11y ago

Splitting teams along the API boundary is a sure way to get crappy API's. To get good API's you need to dogfood the API. In other words the team that writes the server side should be writing at least one of the clients consuming the API.

tracker1 11y ago
I'll go a step farther... the consuming API client should be in a different language/idiom than the server-side implementation (assuming multiple languages are going to be used in your environment). Too often I try to access Java or PHP web services from .Net, where the tooling is very strict, and it just falls apart. Or I'll have to use something via JS that is just excessively painful to use in practice for no good reason. I've also seen time and again layers of indirection or other design patterns used without any consideration of why they are being used in that instance. You don't have to hide your data tier behind factories of repositories. You don't have to make everything an interface. If you aren't going to test anyway, make the code as simple as possible. I tend to favor only adding complexity if it makes those complicated pieces easier to use in practice, and even then not all the time. Sorry for the rant, I just see time and again certain levels of complexity without flexibility or consideration for why.
- tiwazz 11y ago
  > Too often I try to access Java or PHP web services from .Net, where the tooling is very strict, and it just falls apart. Or I'll have to use something via JS that is just excessively painful to use in practice for no good reason. On the other hand trying to use anything from .NET land that implements WS-Security from PHP or Java is also exceedingly painful. I recently had to integrate very similar APIs from 5 different companies into an internal application... One used an HTTP(s) REST API written in PHP, it used mod_auth and I was done in 30 minutes. One used SOAP with some custom extensions, I hacked around a bit with the PHP SOAP classes and was done in a few hours. One used WS-Security, and after a few days of hacking around I ended up using Netbeans' tooling to generate a Java client that could consume the service and forward the results to PHP. Another used a (more recent) version of WS-Security and the same trick wouldn't work, so I contacted their support who admirably tried to create a java client to consume the service, gave up, and created a regular SOAP bridge for us to use. One company is still trying to get our AD credentials set up with their vendor software that uses Biztalk somehow (they've been scarce on the details) after two months of waiting. RESTful services in PHP and Java may not have a pretty GUI configuration tool, but they are much simpler to get working than SOAP and any of the MS extensions in my experience.

qzcx 11y ago

The one thing that I don't understand about his argument is why having dedicated QA is bad? Having QA doesn't mean you shouldn't test your own code, but you have blind spots when it comes to testing your own code. It is easy to make assumptions about how your code should work.

pbowyer 11y ago
The post has a good core, but is wrapped in opinions like this which detract. I agree with you entirely: I produce my best code when I test everything, and then someone else tests and discovers the parts I excluded from 'everything'.

bad_user 11y ago

That's a nice myth, however in practice what happens is exactly the opposite, mostly because people lose sight of the whole picture and end up super specialized on small pieces of the puzzle. This is what happens in corporations, where the whole reason for why projects succeed is because of the invested resources, work still being done on the model of the Egyptian pyramids, with thousands pushing large bricks. There's a reason for why micro-services that don't start as a monolith are failing - people have this impression that micro-services are imposing clearer boundaries, which is of course wrong.

imsofuture 11y ago
The danger of having people who aren't specialized is just as great as the danger of having people too specialized. Backend and frontend concerns are completely different, and it's fiction that you can simply wave those concerns aside and write the same sort of software anywhere in your stack.
- bad_user 11y ago
  I disagree and I think that treating the frontend and backend as different concerns is one cause for the big balls of mud we end up with. For example, many treat the backend as if it doesn't require design or taste for good user experience and many treat the frontend as if it doesn't require solid engineering. They are wrong of course.

manishsharan 11y ago

(apologies for replying to my own comment, but I want to highlight some reasons by division of labour between backend and frontend development work is important). Typically, backend developers need to have specialized knowledge of the enterprise security system which needs to be invokoked for authorization requests. Also the backend developers need to worry about availability/clustering issues. They also have to be familiar with caching subsystems in place , observe or predict the api requests patternt and implement caching strategies. They have to deal with a 'different scale' of concurrency issues than normal ui devs. The there is the issue of api versioning: there will be clients/user who will not upgrade and the backend development team has to figure how to support multiple versions of the same API. Then there is the issue of deployment and packaging: not every development shop lets developer push deployment into directly into production.Then there is the issue of database queries : you will have to optimize those heavily in consultation with your database admin. If you are using JVM, you have to optimize that for your application. The frontend development work has its own set of equally vexing challenges. There is no doubt that any competent developer can handle all these tasks but it won't be the kumbaya singing utopian happy habitable code paradise that this blogger is seeking. Division of labor between backend and frontend is a life saver for developers. I would actually want to go home and not spend my life in this "habitable" place.

jbergens 11y ago
I agree that there things work differently on the server and on the client but the lines are getting blurred. For example, you might not need api versioning if you only write a SPA application, there is usually some caching on the client also and it seems to increase, the concurrency problems are starting to show up in the clients (promises and callback hell) and sometimes you want to duplicate a lot of the security things to the client to give faster feedback and a more dynamic gui. Database queries are probably mostly done on the backend but there might be queries in some rest format in the client that are sent to the server and there might be IndexedDb queries instead.

mikerichards 11y ago

You're right, but current agile dogma frowns on that. I think a lot of us like being a "full stack" developer too. It's part of our ego that we like going from our procs to the css

jimbokun 11y ago

I think Clojure owes much of its success to the acceptance of using multiple languages in the same project. Maybe breaking off a small piece of functionality in a Java project to try implementing in Clojure. Maybe implementing a service with a REST API in Clojure accessed from clients written in other languages. So I find it a little ironic, and maybe short sighted, to hear "write everything in one language" used as an argument for using Clojurescript.

jbergens 11y ago
I agree, if the one language idea really starts to be followed everywhere it is probably javascript that will win. There is almost nothing in this article explaining why clojurescript is or could be a better choice.

deleted 11y ago

[deleted]