4 ms·

Some years ago I was interviewing for head of automation position, and in the process was asked how'd I go about making sure a Web admin interface (to a product

Some years ago I was interviewing for head of automation position, and in the process was asked how'd I go about making sure a Web admin interface (to a product that by and large doesn't need a Web interface, think, in the same category as Kubernetes) is well-tested. To which I responded that I'd not use any JavaScript. Ideally, XML with stylesheets. Very light-weight, renders extremely fast, and is extremely friendly to automation tools (doesn't even require a browser for most tests). For the kind of product this was intended for, and I still believe it to this day, it would've been perfect: nobody needs any CSS animations there or any kind of interaction beyond filling forms and submitting them. One of the interviewers was the head of the front-end department. He hadn't for a moment considered this to not be a joke, but pretended to answer this seriously by explaining that if they don't put a fashionable JavaScript framework into job description, they will not be able to hire front-end programmers. In reality, there are plenty of things on the Web that could, in principle, be just HTML or, as in my example, XML + stylesheet, but won't be for no reason other than to feed the echochamber of the job market. Nevermind that from the business side this makes user experience worse, costs more to host and to maintain, and yet...

webdood90 4y ago
you can't get anything done if nobody wants to do the work
- ozim 4y ago
  I see you got downvoted but people don’t get that choice of technology based on who you can hire is a valid point. I remember a guy who wanted to make company documentation in LaTeX. Well yes it is great tool and we could put it in a git repo and render nice documents for the customers easily. Downside was 15-20 sales people who were not thrilled to use it and spend time learning how to use it.
  - PaulHoule 4y ago
    I think a lot of devs are frustrated with the state of modern Javascript. As I speak I am waiting for "mvn install" to run for a system that has a Java back end and a Javascript front end which compiles both. I think the Java part would finish in about 20 seconds, the Javascript bit is more like 250 seconds. There would be 250 seconds of working instead of posting to HN if the system was "100% pure Java". (To be fair I am mostly depending on an incremental build and I'd say Java turns around in 2s, Javascript in about 20s. One of those breaks my chain of thought, the other doesn't.)
    - holoduke 4y ago
      I never understood why you would need to compile frontend javascript code. Yea maybe a minimizer, obfuscator, some coping etc during a build process. But thats it. My frontend apps are running on the fly. Change in code requires a save and browser refresh. No ammoying compiling .
      - NeveHanter 4y ago
        Well, there're things like React's JSX, CoffeeScript, TypeScript and all of the fricking Babel stuff, all require some kind of transpiling (or how babel names it, compiling), and probably that is what OP means. PS: Luckily, I'm not a frontend dev :)
  - crabbone 4y ago
    Hey, I work in a company where user-facing documentation is written in LaTeX! I even contributed few commits to it. I'm not sure though why sales people would need to edit it. My discontent with LaTeX for documentation is that searching it sucks. I mean, you do get literal search for words, but if you want something smarter... PDFs don't interact well with searching tools we have. Another problem: interactive scroll. In HTML documents you can scroll sections of documents independently of each other (if you need to), so you can create ad hoc views of your documentation that could be more useful to you (eg. collapse a bunch of tables or code listings just to see the text in between). On the other hand, if you want to print it, oh man... it's going to look so much better! :)
    - ozim 4y ago
      It is also a bit of a point of my post. "Why sales people would need to edit it?" Because there were no dedicated people writing documentation, there were developers and sales people - that was it. Non technical documentation so "how to use the system" was going to be written by sales people. Lots of times in a company you work with what you have and finding and hiring "technical writer who has experience or wants to work with LaTeX" I would count as hard task.
      - crabbone 4y ago
        I used to be on good terms with a technical writer from a company I worked for some time ago. He later became one of the very few people who were let go as a result of a merger. Also, from what I can tell, technical writer isn't a cushy job, not anywhere near even entry-level programming jobs. Also, it's usually at companies with existing and large user-base, relatively large companies... there's not a lot of jobs on the market. I mean, I have a feeling that if a company asked a technical writer to learn LaTeX, they would probably do it, even on their own time. It's a tough market, and learning LaTeX enough to produce something isn't a huge effort (also, there are a bunch of tools that prepare the boilerplate code for documents). But I can see how sales people might not have been impressed by such prospects.
mikrl 4y ago
No one wants to write html_page.html, but html_page.js?? Now you’re talking.
- hotbeanwater 4y ago
  Okay hear me out: html_page_analytics.js html_page_bundle.min.js html_page_tracking.js html_page_d8fd766d76223ae.min.js html_page_user.js html_page_banners.js html_page_pardot_dfa7s778d9aa.min.js
  - aloisdg 4y ago
    This should be put into a resume.
bob1029 4y ago
> if they don't put a fashionable JavaScript framework into job description, they will not be able to hire front-end programmers. This is exactly why we are vague with tech stack in our job reqs. Why would you want talent that is laser-focused on specific keywords? What is the average lifetime of a JS/CSS framework? The game isn't to come in knowing this crap. It's to grasp fundamentals such that you can quickly learn the next ones. I much prefer to hire less "skilled" employees who are more interested in the problem domain or product than they are any specific tooling. Goal-oriented developers can be taught to do anything in my experience.
- JohnFen 4y ago
  > I much prefer to hire less "skilled" employees who are more interested in the problem domain or product than they are any specific tooling. Goal-oriented developers can be taught to do anything in my experience. A million times this. When I've hired, the specific languages/platforms/whatever the applicant has is of tertiary importance at best. What counts is the ability to engage in problem-solving, how well they will fit into the team, and how readily they can learn. Everything else can be trained.
- whstl 4y ago
  I agree, but here's the catch: if you're looking for this kind of employee, you won't be hiring "less skilled" people, you'll be hiring "more skilled, more expensive". What people mean by "I will not be able to hire front-end programmers" is actually "I won't be able to hire cheap devs".
  - crabbone 4y ago
    I wish it was that easy... this doesn't account for the dynamics of the job market, the particular niche of Web programming and the perverse incentives created by head-hunters. Much in the same way how programmers (and many others) are scared of "gaps" in their resumes (and will thus accept a job even if their finances would otherwise allow them to extend the job search further, creating more leverage on the employers), Web-programmers, specifically, will be vary today of putting, say, Mootools on their resume (because, oh the horror, I think it's like a decade old tech!). In the very same way programmers, especially in popular fields, like the Web, are compelled to follow group trends more than in less popular ones (eg. HPC). Specifically, in the case of Web programmers, this has an additional side of creating a lot of bloat for no reason other than following fashion. Similar dynamics exist (or used to?) in the world of Java, where you have to (had to?) know about EE and Spring (which are huge and bloated frameworks, most probably don't need to use to get the work done, but were made a staple of Java programming due to fashion).
sublinear 4y ago
> if they don't put a fashionable JavaScript framework into job description, they will not be able to hire front-end programmers. This is not a "pretend answer" and it's perfectly valid for devs to be picky about it. Nobody wants to work on garbage that started out as XML+CSS and mutated into a nightmarish mess that some "backend dev" cobbled together when the product team and the rest of the real world came knocking. It's ridiculous that there even is a distinction between backend and frontend in 2023. It's so much easier to maintain a project when the devs can't feign ignorance.
- mtrower 4y ago
  > the rest of the real world I think you'd be amazed at some of the barebones functional systems that non-trivial segments of the world are satisfied with.
hoechst 4y ago
So you'd write (presumably a big) admin web interface in straight XML + CSS by hand? I don't know the details, but that sounds like a very long and painful process which will end up being hellish to maintain, plus a huge amount of training time for new devs to get familiar with the system. If you even find new devs who'd want to work on this. Who wants to acquire very niche domain knowledge that you can't apply anywhere else?
- crabbone 4y ago
  > So you'd write (presumably a big) admin web interface in straight XML + CSS by hand? That's not what I said. I think, that what you mean when you say "by hand" is the opposite of generating XML (and in case of XML, it's not CSS, the stylesheets are XSL that transform XML into HTML). Before JavaScript frameworks were a thing, technologies like ColdFusion, JSP, ASP Classic proliferated. You can even find remains of this approach in relatively modern frameworks like Django. The idea was to generate XML or directly HTML on the server and send it to the client ready to be displayed rather than sending JavaScript that will request more data as it interacts with the user to build the interface. The former would be called "thin client", while the later is the "thick client". The former used to be more popular because programmers didn't see JavaScript or HTML as a worthwhile to learn language, not enough to build programs in it. It was seen as a target for transpilers. This was before single page applications, or AJAX... The perceived downside of this approach was that for sites with many very similar pages the application server would have to generate a ton of HTMLs, which would be hard to cache server-side, so, allegedly, it would work slowly (compared to AJAX, where a basic HTML page with JavaScript framework would sit in cache and communicate using XML or JSON with the server to build missing parts). XML + stylesheets is one of the ways to address this problem: essentially it does the same thing, but without JavaScript in the middle. The function of the XML part of the equation is to transfer the data that needs to be displayed, and the stylesheet transforms the XML into HTML that the browser knows how to display. Stylesheet can be generic and reused between different XMLs. It's not as flexible as using JavaScript but a lot easier on resources, and will probably beat AJAX solution in terms of speed. Another benefit of XML + stylesheets is good integration with the browser testing tools. With tools like Selenium, you will always struggle to catch page state changes, and will not be able to respond to change as it happens, instead needing to poll for expected condition (that might never materialize). Stylesheets take this aspect completely away because there's nothing in them that happens asynchronously or in chunks. Unlike in single page application, where "page loaded" is undefined, there's an obvious way to tell when "page loaded happens". The problem of XML + XSL(T) is that people have some preconceived notions about it. Very few people know the tool well, and for no particular reason, most people who know anything about the tool know very little about it, but are also very angry about it. Lots of polls for the "worst programming language" would mention XSL(T)... While the truth is that it's just very different from C, and that's what irks programmers. From engineering perspective, sites like, eg. this one, or Reddit or GMail would land themselves well to XML + XSL(T), but the reality is that modern day Web programmers, well, a lot of them, don't even know they have such a tool.
dogcomplex 4y ago
Eh, doable but you do need the JS layer for updating/changing information dynamically (unless you avoid that sort of feature altogether, or just dump ALL your data onto the page in XML). I'm not that opposed though, really. CSS stuff might get kinda ugly quick as you're essentially doing OOP with it though hmm. This all + a basic JS request/response layer to just fetch more XML (rewriting/overlaying previous data) and you're possibly in business.
qudat 4y ago
The beauty of bringing html into js (eg react) is because now we have type support for the entire FE stack. Not to mention the extremely useful view is a function of state paradigm. What you are suggesting sounds something like golang templates and css. That works fine but you can’t easily get types in your templates. It’s a game changer when you have typescript at your disposal for your templates.
ccanassa 4y ago
That's basically how the Django admin works. It's just HTML rendered at the backend. They had to add some javascript here and there but it's very minimal.

webdood90 4y ago

you can't get anything done if nobody wants to do the work

ozim 4y ago
I see you got downvoted but people don’t get that choice of technology based on who you can hire is a valid point. I remember a guy who wanted to make company documentation in LaTeX. Well yes it is great tool and we could put it in a git repo and render nice documents for the customers easily. Downside was 15-20 sales people who were not thrilled to use it and spend time learning how to use it.
- PaulHoule 4y ago
  I think a lot of devs are frustrated with the state of modern Javascript. As I speak I am waiting for "mvn install" to run for a system that has a Java back end and a Javascript front end which compiles both. I think the Java part would finish in about 20 seconds, the Javascript bit is more like 250 seconds. There would be 250 seconds of working instead of posting to HN if the system was "100% pure Java". (To be fair I am mostly depending on an incremental build and I'd say Java turns around in 2s, Javascript in about 20s. One of those breaks my chain of thought, the other doesn't.)
  - holoduke 4y ago
    I never understood why you would need to compile frontend javascript code. Yea maybe a minimizer, obfuscator, some coping etc during a build process. But thats it. My frontend apps are running on the fly. Change in code requires a save and browser refresh. No ammoying compiling .
    - NeveHanter 4y ago
      Well, there're things like React's JSX, CoffeeScript, TypeScript and all of the fricking Babel stuff, all require some kind of transpiling (or how babel names it, compiling), and probably that is what OP means. PS: Luckily, I'm not a frontend dev :)
- crabbone 4y ago
  Hey, I work in a company where user-facing documentation is written in LaTeX! I even contributed few commits to it. I'm not sure though why sales people would need to edit it. My discontent with LaTeX for documentation is that searching it sucks. I mean, you do get literal search for words, but if you want something smarter... PDFs don't interact well with searching tools we have. Another problem: interactive scroll. In HTML documents you can scroll sections of documents independently of each other (if you need to), so you can create ad hoc views of your documentation that could be more useful to you (eg. collapse a bunch of tables or code listings just to see the text in between). On the other hand, if you want to print it, oh man... it's going to look so much better! :)
  - ozim 4y ago
    It is also a bit of a point of my post. "Why sales people would need to edit it?" Because there were no dedicated people writing documentation, there were developers and sales people - that was it. Non technical documentation so "how to use the system" was going to be written by sales people. Lots of times in a company you work with what you have and finding and hiring "technical writer who has experience or wants to work with LaTeX" I would count as hard task.
    - crabbone 4y ago
      I used to be on good terms with a technical writer from a company I worked for some time ago. He later became one of the very few people who were let go as a result of a merger. Also, from what I can tell, technical writer isn't a cushy job, not anywhere near even entry-level programming jobs. Also, it's usually at companies with existing and large user-base, relatively large companies... there's not a lot of jobs on the market. I mean, I have a feeling that if a company asked a technical writer to learn LaTeX, they would probably do it, even on their own time. It's a tough market, and learning LaTeX enough to produce something isn't a huge effort (also, there are a bunch of tools that prepare the boilerplate code for documents). But I can see how sales people might not have been impressed by such prospects.

mikrl 4y ago

No one wants to write html_page.html, but html_page.js?? Now you’re talking.

hotbeanwater 4y ago
Okay hear me out: html_page_analytics.js html_page_bundle.min.js html_page_tracking.js html_page_d8fd766d76223ae.min.js html_page_user.js html_page_banners.js html_page_pardot_dfa7s778d9aa.min.js
- aloisdg 4y ago
  This should be put into a resume.

bob1029 4y ago

> if they don't put a fashionable JavaScript framework into job description, they will not be able to hire front-end programmers. This is exactly why we are vague with tech stack in our job reqs. Why would you want talent that is laser-focused on specific keywords? What is the average lifetime of a JS/CSS framework? The game isn't to come in knowing this crap. It's to grasp fundamentals such that you can quickly learn the next ones. I much prefer to hire less "skilled" employees who are more interested in the problem domain or product than they are any specific tooling. Goal-oriented developers can be taught to do anything in my experience.

JohnFen 4y ago
> I much prefer to hire less "skilled" employees who are more interested in the problem domain or product than they are any specific tooling. Goal-oriented developers can be taught to do anything in my experience. A million times this. When I've hired, the specific languages/platforms/whatever the applicant has is of tertiary importance at best. What counts is the ability to engage in problem-solving, how well they will fit into the team, and how readily they can learn. Everything else can be trained.
whstl 4y ago
I agree, but here's the catch: if you're looking for this kind of employee, you won't be hiring "less skilled" people, you'll be hiring "more skilled, more expensive". What people mean by "I will not be able to hire front-end programmers" is actually "I won't be able to hire cheap devs".
- crabbone 4y ago
  I wish it was that easy... this doesn't account for the dynamics of the job market, the particular niche of Web programming and the perverse incentives created by head-hunters. Much in the same way how programmers (and many others) are scared of "gaps" in their resumes (and will thus accept a job even if their finances would otherwise allow them to extend the job search further, creating more leverage on the employers), Web-programmers, specifically, will be vary today of putting, say, Mootools on their resume (because, oh the horror, I think it's like a decade old tech!). In the very same way programmers, especially in popular fields, like the Web, are compelled to follow group trends more than in less popular ones (eg. HPC). Specifically, in the case of Web programmers, this has an additional side of creating a lot of bloat for no reason other than following fashion. Similar dynamics exist (or used to?) in the world of Java, where you have to (had to?) know about EE and Spring (which are huge and bloated frameworks, most probably don't need to use to get the work done, but were made a staple of Java programming due to fashion).

sublinear 4y ago

> if they don't put a fashionable JavaScript framework into job description, they will not be able to hire front-end programmers. This is not a "pretend answer" and it's perfectly valid for devs to be picky about it. Nobody wants to work on garbage that started out as XML+CSS and mutated into a nightmarish mess that some "backend dev" cobbled together when the product team and the rest of the real world came knocking. It's ridiculous that there even is a distinction between backend and frontend in 2023. It's so much easier to maintain a project when the devs can't feign ignorance.

mtrower 4y ago
> the rest of the real world I think you'd be amazed at some of the barebones functional systems that non-trivial segments of the world are satisfied with.

hoechst 4y ago

So you'd write (presumably a big) admin web interface in straight XML + CSS by hand? I don't know the details, but that sounds like a very long and painful process which will end up being hellish to maintain, plus a huge amount of training time for new devs to get familiar with the system. If you even find new devs who'd want to work on this. Who wants to acquire very niche domain knowledge that you can't apply anywhere else?

crabbone 4y ago
> So you'd write (presumably a big) admin web interface in straight XML + CSS by hand? That's not what I said. I think, that what you mean when you say "by hand" is the opposite of generating XML (and in case of XML, it's not CSS, the stylesheets are XSL that transform XML into HTML). Before JavaScript frameworks were a thing, technologies like ColdFusion, JSP, ASP Classic proliferated. You can even find remains of this approach in relatively modern frameworks like Django. The idea was to generate XML or directly HTML on the server and send it to the client ready to be displayed rather than sending JavaScript that will request more data as it interacts with the user to build the interface. The former would be called "thin client", while the later is the "thick client". The former used to be more popular because programmers didn't see JavaScript or HTML as a worthwhile to learn language, not enough to build programs in it. It was seen as a target for transpilers. This was before single page applications, or AJAX... The perceived downside of this approach was that for sites with many very similar pages the application server would have to generate a ton of HTMLs, which would be hard to cache server-side, so, allegedly, it would work slowly (compared to AJAX, where a basic HTML page with JavaScript framework would sit in cache and communicate using XML or JSON with the server to build missing parts). XML + stylesheets is one of the ways to address this problem: essentially it does the same thing, but without JavaScript in the middle. The function of the XML part of the equation is to transfer the data that needs to be displayed, and the stylesheet transforms the XML into HTML that the browser knows how to display. Stylesheet can be generic and reused between different XMLs. It's not as flexible as using JavaScript but a lot easier on resources, and will probably beat AJAX solution in terms of speed. Another benefit of XML + stylesheets is good integration with the browser testing tools. With tools like Selenium, you will always struggle to catch page state changes, and will not be able to respond to change as it happens, instead needing to poll for expected condition (that might never materialize). Stylesheets take this aspect completely away because there's nothing in them that happens asynchronously or in chunks. Unlike in single page application, where "page loaded" is undefined, there's an obvious way to tell when "page loaded happens". The problem of XML + XSL(T) is that people have some preconceived notions about it. Very few people know the tool well, and for no particular reason, most people who know anything about the tool know very little about it, but are also very angry about it. Lots of polls for the "worst programming language" would mention XSL(T)... While the truth is that it's just very different from C, and that's what irks programmers. From engineering perspective, sites like, eg. this one, or Reddit or GMail would land themselves well to XML + XSL(T), but the reality is that modern day Web programmers, well, a lot of them, don't even know they have such a tool.

dogcomplex 4y ago

Eh, doable but you do need the JS layer for updating/changing information dynamically (unless you avoid that sort of feature altogether, or just dump ALL your data onto the page in XML). I'm not that opposed though, really. CSS stuff might get kinda ugly quick as you're essentially doing OOP with it though hmm. This all + a basic JS request/response layer to just fetch more XML (rewriting/overlaying previous data) and you're possibly in business.

qudat 4y ago

The beauty of bringing html into js (eg react) is because now we have type support for the entire FE stack. Not to mention the extremely useful view is a function of state paradigm. What you are suggesting sounds something like golang templates and css. That works fine but you can’t easily get types in your templates. It’s a game changer when you have typescript at your disposal for your templates.

ccanassa 4y ago

That's basically how the Django admin works. It's just HTML rendered at the backend. They had to add some javascript here and there but it's very minimal.