I stopped guys, I stopped doing it. For internal tools at my company, I just use a golang backend (because most of our services are golang so there's no learning curve for folks) and use go's templating system to render HTML.
I can crank out tools in minutes. No complicated build systems or web pack or dependency management system. No react, no reduce, no apollo or graphql. No typescript, etc.
Just simple go, html, css, and a bit of javascript when it's needed for a form. I don't minimize anything, or try to do anything fancy. It faster to develop in, and faster to load in the browser.
I'm specifically talking about internal tools here.
The usual problem is that people often pick an SPA tool for a job that a CGI script can handle. The fashion made "web UI" and "react" associated too strongly.
Much simpler tools can work if you allow for less fluid interfaces, and this may be a non-issues for a tool running on a LAN.
We're never replacing our old-style PHP internal tools, because according to business users it's "instantaneous", and any attempts to use a more SPA approach cause complaints about "sluggishness".
Once the CGI page loads, all info is in there. React requires 1 request for the basic HTML, (1 request for the JS but it’s generally cached) and 1 request for the data from the REST API. It’s double the time to load a page.
React apps constantly have gray placeholders waiting for data to finish loading. Contrary to initial experiments, progressive rendering is recorded by the brain as a bad experience.
React is simply a library that renders your UI to the DOM. It doesn’t have any opinions on how your data is fetched, or how many roundtrips it takes. That’s an orthogonal concern. People have been using XMLHTTPRequest with CGI since the 00s, way before React was a twinkle in Zuck’s retinal sensors.
You can send your initial data for React with the HTML response if you want to eliminate the extra round trip on startup. Depending on the geographical distribution of your users it may or may not be worth it.
React's new server components (only in next 13 at the moment, coming soon to other framework) addresses this problem. Of course react and node both have performance work they need to do also.
I have just spent the last year doing the literal opposite.
15 year old software product built on Perl CGI with a server rendered html+jQuery front end. Massively grown past the point where that is suitable, with plans to add interactive features that would be crazy to do with the old architecture. Have moved the whole thing to a VueJS frontend. We have kept the old Perl CGI server architecture, just refactored it to return JSON.
You are complete right, to many people chose a tool based on fashion. There are two main things to consider when picking a toolkit or architecture for a web app/site:
- what do my team and myself know well, what will be the most efficient?
- where is the state? Is it predominantly in a database on the server or client side in the browser?
The project I'm on when they first asked those questions, the answer was, Perl CGI and server side state in a database. That is no longer the case for the second question, the state is increasing moving to the client side, and that's why I joined the team.
If I was answering the second question as server side right now I would probably pick htmx+alpinejs.
However, sometimes the first question overrules the second.
(There is a third question, do you need an installable app too? In which case a SPA with a toolkit that supports PWAs or web view wrappers is a good option if you want to only have a single codebase)
I mean, there’s been outcries how the US is overly car-dependent and driving should be a choice not a requirement etc. The parent is onto something if you go with this analogy.
I’m not sure the complex problems these tools were originally created for still exist. For example, do you really need to support old browsers? If not, you probably don’t need a transpiler anymore.
Well, webpack has been replaced by vite (for those who pay attention to front-end trendfuckery) which is much simpler than Webpack and Babel is eliminated.
We are still not quite at the point where it’s practical to not have a module bundler. Handling things like imports etc is still necessary.
But we are moving away from React. Things are slowly going back to sanity. SvelteKit is an excellent step in this direction IMO.
Their customer support pages with built-in live chat do. And I'm assuming we're excluding aws.amazon.com with realtime graphs and viewable log streams.
Take a look at htmx (https://htmx.org/) if you haven't already. For my use cases, generally internal tooling like you mentioned, I've found it integrates extremely well with go templates and more often than not provides all the functionality that I'd generally be reaching to javascript for.
99% of us live in a world that does not need reactivity, yet so many of us are led to believe that we are in a world that does. All because Facebook made React (for what original use case? Facebook Ads Manager?) doesn't mean we're all going to be Facebook, need to be Facebook, or want to be Facebook.
When I need the reactivity, I need to sprinkle it on; I don't need to use reactivity when it's not needed just for the few cases that do.
I mean, you're welcome to go back to PHP and jquery like it's the dark ages, but from where I'm coding, react is the only sane way to deal with a big complicated app.
You have no idea how bad it can get. I hate hate hate anything Ruby. Rails itself is a good idea, but you basically get 0 editor support even with tooling and you barely know the structure of your objects.
If you stay away from metaprogramming in your own code Rubymine brings a lot to the table:
Go to definition (all the way down to any source code in gems)
Usages
Refactoring (renaming methods, classes and filenames)
Integrated debugger
It even infers types now
Brings nice documentation for methods if you use RBS and/or Yard
I think this goes as long as it can be taking into consideration that Ruby is dynamically types and has a lot of support for meta programming.
I know of Rubymine and use it daily. Rubymine sadly gives up if files get too large, which is realistic for `config.rb` even in medium sized Rails projects.
But I wonder if a language can be considered good for use if you can only really use it within a dedicated, non-free IDE.
Heh, this comment made me giggle. Indeed when someone says that React (or any other technology to write a SPA) sucks, they should just go back to PHP + jQuery in order to remember why we are here.
> Just simple go, html, css, and a bit of javascript when it's needed for a form
I mean if your tools are that simple, this is a no-brainer. The problem is when you have to scale up. Internal tools can get complicated because their user base is often highly specialized technical users. Managing reusable components, behavior, and state of a complex application is when you need something like React.
I’ve grown to loathe React but your approach breaks down horribly once you start getting to a certain level of complexity. There is a reason frontend JS frameworks exist, I just wish the default wasn’t React.
Have you tried Vue? I work for a huge company (nearly 100,000 employees). We tested both React and Vue and settled on Vue. That was years ago, but we’ve had no regrets since.
I've used Vue. It's much worse than React. It's probably ok for very small sites but its automatic reactivity system seems almost deliberately designed to produce spaghetti code and subtle bugs. Plus it has poor Typescript support. You don't have to worry at all about type errors in TSX.
That said, I'm liking Yew a lot more than React. The difficult thing with React is state management, which is why it's common to resort to immutable state (even though that's a real pain in JS), and even then React chickens out by assuming components are impure by default.
Everything makes way more sense in Rust. The big downside is that Yew doesn't really have anything like Bootstrap or Blueprint yet. I mean there are ports like Yewprint (great name) but they seem to be complicated to set up and you lose the really nice simplicity of Trunk.
It won’t be. React had its time and is now waning. The future is frameworks with no virtual DOM that are interoperable with other JS frameworks like Svelte.
You can still throw in something like Vue later, easily. It is one script tag away. That is what most do not get. You can go the traditional template rendering way for as long as it serves you well and then you can still have interactive components, when you really need them.
I was recently writing raw html and the typesystem compared to js components (aka JSX) is... just not there? I hate coding without proper autocomplete.
Yep. My experience has been that you can start with a wonderfully simple tool, but you end up jamming in dynamic behavior because users today want it and expect it... even in "simple" internal LOB apps.
Updating the UI in response to user value input and state changes in real time: error messaging, validation, presenting more relevant additional inputs, formatting, etc.
How much of a usability win is making things “real time?” Submitting a form and having the server do validation and render the error messages can feel just as fast. Plus, if you use the correct HTML input types the browser will handle the most obvious validation without any JS.
You have to do validation on the server anyway. Why do it again on the front end?
You don’t have to do all validation on the server side.
Did the user forget to fill a mandatory field? Is this phone number actually even possible? Does this zip/postal code exist? Is the age entered too low to create an account? Is the password long enough? Does it meet all the requirements. Can we dynamically show which requirements it doesn’t meet.
Even email, which you will want to verify by actually sending an email, can have some basic front end checks (is there an @ in the email entered by the user).
In fact, I bet the vast majority of validations can in fact be done in the front end in real time.
Client-side code is subject to potential manipulation. No validation you perform there can be a guaranteed truth for the server-side. Thus you cannot replace validation on server-side with validation on client-side.
You had all this (most often as free & open source jQuery plugins) 10 years ago.
Honestly, 99% of webapps today are 2 very interactive pages (which could often be developed in jQuery anyway) + bunch of generic datagrids & forms we have seen many times since the introduction of <form> and <table> tags decades ago.
While this could be achieved on the frontend with jQuery + plugins (or even vanilla JS, let's be honest) I think you're not remembering how cumbersome and error-prone building forms / complicated flows was without a dedicated framework. Speaking from experience, I believe Backbone.js was the first time I felt confident building state based UI on the web. Newer frameworks (first Angular, then React/Vue since then) have upped the stakes.
Honestly, my problems as a developer generally aren't with the frameworks (I'm mostly defending Vue here, as I find it predictable and easy) but with the build tools, which have gotten a bit out of hand and always feel brittle.
Personally, I think the main problem with jQuery was .data instead of having proper state management. If we used jQuery just as a library and not the centre of everything without any layer above, we might be perfectly ok with it even now in 2023 for everything that's 100* simpler than GMail (which most of webapps are).
Verbosity is hardly the problem these UI libraries/frameworks solve. They establish idioms for data flow and composition.
The UI component model’s data flow might vary between libraries, but they’re all generally opinionated and fairly consistent internally. The equivalent in “vanilla JS” can easily become unwieldy even with a lot of discipline, because the underlying APIs are designed with the view as the source of truth. That’s almost always the opposite of how you’d want to design a system with more than a very small amount of complexity. But that’s where inertia will guide you because there isn’t even a notion of state that doesn’t reference the DOM etc.
Once you’ve succumbed to this even partially, composition becomes incredibly difficult because the underlying model leaks implementation details. Tangling them is not just easy, it’s the default. Avoiding tangling them means basically developing a UI library with its own opinions and idioms. Which maybe you want that, but most people are building something else.
Untangling them is an enormous task. I’m maintaining an application that began in the era when this was common, and picked up some notion of components along the way. Even just understanding how things get invoked can take hours or days tracing app code and its interaction with implicit state in the view, and that’s with two years of familiarity with the code.
I don’t even like React or several of its idioms. But stuff that takes me hours or days would take minutes to understand with just the basic assumptions React or any other component library would afford. I can’t speak for any specific commenter, but I think this is the kind of “scale” most UI devs mean when they discuss it in those terms.
And granted, the critique that many things don’t need the scale they take on—that they add incidental complexity to fit a library/framework’s model. That can certainly be true, but I think the “vanilla JS” camp really underestimates how steep that cliff is and how quickly many projects can run off it.
Back then, people fell in love with GMail and suddenly everyone thought they were building another GMail. This wasn't true. Most people were building an app with a couple of forms, a datagrid and maybe 2 highly interactive pages.
PHP, Python & Ruby frameworks gave perfect support for all this >10 years ago. You had jQuery plugins you added to page in 30 minutes and you had validation. In 2 hours you had a datagrid. Autocomplete, datepicker, things like this was no problem.
It was a form of egoism all the time.
Coding Sign In page was work for less than an hour. Now, in React, it's 2 days.
Look at developers now and compare them with senior devs a decade ago. My estimate is that development today is 4 times slower. Given a growth of salary at least 50%, a system back then in MySQL, jQuery, Django or Zend Framework for $40,000 is now $240,000 in React with GraphQL, Mongo, etc.
It's my observation as someone who leads developers well over a decade.
Development just got way more expensive, slower to get app-like feel. All this when >80% of pages in almost any webapp could be server-side rendered without big (or any) sacrifice of user experience.
It's so tiresome. I hate Go but you don't see me bringing it up every time someone mentions it. For some reason it's irresistible, I guess because they know the choir will like the sermon.
You can actually measure the amount of dollars a language / framework / tools generates in real business applications by looking at how hated it is on HN.
Removing complexity where you can is a good thing. Being able to recognize when you don't need a complex system is a skill. Many devs fall into the "One tool for every problem" trap by defaulting to the same boilerplate project for everything (eg create-React-app or Next.JS) and end up making something complex when a much simpler system would have worked better.
If you have a basic project the tools should be basic.
Your tools should be as complex as they need to be. For most apps, that is a lot simpler than the developer has made them.
The inverse isn't true because as soon as you actually need complexity your basic tools stop working. The "smug superiority" of the original post here is an admission that the author didn't need complex tools. The fact they recongized that, even if it was for the wrong reason if you're right about the smugness, is a good thing for their users.
So now that you've said React is indeed useful for complex projects, what relevance does the original post have here? It does nothing except clog up the comments with people tooting their own horns about how amazing they are for not using it.
When every new hire runs "npx create-react-app" without thinking as the first step of any solution to any problem, avoiding unnecessary complexity because you don't chase fads seems like a superpower.
There are times where React/Vue/SPAs are warranted. It's not 100% of the time, however.
Small "unless" and you are forced to make all your APIs generic because there might be many clients.
Small "unless" and you'll ignore all power features of your database and dumb-down your approach to data because user might want to switch a database.
Small "unless" and you will make your app ultrascalable even when you have no proof there'll ever be more than 100 users.
This is a disease that makes development slower and more expensive even when 95% of time, the customer needed something fast and cheap. No, most devs aren't building another GMail, most devs are building something that could have been modelled in 2 weeks in Visual FoxPro 25 years ago.
Well, it does require some though about SPA or website upfront, but will save lots of work and time to being online. I guess we can at least demand that much thought about things, instead of jumping immediately to SPA and causing weeks and months of more work.
I have seen it. It is all "But React has this built in!" and "React does this nicely!" until it comes to actually implementing components. Without a need for interactive widgets to avoid page reloads and avoiding becoming a non-SPA again, it will take a lot more time to get things done with React, that it would take to simply churn out server-side rendered templates the traditional way. UIs that could have been done in 2 weeks the traditional way take suddenly multiple frontend devs a few months, with things like the back button not working correctly.
Specifically for internal tools, this is a much efficient way.
With anything more than html, css the complexity is not worth the return.
We've done away with everything that needs internet to build or deploy (npm, dockerhub, brew, whatever). Primarily for the security theatre around package updates.
So much simpler now. Backend is very well integrated with the entire ecosystem. Exact same setup as production. Folks who build internal admin tools tend to (and they should) know that part much better.
Everything is instantaneous.
We avoided all frontend libs. Some (like moment.js) needed extra work on the API side, but that took an hour at best to find an existing backend method to use.
All of the admin UI stuff is like < 100 kb. In 1 repo. Everything works without javascript, in all browsers (including lynx).
Night and day contrast against all previous versions where we used a mix of jquery, then angular and finally react with all their baggage and unexplainable dependencies to utter dismay.
Clearly the case of using the wrong tools but good lord did it take a while to get rid of the FUD around html only tools.
Ironically I opened this up hoping to see the first comment was "just don't use React" and was even more surprised that it is exactly that and also what I've been doing for a while.
I also wrote a < 0.5Kb DOM abstraction that basically just saves a bunch of typing (get element, replace element with something, go fetch some shit off the server, add style, remove style) and that covers about 90% of the "would be nice if it did this" use cases.
This all gets compiled into one binary file, resources as well, chucked in a docker container and pushed to Kubernetes.
Makes sense, you were creating static pages but were using a tool that is dramatically overengineered for that use case.
I would've switched to Astro for that use case, mainly because you could still leverage your understanding of React/Vue/Svelte/whatever within those mostly static pages very easily, plus the markdown support is brilliant for internal tooling.
Why not use something like Retool? IMO if you’re building internal tools from scratch like that there’s a 99% chance you’re spending too much time on them.
Yes! Thank heavens people are finally starting to see the light. All these nonsense “modern” frameworks with their broken layers of abstraction need to read that article by Joel spoelsky on leaky abstractions.
And don’t be afraid to use this approach outside internal tools.
This is how most of the FrontendMasters.com website is made. Go/Hugo templates and vanilla JavaScript. People are always shocked at how fast our website is. Write the code necessary for the job at hand.
No? External changes to variables trigger reloads too, it was quite a nice experience coming from back end and hobby game dev.
Now, the reactive blocks, where an update to _any_ variable used in them trigger the re-evaluation seemed rife for abuse - particularly when the variables could be brought in from other files, but I forget the mechanics behind that.
I used it plenty of course. Forgot how it worked the day after I stopped working on the project though.
Edit: unless you mean lines like `ultrasonicDetectedDistance.update(v => v = distance)`, which yeah was an interesting quirk. Not enough of a pain to go with something like React, thought that wouldn't meet the latency requirements for this project. TBF neither did Svelte entirely, but it got close.
You're using Go's build system, dependency management system, templating system (a transpiler...), etc. You're just replacing one "evil" by another "evil".
On mobile (safari) it doesn't show results as you type. You have to type your partial string and then press the dropdown selector to see the list filtered by your string.
Sure, so if you need more functionality or different styling they won't work. But I suspect many devs reach for a JS searchable dropdown replacement without even bothering to ask the question of whether they really need something else.
Okay. I'll explain it to you. It basically comes down to a server-client architecture. The server (db, server side code) is the backend, that the user never gets to see. The client (basically the browser - js, html and css) is what the user get's to see, not just through the interface, but by selecting "view source".
So PHP and Rails are back-end languages. You never get to see the code and logic that generated the page because it is "at the back". Golang, which the poster mentioned, is also a back-end language. So if the core of your apps logic is at the back-end (server), what you are practicing is back-end dev. If the core is in the front (e.g. SPAs) then it's front-end dev. Sometimes the complexity can be split 50-50 between the back and front. But if your web-application just uses html, css and a sprinkling of JS, then it is back-end driven. Another category is a website, which does not really have any complexity whether at the back or front.
So to correct your statement, PHP and RoR have never, at any point in time been considered front-end tech. If it is not html, css and js (including complile to js languages like ts), then it is not front-end dev.
I'm not sure how long you've been in the industry. But you sound like it is less than maybe 10 years. Before react and such, you were considered a frontend developer when you delivered your javascript + html + css from any backend, though typically it would be served by php, RoR, or, more limitedly, by some python. Backend developers didn't touch html or css and couldn't be bothered to to think about js. The balance between full stack, backend, and frontend teetered on if you we're concerned with pixel alignment and UI things vs data storage, manipulation, and retrieval.
Again, back in the day, you wouldn't call yourself a backend dev if you did anything meaningful with html UI. You would still call yourself frontend even though you had to work through templating in a given backend language.
Source: I've been doing this for a couple of decades.
> I'm not sure how long you've been in the industry. But you sound like it is less than maybe 10 years.
Okay. No offence, but so do you.
> Before react and such, you were considered a frontend developer when you delivered your javascript + html + css from any backend, though typically it would be served by php, RoR, or, more limitedly, by some python.
Not really. Back in the day, before the great divide [1], the terms we used were "Web Designer" and "Web Developer". We also had "Flash Developer" but I digress. A web designer was expected to know all the front-end stuff including JS, since the front-end was not that complex. Almost all complexity was at the back-end, and that was the job of a web developer. The term "front-end web developer" simply did not exist in 2003. There was nothing to "develop" in the front end, since all complexity was on the back. Yes, there were some exceptions, but in those days, PHP was king. React is current king, and it's funny how it gets the same hate PHP got back in the day. Some people just like to tear down and burn whatever is at the top. Reacts successor will get the same hate. Thats how you know who the king is.
> Again, back in the day, you wouldn't call yourself a backend dev if you did anything meaningful with html UI. You would still call yourself frontend even though you had to work through templating in a given backend language.
Wrong. Why would someone working on PHP and MySQL call themselves frontend? So who were the backends back then? Strange thing to call yourself "front", when no one called themselves "back", don't your think? Like I said, the
terms back then were web developer and web designer.
> Source: I've been doing this for a couple of decades.
> PHP and RoR have never, at any point in time been considered front-end tech.
Okay, let me explain something to you, as a person who has been in this biz for 23 years.
What you're talking about is client-side vs. server-side which doesn't have a 1-to-1 correspondence with frontend vs. backend.
Frontend has always been about something user-facing. Backend has always been about something that is non-user-facing.
Client-side dev has hijacked the term frontend to describe purely client-side development. Even though with the exception of direct DOM manipulation there are very few conceptual differences between generating UI on the client and generating the UI via PHP/RoR.
> Okay, let me explain something to you, as a person who has been in this biz for 23 years.
Since you've brought up your experience, what exactly does "in this biz" mean exactly? What was your job title 20 years ago? 15 years ago? 10 years ago? 5 years ago? Now? If you've really
been in the industry that long, you should have noticed that the job titles also evolve. Back when all the complexity was in the server, and JS was just a baby toy language and not the
beast its evolved into today, the job titles were very different than they are now.
> What you're talking about id client-side vs. server-side which doesn't have a 1-to-1 correspondence with frontend vs. backend.
Just google "front-end" dev, or even use wikipedia [1]. The client-server architecture even pre-dates the web, but when it comes to web developement, the front end is css, html and js.
Nothing more, nothing less. If you do not agree, then go edit that wikipedia page.
> Frontend has always been about something user-facing. Backend has always been about something that is non-user-facing.
What do you mean by "user facing"? Can a user view the source code of a PHP generated page? How is PHP user facing? Can you give me an example of a web tech that is "non-user-facing"?
> Client-side dev has hijacked the term frontend to describe purely client-side development. Even though with the exception of direct DOM manipulation there are very few conceptual differences between generating UI on the client and generating the UI via PHP/RoR.
The term client-side dev is never used in the industry. Never. What we use is front-end developer. Go to any job ad website[2] and look for the term "client side dev", you wont find it. What you will find is "front-end dev". Then look through all the front-end dev job postings, and show me one, even one that lists PHP, RoR or Golang as a job requirement. Here are some front-end roles [3][4]. Notice how none of them mention PHP, Golang or RoR?
Then here are some back-end roles [5][6], notice how there is no mention of js, html or css?
> What do you mean by "user facing"? Can a user view the source code of a PHP generated page? How is PHP user facing?
It literally produces the website that the user is looking at.
Unlike, say, a microservice that retrieves some data.
> The term client-side dev is never used in the industry. Never.
If you paid attention to what I write you could've seen this: "Client-side dev has hijacked the term frontend to describe purely client-side development. ".
This is what happened, and you are a great example of this.
Two technologies produce user-facing UIs and sites by stringing together data from different services and presenting that to the user.
"OMG PHP runs in the server this is backend unlike this JS code that literally does the same"
> It literally produces the website that the user is looking at.
Your definition is meaningless because EVERYTHING in the pipeline literally produces everything "you are looking at" from the database to the css.
> Unlike, say, a micro-service that retrieves some data.
That data still produces part of "what you are looking at". What a useless phrase. Stick to industry definitions, yours do not make sense. And there is no language called "micro-service". I asked you to name the so called "non-user-facing" part of the web development stack.
> If you paid attention to what I write you could've seen this: "Client-side dev has hijacked the term frontend to describe purely client-side development. ".
So, old man yells at the cloud and uses his own idiosyncratic terms. What matters is not who hijacked what. What matters is that the industry has settled on the term "front-end developer". Complain as much as you want, but realize that train left the station. Go ahead and use your own terms that no one understands because "my 23 years experience", but that's exactly how people fall out of touch. And then when you say thinks like "PHP is front-end dev" people will immediately dismiss your knowledge, so you have to keep reminding them "but look.. my experience!" The term is "front-end dev", deal with it.
> "OMG PHP runs in the server this is backend unlike this JS code that literally does the same"
Old man yells at a language that can be used both in the cloud and browser.
When JS is executed in the server (e.g. Nodejs) is it part of the back-end stack. When it is executed by the browser, it is part of the front-end stack. When it executes on both, it is full-stack. Kapish?
It's simple enough: before the rise of front-end frameworks in the 2010s, web developers were indeed more of a single group ("full stack"). But even before the rise of Angular in 2011/12ish, there was already starting to be a specialisation in front-end vs back-end; some devs, I remember, worked almost wholly on the JS UIs of more front-end-heavy websites (they may have been more of web designers previously). Others concerned themselves more with the backend, databases, services, etc. As frontend technologies grew more complex (and mobile became of primary importance), the division grew.
Before Angular and co., "full stack" encompassed using HTML, CSS, and JS. What it can be fairly said to mean nowadays is debatable, but 10+ years ago, doing Rails with a bit of JS would definitely have counted.
The key skill that you're looking to pick up is actually what professionals think of as "full stack web development". That is, you should aim to understand lots of things:
- MVC web frameworks like Rails and micro-frameworks like Sinatra
- MySQL and non-relational datastores like MongoDB
- web and proxy servers like thin and nginx
- Redis! it's like a Swiss Army knife... but also Memcached
- jQuery and Haml/Sass
- Backbone and websockets
====
Basically, in 2010, if you knew how to work with jQuery, Haml/Sass and maybe Backbone (in addition to backend tech), you could be called "full stack".
And that Sep 2010 Who's Hiring post had many ads looking for front-end (or UI) and back-end engineers, meaning that it was common to be specialised at the time.
Looking back, wow, the experience/knowledge requirements back then were pretty low compared to today...
LOL! Looks like some people are silently getting butt-hurt over a simple challenge asking them to differentiate between front-end and back-end dev. If front-end dev is not your cup of tea, that's ok. Just be honest with yourself about it. Using only html, css and a sprinkling of js is not front-end dev, it is web-design.
If your output is HTML and CSS, you are full-stack dev. There are frontend-heavy full-stack devs ignoring backend with Firebase instead of proper backend. Nobody is telling them they aren't full-stack. So let's stop calling developers backend when they provide backend-heavy solution with a bunch of jQuery plugins or HTMX app.
> No react, no reduce, no apollo or graphql. No typescript, etc.
All of these bring 10 benefit but add 12 problems back. It makes developing project slow at start, slow at medium term, and super garbage at long term. If developers get paid $100k+, I think they should be able to write good codes and have a good team instead of using these to save them from mediocrity.
If you have to really do SPA, pick something that's not bloat, not slow, not flaw .. instead of "hiring pool" BS.
I can crank out tools in minutes. No complicated build systems or web pack or dependency management system. No react, no reduce, no apollo or graphql. No typescript, etc.
Just simple go, html, css, and a bit of javascript when it's needed for a form. I don't minimize anything, or try to do anything fancy. It faster to develop in, and faster to load in the browser.
I'm specifically talking about internal tools here.