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.
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.
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.
That said, I've never really been a fan of SOAP in general, and WS-(death)* is painful in any system. Funny enough, I've found node.js to be the easiest middle-man to coerce into using different services as a gateway, and it's my go-to when a wsdl doesn't import cleanly into a .Net project, and just define my own JSON/REST interface in front of the foreign services for the parts I need.
AD integration is particularly painful, and pretty much only works in IIS, in that case, I'd lean towards writing a shim in ASP.Net MVC exposing JSON endpoints, in a similar fashion.
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.
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.
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.)
Which is very reasonable, btw, as it allows you to have a static site that renders for those whoes browsers doesn't run javascript and a more dynamic page for those whoes browser does run Javascript. You are guaranteed that everything renders the same way only if you excecute the same code (this can't be replaced by e.g a sensible template system because rendering might also be affected by how you, e.g, sort comments).
What does this mean exactly? What kind of code needs to run on both?
You can optionally choose to include Meteor methods (ajax-style remote endpoints) on the client. Then when the method is called, the client-side version is run in addition to the real, server-side one being kicked off. If the server-side returns an error, such as due to insufficient permissions, the changes made client-side are rolled back. Combined with Meteor's client-side mongo implementation and reactive UI updates, it gives impressive "perceived performance" benefits.
A simple one is validation of forms, but also doing rapid UI updates without having to do network round-trips.
validation
routing
modular business logic e.g. - calculate total interest paid over the life of the loan provided the client pays x per month etc etc
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.
It's an artifact of having competent developers, be they full stack or not.
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.
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.
I like Clojure and I am interested in learning ClojureScript but this blog post makes a poor case for it.