20 votes

Web developers - What is your stack?

As someone who is not mainly a web developer, I can barely grasp the immensity of options when it comes to writing a web application.

So far everything I've written has been using PHP and the Slim microframework. PHP because I don't use languages like Python/Ruby/JS that much so I didn't have any prior knowledge of those, and I've found myself to be fairly productive with it. Slim because I didn't want a full-blown framework with 200 files to configure.

I've tried Go because I've used it in the past but I don't see it to be very fit when it comes to websites, I think it's fine for small microservices but doing MVC was a chore, maybe there's a framework out there that solves this.

As for the frontend I've been trying to use as little JavaScript as possible, always vanilla. As of HTML and CSS I'm no designer so I kind of get by copying code and tweaking things here and there.

However I've started a slightly bigger project and I don't fancy myself writing everything from scratch (specially security) besides, ORMs can be useful. Symfony4 is what I've been using for a couple of days, but I've had trouble setting up debugging, and the community/docs don't seem that great since this version is fairly new; so I'm considering trying out something more popular like Django.

So this is why I created the post, I know this will differ greatly depending on the use-case. But I would like to do a quick survey and hear some of your recommendations, both on the backend and frontend. Besides I think it's a good topic for discussion.

Cheers!

27 comments

  1. [3]
    unknown user
    (edited )
    Link
    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...

    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.

    6 votes
    1. Akir
      Link Parent
      I gave up on Angular on multiple occasions. I tried picking it up two or three times, at once even purchasing a training course on udemy. The structure it requires is extremely unusual if you...

      I gave up on Angular on multiple occasions. I tried picking it up two or three times, at once even purchasing a training course on udemy. The structure it requires is extremely unusual if you aren't used to it and I feel the documentation aimed at first time users is woefully inadequate, basically saying "do things this arbitrary way because we said so". The training course was much better because the instructor would explain why things were structured the way they were, but at that point I found it difficult to learn because of how complex it is.

      The last time I gave up on Angular was when I realized that the majority of Google apps I used for work which had been rewritten in Angular were extremely buggy and slow. If even Google had difficulty getting it to work right, why should I bother?

      Vue, on the other hand, felt like a godsend. Its fast, it is much simpler to understand. You don't need to have a deep understanding on how it works and you can basically drop it in a project just like jQuery. Unfortunately, the last time I was on the jobs market, Vue wasn't very commonly used in corporate projects. At least in the US.

      3 votes
    2. dysoco
      Link Parent
      Thanks for the in-depth answer. I've actually been looking at Lumen, I might do with that plus Eloquent ORM. I'll give it a quick try tomorrow.

      Thanks for the in-depth answer.
      I've actually been looking at Lumen, I might do with that plus Eloquent ORM. I'll give it a quick try tomorrow.

      1 vote
  2. unknown user
    Link
    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...

    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.

    4 votes
  3. [6]
    djfrodo
    Link
    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...

    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.

    3 votes
    1. [5]
      dysoco
      Link Parent
      I don't think Rails it's a bad choice at all. I think it has fallen out of popularity but it's probably even better than in it's prime time. I just hand't considered Rails because I don't know...

      I don't think Rails it's a bad choice at all. I think it has fallen out of popularity but it's probably even better than in it's prime time.

      I just hand't considered Rails because I don't know Ruby and learning Python seems more useful nowadays.

      2 votes
      1. [4]
        djfrodo
        Link Parent
        On the ruby/rails vs python/django question...I think python will win due to its adoption in universities. Ruby/rails was/is loved by startups who want to get to market as fast as possible. The...

        On the ruby/rails vs python/django question...I think python will win due to its adoption in universities. Ruby/rails was/is loved by startups who want to get to market as fast as possible.

        The great and terrible thing about rails is all of the magic/behind the scenes stuff it can do. Basically you get so much power "out of the box" that you feel as though you can do anything without knowing how it works. There are also usually 3 different ways to do the same thing.

        Django is the opposite. You need to know exactly what you're doing. There's one way to do it, that's it.

        When things go wrong in rails...good luck. When thing go wrong in Django you can probably figure out what's happening.

        With that said, ruby is much more fun to write.

        3 votes
        1. [3]
          unknown user
          Link Parent
          I have always wanted to get into Rails because I like Ruby better than Python (hate hate significant whitespace and dogmatism of the community, altho I love the ecosystem around Python), but the...

          I have always wanted to get into Rails because I like Ruby better than Python (hate hate significant whitespace and dogmatism of the community, altho I love the ecosystem around Python), but the "magic" has always intimidated me. It feels like trying to enter into a group uf friends that know each other since decades, so much conventions and implied things and history and context one has to learn. But maybe I try again these days given I have some free time at hand.

          2 votes
          1. [2]
            djfrodo
            Link Parent
            The "magic" you're referring to is Rails, not Ruby. After a while that "magic" fades and you'll know what's actually going on. I'd learn Ruby first. Many of the coding academies that cranked out...

            but the "magic" has always intimidated me

            The "magic" you're referring to is Rails, not Ruby. After a while that "magic" fades and you'll know what's actually going on. I'd learn Ruby first. Many of the coding academies that cranked out Rails developers a few years ago cranked out Rails developers that didn't know where Ruby ended and Rails began.

            2 votes
            1. unknown user
              Link Parent
              I do use Ruby, altho I lack a deep knowledge of it, for scripting, and for generating my website using a little thing I made for fun. It is a beautiful language, and you're totally right. The main...

              I do use Ruby, altho I lack a deep knowledge of it, for scripting, and for generating my website using a little thing I made for fun. It is a beautiful language, and you're totally right.

              After a while that "magic" fades and you'll know what's actually going on.

              The main problem for me is how long that fading away will take before I'm productive, because with Rails it always distracts me from learning it, each time I attempt it.

              I wish there was a Django for Ruby...

              1 vote
  4. meghan
    Link
    For backend stuff: I use Go / NodeJS For anything frontend: HTML / SCSS / Vanilla JS

    For backend stuff: I use Go / NodeJS

    For anything frontend: HTML / SCSS / Vanilla JS

    1 vote
  5. yamalight
    Link
    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...

    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.

    1 vote
  6. happimess
    Link
    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...

    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.

    1 vote
  7. WhyCause
    Link
    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...

    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.

    1 vote
  8. s3rvant
    Link
    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...

    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.

  9. [2]
    StellarTabi
    Link
    You should consider laravel. I wouldn't consider switching languages unless it was to Elixir\Phoenix.

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

    1. dysoco
      (edited )
      Link Parent
      Elixir\Phoenix looks cool but I don't think it's battle-tested enough for my likings. I've considered learning Erlang but I think it's more apt for microservices or server stuff and less for an...

      Elixir\Phoenix looks cool but I don't think it's battle-tested enough for my likings.
      I've considered learning Erlang but I think it's more apt for microservices or server stuff and less for an MVC application.

      Still though, I see many people going towards Elixir so I guess it has something interesting to offer.

  10. unknown user
    Link
    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,...

    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.

  11. welly
    Link
    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,...

    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.

  12. Greg
    Link
    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...

    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.

  13. [2]
    Ephemere
    Link
    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,...

    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.

    1. dysoco
      Link Parent
      Well that's interesting for sure! I've actually never written Perl, when I started programming Python had already replaced it. However I've heard good things about Dancer and the CPAN ecosystem in...

      Well that's interesting for sure!

      I've actually never written Perl, when I started programming Python had already replaced it. However I've heard good things about Dancer and the CPAN ecosystem in general.

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

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

  15. cprayingmantis
    Link
    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

    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

  16. skidd0
    Link
    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.

    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.

  17. b55t
    Link
    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...

    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.

  18. lobtask
    Link
    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.

    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.