Hacker News Reader

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.

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.

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.

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.

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.

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

It's worth noting that you can mount very simple SOAP services in .Net (doesn't mean that people do)... WCF for example gives a lot of ways to mount your services together, or separately.

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.

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

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.

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.

The split between backend and frontend is not arbitrary; it is based on client-server paradigm and it has worked well.

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.

You mean that one needs competent developers? That is nothing new. At least a few of the developers should now both languages and sides.

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

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.

Can you provide some examples?

To oversimplify, if the user clicks on a button on our website, the app checks to see if the operation can be done client-side. If it can be done client side, it's done client side instantaneously. If it's too big to do client-side or requires access to resources that aren't available on the client, the app submits a job to the server, and shows the client a progress bar.

He is getting downvoted, and rightly so, because the person is replying to has clearly set up his system is such a way that some code runs on both the server and the client.

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

We're doing that too, but that's the boring part. That's just running client-side code on the server. It's still client-side code. You can do that in Rails too. See my other comment for more details.

If you are running client side code on the server you use a very different definition of client side code than most other people, which is bound to be confusing.

> but the majority runs on both

What does this mean exactly? What kind of code needs to run on both?

I tend to agree with you, but there are things that can/should run on both - validation of input for one. But I'd like to hear other things - I hear "use the same code on the server and client" all the time, but I haven't found a lot of use for that personally.

Another common example is something like a Markdown/BBCode parser.

Turning a reactive web application into a regular "web site" -- ie. allowing you to use the bulk of the application without Javascript enabled. Great for SEO, too, at least until Google gets Javascript execution further along (which it's certainly doing, and getting better every day).

Aside from things like general libraries (e.g. serializing/deserializing data to/from the client), anything you want to happen client-side that you don't trust the client for, you will need to re-run on server side.

A simple one is validation of forms, but also doing rapid UI updates without having to do network round-trips.

template rendering

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

The Meteor framework [1] uses this to good effect to support latency compensation.

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.

1. https://www.meteor.com/

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.

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

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.

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.

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.

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.

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.

I think trying to write your apps in this way hides the underlying client-server architecture.

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.

It's not an abstraction, it's an accidental byproduct of physical hardware placement.

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.

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