Ask HN: Are there any non-SPA front end developers left?

[karolinepauls]

Back in "my days" we would get an in-house web designer to create assets, styles, and a demo HTML document demonstrating all necessary components to implement the planned content.

We would then break down the demo HTML into templates, which we would render in the backend, and work from there.

There would be JS for interactive components - first Knockout (viewmodels, terrible idea), then React (which would let you separate the state from presentation).

Backend templates + React frontend components was IMO the optimum, as long as your POST handling logic was sensible and data-oriented rather than some OO nightmare (https://wtforms.readthedocs.io/en/3.2.x/fields/#the-field-base-class).

You didn't have to implement the API separately from the frontend to later discover that your frontend developer worked really... fast. And implemented their own understanding of the problem domain. These days, if you're super unlucky, you discover that your frontend has been blessed with some non-standard component wrappers, which wrap components, which wrap components, which wrap... And somehow types in TS docs still have no links, so good luck finding what they mean by TData, especially if TData comes from a different codebase.

tl;dr: The tldr is in the title. I want sanity back :D

[gethly]

They never left. But SPA is now more in demand than the old school server-side rendering where you return HTML in your response and let the web browser render it as is.

Decoupling back-end logic from front-end logic has just too much positivise and advantages that doing SSR is just so 2000s. JS brought dynamicity into web page rendering a long time ago. With SPA, or maybe even PWA(who really uses these?), you get also decoupling from the server - a data dynamicity, so to speak.

In short, SPA turns a dumb web page into a dynamic and responsive application that can have the look and feel of a desktop program. Web is no longer static and slow but fast and lively.

Nowadays, static HTML is a niche use case for serving web pages. Like a personal blog or corporate website that is static in nature(information there change sparsely) and can be manually typed or compiled via static website builder, like Hugo.

[austin-cheney]

I prefer to develop SPAs for personal use but with vanilla JS. My goal is both scalability, performance, and accessibility. Its hard to find employment that values things like high performance and test automation, so I switched to a different kind of software for employment where I was quickly elevated into management.

I don't want to go back to JavaScript for employment so long as its riddled with unnecessary abstraction/dependency nonsense. While I did get tired of solving for the numerous problems that shouldn't exist in the first place I got more tired of insecure peers who were always quick to point fingers. I don't have to worry about that any more.

[cranberryturkey]

I'm starting to get into building .onion sites and my general experience is people on Tor all have js disabled. So I'm looking for a js-free framework that works with node.js (ironically)

[Leftium]

SvelteKit has been designed so JS on the client can be optional. (All JS is executed in node.js, with optional JS enhancement on the client.)

Try playing Sverdle with JS disabled! https://sveltekit-template.vercel.app/sverdle

> Unlike the original Wordle, Sverdle runs on the server instead of in the browser, making it impossible to cheat. It uses <form> and cookies to submit data, meaning you can even play with JavaScript disabled!

[lcnPylGDnU4H9OF]

> So I'm looking for a js-free framework that works with node.js (ironically)

I know you already called it out but there really is something funny about this. The primary reason I recall for node's popularity is that it means you only have to know one language. I guess that's still true...

[leakycap]

SPA development is everywhere because you can charge a lot more for it, and web development has become commoditized in many other arenas

Sanity is available immediately if you are willing to be paid less. There are tons of simple, non-SPA, non-stack-on-stack projects out there, they just usually pay 1/10th the complex stuff.

[karolinepauls]

Sorry not to have made this clear: I am not a frontend developer. I'm a backend/infra developer who's forced to work on a React app abandoned by a frontend developer who incorporated their own wrappers-of-wrappers-of-wrappers.

Meanwhile the client is telling me is virtually impossible to find frontend devs willing to write HTML.

[andrei_says_]

Yes, of course.

Rails for example is SSR by default with a bit of js which speeds up the experience with zero dev effort. Anyone starting a greenfield rails project is spa free by default.

[decafninja]

As recently as 2020 I know there were a decent number of old school ASP.NET sites at various Wall Street investment banks (and devs maintaining and even building new features for them).

I don’t know if that’s still the case.

[fzwang]

If you haven't already, check out the HTMX community [1].

I think there's some recognition that a lot of SPAs didn't need to be SPAs in the first place. At the end of the day, you're just submitting a form for a CRUD app. Good ol' HTML + a sprinkle of JS was enough for most use cases. CSS has evolved to take away some of the stuff that required JS before.

At the moment, I don't think there's really any strong incentives to cut down the complexity of apps by moving away from SPAs. There's real job security in creating complexity. And in some big orgs it's unavoidable. It can change when developers are more aligned with long term outcomes (ex. a product that they own), which usually means smaller projects.

[1] https://htmx.org/

[mierz00]

Maybe I have misunderstood but this sounds like a ways of working problem as opposed to technology?

[trumbitta2]

Is there any non-SPA front end job market left?