Really depends on the context.

Client

Personally, on the client, I'll either go with or Vue, Angular if I'm needing to develop a complex application, or if it's something simple, I'll usually just through up a static site either with a generator like Hexo, or hand-build it myself and rely on Vanilla JS where necessary.

I find Angular to have a difficult learning curve, and being quite late in the game to the "full-fledged JS SPA" race, well behind React; it doesn't have quite the mindshare as other frameworks—this is a double edged sword. Given I'm well-versed in the framework's nuances, it makes applying my skills professionally quite a rarity; but when I have found Angular-based work, the pay is fairly good precisely because it's such a niche solution.

Vue is very nice to work with; it's far more forgiving to you as a developer, has a very nicely polished CLI, and isn't opinionated like Angular is—if you want to just use Vue a bit in an existing project, Vue lets you do that. Angular on the other hand effectively requires and expects your project to be totally built within its confines.

I am actually a bit of a hypocrite on this front, considering I've previously posted comments like this gem right here on Tildes espousing the benefits of not inverting the web pyramid. Sadly, inverting the web pyramid pays—literally. I am at the end of the day working not only within the confines of a particular technological stack, but also at a product manager or technical director's discretion, and they may have salient business reasons to tie their future development to a Javascript client framework.

For small projects, like I was explaining above. It's either a static site generator that parses Markdown & EJS files into HTML & theming files respectively; or it's hand tweaked. This is normally usually all personal projects.

Server

Honestly, I really like working with Laravel. Say what you will about his opinions, but Taylor has created a really nice encompassing PHP framework with a good set of CLI tools (php artisan) to work with. It fully encapsulates database migrations, seeding, an IoC container, dependency injection, typical MVC best practices, etc. It has a vibrant community, lots of packages and paid extensions, and abstracts away quite a bit of horror that you normally would associate with PHP (looking at you, array_walk, etc). I haven't tried it myself, but Lumen seems to be a nice microframework if you just want the basics of Laravel without all the unnecessary tooling.

For smaller professional projects, some personal ones too—express.js or any Node web server works just fine. Javascript on the server is fairly painless to work with now that we're a few years past callback hell.

I have worked in a Windows Server shop a few times, in fact, my upcoming new job is mostly Windows Server-hosted. In these instances, ASP.NET Core works well; a lot of the concepts are transferrable from Laravel, such as dependency injection, and service management, just with some better typings. I do overall prefer strongly typed languages, even if I don't work with them professionally all that often.

Package Managers

I pretty much exclusively use Yarn if I'm dealing with a Javascript project. I did start out "by default" using npm; but I saw the announcement of yarnpkg on HN, gave it a go, and was visibly faster. I don't think I looked back. For PHP, the answer would be composer. When I've worked with C#, obviously everyone usually chooses NuGet.

Mine is mostly HTML/CSS/JS. I work off the assumption that, most of the time, one could still make good design without relying on the fleeting external supersets of code. That, and I get easily confused by vast design systems that don't align with my thinking process; either it works for me, or it can't. This usually means I write my own utility code.

I'm not the kind of an asshole who would chastise anyone for using jQuery, or Bootstrap, or Pug, or whatever others may find useful. I frequently use JS libraries when I'm in the rapid-prototyping stage, just to make the thing work before making it work well. I also use LESS, the CSS preprocessor, from project to personal project, and am eyeing Caffeinated Style Sheets. LESS appeals to my idea of doing more with less, even though it's the same CSS in the end; I wish CSS was a lot more like some of its preprocessors for the reason stated above. But, since that ain't happening any time soon, I'm okay with using LESS during development. (Never for shipping: my website only has .css for styles.)

But, yeah: the less technological overhead, the better. I've said it here before: if it can be done more plainly, I will spend time in an effort to achieve that.

For front end stuff on a non complex site I can't see how meghan's choice isn't the best - just HTML, SCSS (or sass), and Vanilla JS.

I actually still use JQuery with simple css, and to be honest it's great.

For the back end, weirdly, I'd probably go with Rails. It's got all the ORM and migration stuff you need and the language is fun as hell to write.

I learned how to program using PHP, and it's great, but I certainly wouldn't want to go back to it.

I'd stay away from Java unless you're really going to get complex or need high scale.

Personally if I were starting and could give myself advice I would say "stay the fuck away from node" - there are too many frameworks, dependencies, build chains, package managers, etc.

But it's what the kids like today.

Do what tildes.net did - skip the "cool" new frameworks and go for a simple MVC server side framework (Django, Rails, Laravel, etc) with a lot of javascript for the UI. Keep the database stuff as simple as possible.

Hope that helps.

p.s. I made a version of reddit/tildes in rails: headcycle.com with basically the above advice.

For backend stuff: I use Go / NodeJS

For anything frontend: HTML / SCSS / Vanilla JS

I primarily work on web-oriented things. For the past ~3-4 years my goto stack was Node.js on backend (with express / fastify / polka depending on requirements) with React on frontend (majority of time with Next.js). Javascript has grown to be one of the most versatile languages out there. The stack works equally good for building web apps, creating mobile apps (react-native is quite good), even processing terabytes of data (~1TB was the largest dataset I worked on so far).
I also occasionally work on ML/AI-related things and while I'd love to stick to JS - so far python and java are winning in this area (at least library-wise). But that's mostly related to data processing rather than web bit of the services.

I've been writing web applications for more than a decade, mostly on the back end. I've been paid to work with Java, Javascript, PHP, python, F#, and a couple of proprietary languages that nobody's ever heard of (any Focus devs around here?).

If PHP is working for you, then definitely stick with it and follow the advice already given in this thread. It's a good enough language, and lots of great software has been built with it.

However, I was introduced to F# at my current job, and if you're looking to make a switch, I can't recommend it enough. We have lots of complex code and hundred-line functions (business logic gets crazy!), but it all looks something like list of objects |> filter |> transform |> transform |> filter |> wrap it in a bow. Once you get used to the style (and to be sure, coming from most other languages it looks weird), it's very easy to figure out what's going on in unfamiliar code.

Also, the .NET core tooling[1] is now fairly mature and easy to work with on any OS. mkdir myProject; cd myProject; dotnet new mvc -lang F# creates a web application based on the fast, stable, well-documented .NET MVC framework. Access control, server-side rendering, swagger documentation, and all kinds of other stuff is easy to put together. You also get access to the .NET ecosystem, which includes solid libraries for basically anything you'd want to do.

Take a peek at F# For Fun and Profit and the .NET Core Guide if you're interested. I love working with it.

[1] Sadly, there's three separate runtimes: .NET, .NET core, and mono. That part can be frustrating, but I recommend .NET core. Pick one and stick with it.

I eschew frameworks, sticking with vanilla js and jQuery (primarily just for element selection and AJAX), lots of semantic HTML, and plain old CSS on the front end.

For the backend, I use Python (via Flask) exclusively.

I primarily write simple web applications for my company such as their training website, laboratory data entry, operator field readings, etc.

For the back end we run Ubuntu Server with some bash scripts running background tasks and PHP / MySQL for server side data. I do not use any frameworks for these.

On the front end it's the standard HTML / CSS / JavaScript though I prefer to avoid JavaScript where possible (aka most of the time). I do like to use the jQuery framework for these.

You should consider laravel. I wouldn't consider switching languages unless it was to Elixir\Phoenix.

I haven't done something like this for years after deciding to go with humanities, but if I wanted to go back today I would Django & Scss & plain JS/CSS/HTML. Python is not my favourite language, but it is good enough, and Django is nicer to work with than Rails.

PHP, with mainly Drupal, occasionally Symfony. And the usual front end rubbish (scss, jquery). Nothing modern whatsoever, but stable and reliable. Been using this stack for over 10 years, previously I dabbled in Rails and a few other PHP frameworks (Cake, Zend) but have settled on Drupal for the vast majority of work.

I was a Microsoft developer for 10 years prior to all this and am glad to see the back of it.

Node/Express/React/Postgres - my opinions differ in a few ways from the prevailing themes I'm seeing here (albeit with the same overall goals), so I figured I'd throw them into the mix!

I think that:

• Writing the UI once in JS guarantees consistency between client and server; it's faster to build, and reduces the chance of errors if and when code changes get out of sync.

• A data driven UI is more robust and testable in general than using vanilla JS and manually keeping track of changes.

• ORMs tend to be leaky abstractions. I've yet to find one that handles large or complex structures as well as hand-coded SQL, and I've found that they hide enough of the details to bring their own class of hard-to-find bugs into the mix.

• You can still build a site in React that performs perfectly with browser JS disabled completely, if that's one of your requirements. Even if not, you should absolutely be building the full HTML on the server and passing it down along with the state object to the client.

I'll add that I also drive all of that from Clojurescript, but I wouldn't in good conscience recommend that to a new web developer nowadays. The advantages are fewer than the used to be now that JS has matured further, and the ecosystem adds complexity if you're not already familiar with it.

I work in a perl shop, so I suppose we have a somewhat interesting one. On the backend we've been using Dancer, hosted via plackup/Starman. I've heard some very good things about mojolicious, though at the moment we haven't really hit any pain points using Dancer. It's easy to code, talks HTTP/HTTPS just fine, and pretty much all of our delay has been due to application logic.

On the front end, we've been using Extjs, mostly because it seemed a good choice for working with tabular data when we started. It's pretty unpopular these days, but as it's been serving our needs and our team knows how to work with it, so I see little reason to pick up something different.

I've been really looking forward to exploring some other stacks, but the above is more or less satisfactory as far as I can tell.

Generally Ruby on Rails, with bootstrap for our HTML framework, SASS for css, and vanilla JS.

For work:
Front end: Angular 6
Backend: Python, Node, and Salesforce

Hobby projects:
Front end: React Native, Angular 6
Backend: Laravel, Node, but wanting to rewrite the PHP into Elixir/Phoenix

Currently running some fun hobby stuff using a React frontend with Lisp backend, Postgresql, and nginx. Very fun to work in.

For lisp, I use snooze to handle routes and postmodern for SQL stuff.

Postgres if I need a DB (via an ORM, because lazy), Go is the server, HTML / CSS / Vanilla JS in the frontend.

I learned these languages in a weird order and taught myself everything off online courses, so what I create is probably any CS-Major's nightmare, but I'm slowly getting some more interesting stuff to work now.

I use libraries for prototyping things quickly and then roll my own where possible. With security I stick to what's established, as I really don't want to mess with that stuff.

I may one day forego the ORM (gorm in my case), when things get more complex, but for simple CRUD it works.

My main struggle is organising my JS code in the frontend in an orderly fashion. Originally, I would have thought that a JS frontend would be much easier to build and maintain than the DB or server. Bizarrely, however, it now turns out that I find the DB / backend stuff to be really well structured and easy to maintain (because Go kind of forces you into good practices as a newbie), while the JS frontend is this crazy nightmare of a million DOM elements, functions that are very hard to DRY, all with special cases and tons of exceptions to whatever patterns you try to establish. I have been trying to structure it well, but I find that very difficult to do.

HTML / CSS feel quite natural. HTML is the easiest thing to work with ever and CSS starts to make sense once you understand its quirks.

Front end is just HTML/CSS and minimal JS when needed. Backend is Golang, though the language could really use a Django or RoR like framework for it.