Hacker News new | ask | show | jobs
by rwalle 1025 days ago
> single language applications are single build applications

I don't know your background but most teams don't view "single language" as an advantage over other options. People choose a certain language because of internal infrastructure, libraries/ecosystem, performance, and whether it is the best suited for a project etc, rarely because "we use that language for backend so we should also use it for frontend" or vice versa
2 comments
bob1029 1025 days ago
> I don't know your background but most teams don't view "single language" as an advantage over other options.

We view it as a massive advantage, assuming we are on the same page with "single language, plus HTML/CSS/JS"

Our language is C#. Our web "framework" consists of the string interpolation and verbatim operators. Most of our views take the form of:

  var finalHtmlResponse = @$"
    <html>
     {DiyPHPViewEngineRabbitHoleEntrance(httpRequestContext)}
    </html>";
I actually tried using the cshtml/razor engines because it seemed "more proper" but after 2 days of dependency hell I decided to go back to raw string interpolation. If you are able to build a functional website using static sources and have the barest capability to compose functions and strings, I do not see why this path would provoke any serious anxiety (other than it not being popular).

Imagine being able to directly invoke some utility or other backend method from your HTML view source pipeline. If you write it all in the same language, this becomes feasible. The moment principal rendering is outsourced to the client (or some other language), you are talking about a JSON API + distributed state circus and all the hell that must go along with it.

link
flimsypremise 1025 days ago
I mean, JS is a language, so this would not really qualify. I have to wonder how you expose the state of your C# app to the JS when that needs to happen. Perhaps... with JSON? In which case you are just doing JSON API + distributed state, except in a more complicated way with C# thrown in for good measure. You could simply render your DOM in JS/TS on the backend and save yourself a step. Hell if you are really that opposed to writing JSON APIs, you can just write a Node app that queries the database directly. I don't really recommend doing this since I think exposing data via APIs is good, but whatever floats your boat.

Either way, at some point your app is running JS/TS and CSS, and those two resources require some type of build process to manage beyond a certain degree of complexity. I lived through the hell of having to determine the load order of JS and CSS files by where the script and style tags occurred in the DOM. It was incredibly difficult to do simple things. Now we can do much more complicated things more easily, but language chauvinists object to doing complex things in what they view as "lightweight" languages. The thing is, the "correct" language to use is generally just the one that does the job best, and in this case JS/TS is specifically optimized for writing applications that interface with the DOM.

link
flimsypremise 1025 days ago
Not sure what you're really saying here. Teams often use languages because their existing codebases and the proficiencies of their existing members, but "we use that language for backend so we should use it for frontend" is totally a thing. You're somehow seeing multiple languages as an advantage when its actually a form of debt. Teams work in multiple languages because prior choices force them to, but if you can limit the number of languages and technologies in use it allows you to streamline and automate spinning up new services, make it easier to hire, and greatly simplifies deployment configuration. This is one of the major things that happen as you transition from an early stage to late stage as a startup. You hire professionals after a few years of not knowing what you're doing, and they cull all of the non-standard shit, lock in your architecture and languages, and then template our your apps, your configuration and your deployments.
link