I've gone the other direction, which is basically "Typescript everywhere", or at least as much as possible, i.e. React on the front end, NodeJS on the backend, and Capacitor for apps (note Capacitor may not be appropriate for all types of apps but in our case it was).
Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.
Just the same Languages have their strengths. Using a backend language to write your frontend is more or less a waste of developer resources. Chances are if you just chose react and typescript you could pull things off the shelf and have almost an unlimited amount of resources and developers you could pull from compared to an esoteric LiveView or webassembly type framework, get the project done faster, ship and iterate as opposed to reinventing the wheel and satisfying the commonly felt NIH syndrome.
Typescript for both frontend and backend is a bit better, but the backend story for me is still weaker than using Python or elixir, etc simply serving an API, because if you are building a company, 9 times out of 10 you are going to have to have an API anyways. I like to have the boundary of that API explicit.
the only exception to the above is if you aren't building a company and instead working on a small personal or group project.
Doesn’t that say more around your surroundings? I’ve definitely met people that were equally competent at both (and more competent than most). A lot of things that are important on the front-end are equally important on the back-end and vice versa. Lets add databases and infra while we are at it.
The thing is, you need an actually senior engineer for that. Not some kid right out of college that is somehow called a principal.
On the frontend you need to deliver excellent user experience, deliver accessibility, localization, cater to different—sometimes legacy—browsers. Even if you have a graphic designer, you still need to work with your designers to deliver a good UX.
On the backend (I think) you need to deliver optimization, and speed, you need to work within confines of your infrastructure, or work with your infrastructure engineer, you have to design databases and optimize your storage and delivery. You also need to deliver a good API for your frontend devlopers, otherwise they‘ll complain. I‘m a frontend developer so I bet there are tons of stuff backend developers do which I don‘t even know about.
I do agree with you that there are skills specific to each layer of the stack and they don’t all cross apply. You definitely don’t get to be good at backend and then magically be a strong frontend engineer! But I think a good backend engineer has a bright future as a good frontend engineer and vice versa, should they choose to pursue a different branch of our discipline.
I hope the same applies for frontend. Let's not have the 20MB bundles (definitely exists) and seconds before a page loads etc.
> which I don‘t even know about
Security!
This is why no-one should hire me as a backend developer ;)
But fullstack engineering is just much more individually productive, if you're updating a settings page why involve multiple engineers and coordinate a handoff, when one engineer can just add the API calls on the backend and add the new toggles to the frontend in a single day? Most software doesn't need to be beautifully polished and completely excellent.
Anyway I personally just find it fun, I get to breathe life to a vision end-to-end and tackle a wide variety of problems, and I can deliver quickly. Even if I'll never be (and don't desire to be) a super expert in one technology.
It’s a very recent thing that these things you describe are even considered related to front and back-end at all. If you go even 7 years back you’d have needed to consider all these as a “back-end” developer.
For example if the the app is too slow because we are pulling in thousands of records and rendering it to the DOM, the correct optimization is to paginate the results. Both frontend and backend devs should know that. However the frontend dev needs to make the pagination a fluid UX for the user, decide between page controls or infinite scroll, implement search on type, set the correct aria-attributes so assistive technology knows this is an incomplete list, etc. The backend dev however needs to optimize the database queries, decide on the type of pagination (keyset vs. limit-offset vs. cursor etc.) and map the response such that the frontend won’t have to do too much work ones received (I guess a frontend dev should be able to do the latter; but it is hard to ask a frontend dev to be an expert in optimizing database queries; or implement proper keyset pagination [although if the UX team decides on infinite scroll that limits the possible pagination types a little]).
> If you go even 7 years back you’d have needed to consider all these as a “back-end” developer
I have been a frontend dev for almost 15 years, and I very much disagree with you here. I don‘t think that in 2018 you could expect a backend dev to implement responsive layout, deliver accessibility, localization, delivering to different browsers (case in point: Intl.PluralRules became widely available 7 years ago).
This may have been true in 2009 when web-apps were fairly simple (often just a series of form submissions), you had a good idea about the screen size of your users, it was hard to mess up accessibility (and yet, many developers did), localization was mostly done on the backend, single page apps were almost unheard of, etc. But not in 2018.
This is all HTML & CSS. Bootstrap made responsiveness normal ever since it was introduced. If you have any form of server rendered application you have to handle these. It’s not like you can choose to hand it to a nonexistent front-end dev, since there is no separate front-end.
Fullstack in my experience arises out of a need by companies and startups to cut costs by having a single engineer do both.
The adage being "A jack of all trades is a master of none, but oftentimes better than a master of one."
A fullstack developer is not two developers in one. A dedicated backend or frontend dev will always overperform a fullstack dev in their side of the stack.
But while a good fullstack dev is not useful to a more mature company, they are invaluable to a startup, early stage company or greenfield project where building fast, lean and "good enough" is the target.
I’ve met people who haven’t solved a partial differential equation in 10 years and still remember how to do it whereas some people barely remember the library they used last week and have to keep a mountain of notes.
The people in the former camp have a lot of very deep knowledge on a lot of things.
One issue our industry has is how to identity a great generalist. Broad conceptual thinking is harder to test and interview for than specialized tasks.
It's important to not see any iteration of the phrase as either praise or insult. There is nothing wrong with being a specialist or a generalist, only that there are uses for both.
Consider two examples: sending an email, which requires typical frontend skills but is by nature in the backend code; and configuring invisible backoff and retries in the frontend, which is the opposite.
I call myself a full stack engineer even though my ability to do design-adjacent work is pretty bad because I've spent a lot of time working in this middle ground. When you want to e.g. move PDF generation from the server to the client, or you want to untangle the horrible Redux caching layer that doesn't invalidate things properly, that's a specific blend of skills that's neither fully one nor fully the other. This is less about cost and more about a niche between the two fields.
Consider also data engineers, or teams with a technical lead rather than an EM, or any other role that sits between worlds.
From my experience a fullstack dev can be a lot more productive than two separate devs when it comes to adhoc work like bugfixes and adding small features.
Also they tend to have very good API design skills, since they understand both sides intimately.
This is somewhat silly because there's no good way to compare backend and frontend abilities. And why would you! A full stack engineer indicates willingness to tackle both sides, no equivalent competancy.
Tbh this is a meaningless statement. How on earth is any sane person supposed to compare competencies?
I both describe myself as full-stack and associate with other people who do the same. There isn't a single person among us who would try to pitch ourselves as equally competent on the front end and the back end. Who would do this? Why? To what end? This simply ignores why people actually use the term "full stack": to indicate willingness to take on work, not competency.
So what? Both of these developers would be able to ship a typical feature in a typical web product by themselves, without back-and-forth with their counterpart all the time, and that's a huge productivity boost. May be at some point help from a subject area expert would be needed — set up proper db indexes, center that div properly on a small viewport. But being able to iterate without the need to communicate, debug miscommunications, or wait on another person’s availability is a massive efficiency gain. Most product work doesn’t require deep specialization—just someone who can get things working end to end, refine as needed, and know when to pull in an expert.
The alternative is siloed devs constantly handing off half-finished work, where backend waits on frontend for an API contract, frontend waits on backend for an endpoint, and everyone waits on QA. Been there, done that. A competent “full stack” dev sidesteps that bottleneck and ships.
Its a short term productivity boost sacrificing for long term maintainability and future productivity.
I would take 1 backend engineer + 1 frontend engineer over 3-4 "fullstack engineers" any day of the week.
Thats not to say a layperson can't build a house, but having experience and training about a specific domain can make later modifications and updates significantly easier.
You don’t get back to architect when you’re doing plumbing. You don’t get back to plumbing when doing electricity.
And not only those are often highly isolated tasks but those domain have specialist in it as well. You might go to electrician who can do high voltage installations and you don’t care because he can to general wiring too (thus being full stack).
But there’s different about sacrifice that’s bigger issue. In software engineering handoff costs can be absurdly high. Teams can be allocated and if backend team misses on deliver the next window of opportunity can be in couple weeks. In micro, highly agile teams it’s yeah whatever, but I’ve yet to see a dedicated team of frontend/backend that’s on standby for the other party.
I am literally that person. It's a good thing we've never met, or you wouldn't be able to say that anymore!
Edit: Sorry for sharing my professional responsibilities, where some of my clients pay me for front-end work, some for back-end work, and some for both. I forgot that people on the internet that have never met me know what I do better than I do, and that I'm not good at it! Please don't tell my clients that have been paying me continuously for 15 years....
As someone who worked directly with OP, I can confirm they are highly exceptional. Don't be too surprised when you encounter talented people on HN. I challenge you to be more inquisitive, rather than dismissive.
I’ve met a lot of programmers early in my career who were full of themselves, and a number of more experienced ones later in my career that understood their own capabilities very well.
But also, no one thinks Full-stack developers are experts at everything. We are well aware they are the jack-of-all-trades developer archetype, that's why we hire them. They come in all kinds of shapes like you allude to, more like a starfish of skillsets with varying degrees of skill in each leg.
But perhaps the best thing you get out of the starfish, is you know they'll be able to pick up whatever you throw at them, and they won't complain that that they can't do it because it's not "frontend" or not "backend".
Corallary, good programming is universal. I find people tend to be experts in business domain and framework, regardless of where that lives on the front/back spectrum.
Note I'm not saying do this everywhere if there is a place where there are clear benefits to using another language. For example, while IMO the difference between Python and Node on the server for standard CRUD type apps is really one of preference, that's not the case for doing something with ML or LLMs, where the ecosystem around Python is much bigger, robust, and more generally familiar to the AI crowd.
Anyways recently the typescript backend scene is developing a lot better than even a few years ago. stuff like NextJS becoming more popular and more stable better backend typescript frameworks coming out.
My comment was mostly aimed at using backend languages for frontend as opposed to necessarily targeting Typescript
FWIW I was a primarily a Java server developer for the first ~15 years of my career, then switched to Node and really loved it. It was at that point that I fell into the benefits of my "Typescript everywhere" mantra because it solved so many problems I had seen with the common setup of Java on the backend and Javascript with the rise of SPAs on the front end.
I am curious - could you explain how you are benefiting from using Typescript on both back and front end?
When I've posted this before, the main objections I've got have usually been from the perspective on individual developers, or stuff like "you can't actually share a ton of code between front-end and back-end". That's not my primary point (though there are some places where it is nice to share code, e.g. input validation that you may want to run on the client for user experience/performance reasons but then that you also need to run on the backend for security reasons). The biggest benefit I've seen is in team dynamics which results in bugs getting fixed faster and new features getting added faster because it's easier for team members to "cross" backend/frontend boundaries.
We switched over, have fastapi generate an openapi.json, then use Kubb to have it auto-generate typescript types (it can also do zod models), done.
And given the current market, companies can be more selective.
I never interpreted Full Stack to mean homogenous competency, which is a rather strange concept if you think of it.
There is something to be said about language _pairings_ though. I was building with a Python backend and ClojureScript front end for about 8 months and it. was. [expletive]. miserable. The context switch between the two languages was insane.
I rewrote the backend to Elixir and the problem completely went away. No more context switching. Elixir is amazing at what it does. ClojureScript is amazing for UIs and state management. Everything is functional and immutable.
That being said, I do occasionally wish the data validation could be written in one language and used on both places. But that’s just the engineer in me - in practice I have had 0 data validation mismatch errors
Full stack developer here who disagrees. Most web apps are not that complicated and if there are the term 'backend developer' will be replaced with something more specialised as well.
> the backend story for me is still weaker than using Python or elixir, etc simply serving an API
That is a very odd statement, Python has a lot of issues that NodeJS never had, in terms of developer experience I believe NodeJS is superior just based on the fact that I don't need to know what a virtual environment is and I don't need to choose between different incompatible package managers before I even write my first line of code.
> if you are building a company, 9 times out of 10 you are going to have to have an API anyways. I like to have the boundary of that API explicit.
If the only consumer of the API is your frontend, why would you want to have such a strong boundary?
> the only exception to the above is if you aren't building a company and instead working on a small personal or group project.
This statement can easily be hard countered by the rise of full stack frameworks like NextJS and the fact that the whole backend-frontend separation didn't always exist, it mainly happened because of SPAs.
I would not be surprised if in 10 years from now, there will only be full stack web developers.
I am a desktop developer (yeah, Electron). There's really no front-end / back-end split in this domain. Electron is pretty much everything web front-end (in a "SPA, choose your own adventure" way rather than relying on a framework to do the heavy lifting) and all the business logic that is self-contained within the app and putting it all together with the APIs Electron exposes. I know that a local self-hosted back-end does not have the complexity of a distributed web-backend, but it's still much more than just front-end and there are areas of development that are probably more "wide" and definitely more complex than this anyway - like video game development or C++ / QT desktop development.
Now what happens to the front-end now? Full-stack frameworks like Next.js. They also simplify the front-end part to death, where you do not even get to think about state management anymore. Then you add generative AI...
Also consider this, is a front-end and back-end engineers with 10 years experience at a large co that much better at their respective domains than a full stack with 5 years of experience at a startup? I cannot say for the back-end, but I can say for the front-end - there's a ceiling and it does not take long to reach it (maybe 5 years). You stop getting much better once the ceiling is reached. So what makes someone good is both reaching the ceiling and continuing to do the work on a daily basis, rather than specialising in an area, in my option. A video game dev with 20 years of experience probably is much much better than one with 5y. But front-end? I don't think so.
The only kind of frontend I could equally consider myself good, are native frontends on Apple and Microsoft platforms, but that is because native GUIs do most of the UI work and don't require CSS wizardy skills to turn divs into drop down boxes with type-ahead search.
stitching libraries together is the essense of soctware engineering
I wish it got more love.
Scala is more similar to traditional Java while letting functional programming shine.
Nobody wants that culture in their workplace. Also the dysfunction is visible in the technical fragmentation of the ecosystem
It's backed by $$$ that have promoted it that way - a "better" Java.
Modern java has been grabbing features from all the “better Java” languages at such a pace that the big gap right now that I see is the question mark operator.
.NET is in the same predicament. Very convenient and highly efficient concurrency primitives.
Unlike Go, but like Rust, it has a reasonable type system, and is data race free (since JS is single threaded).
Anyway, I come from a C++/Rust background, but have been using TS recently, and it’s a much nicer language than I’d have guessed.
"Consistency is the hobgoblin of little minds"
-- Ralph Waldo Emerson
Google also trie to do this with Protocol Buffers on Javascript front ends and the serialization methods were... suboptimal. Because obviously you can't do (or at least couldn't at the time) binary encoding and decoding on a browser.
All this is why we've seen multiple attempts to, say, allow you to write an app that'll work on iOS and Android. React Native springs to mind.
Now if you can come up with an end-to-end Typescript solution, that's great. But it's also a pretty severe constraint and one that doesn't, for example, solve the native mobile platform issue.
And react introduces a host of dependencies which may be ill maintained. The only reason to bring this up in an online forum is because I'm tired of recruiters constantly asking for react and nodejs.
REST isn't complex, but API design is still hard. Making a strategic choice not to design a service API but to ship the same code in two places is valid, and arguably the right one if that's what the teams skills lend themselves to.
See: Rails Hotwire, Laravel Livewire, Alpine.js
With the setup you described I just felt I had to write more, even if it was in the same language.
More importantly, though, you seem to be commenting from the perspective of an individual developer. The biggest productivity gains I've seen is that it makes it much easier for people on different areas of the team to understand and fix/modify parts of the code that they're least familiar. E.g. if I'm a developer that spends 99% of my time on the front end, but then I need some extra field that's not being returned by the backend, instead of having to do a full context switch, get an environment up and building that I may not have compiled in a long time, get my brain "switched over" to a different language, or worse, file a ticket and wait for the backend team to fix it, it's much easier if I can just go in quickly and add the field I need.
I've seen this in spades on small/medium teams - it really "lowers the barrier to entry" for people being able to submit PRs in parts of the codebase that is not their primary day-to-day work.
This assumes that just because it's the "same language" it's all the same.
It's especially true in Javascript land where the React setup is vastly different than the Node backend framework setup.
You get bundler differences, ESM/CJS, different versions of Node (or even Bun / Deno), linters or things like decorators, etc... You can be doing "functions" with React and then head to classes and modules with NestJs all of a sudden.
It pretends to be much easier. I've seen lots of real world assume-there's-a-shortcut method that just makes it worse.
Absolutely bad advice and totally disagree.
So having a language such as TypeScript which is already built on top of an even more immature language such as Javascript in critical systems software or highly regulated settings is a good idea?
Having it on the backend is also bad enough, but everywhere really an indication of not being able to adapt into using a properly designed language for the specific use-case and just being inflexible because you are 'used to the language'.
This is not even talking about the entire TS/JS ecosystem which is has a sea of libraries which most of them are also immature and not production-grade at all.
That said I’m patiently waiting for dotnet renaissance.