Types of programming used for big sites

Ayaz
Ayaz
Hi everyone, new to this forum.

Just wanted to know what kind of programming language/software is used for sites like these:

https://www.myhometouch.com/

http://www.peopleperhour.com/

Thanks for reading!

Comments

  • roto
    roto
    |-/ Posts: 12,958
    That intercom chat overlay is really getting old...but good on them. I see it everywhere.
  • calder12
    calder12
    Senior Member Posts: 13,496
    HTML/CSS and Javascript. There's nothing special being used in either. For that matter they're both bloated pieces of crap at the code level but that's just my opinion.

    And fuck that Olark plugin, I despise shit that throws errors on my sites.... we use it on one of ours and it pisses me off every time I work on it.
  • mayawallis
    mayawallis
    Hey,
    You can go to https://builtwith.com/ and check any website for the technology and languages used
  • calder12
    calder12
    Senior Member Posts: 13,496
    Built with won't always give you an accurate report, and it won't give you the backend at all.
  • Shiro
    Shiro
    社長 Posts: 15,053
    Built with won't always give you an accurate report, and it won't give you the backend at all.
    It listed the Yii framework for people per hour, and I know it generally gets Drupal for Drupal sites.

    There are often identifiers in the HTML that point at the backed system being used.
  • calder12
    calder12
    Senior Member Posts: 13,496
    If I remember right twitter is Scala, it still lists RoR. I guess some of it still is, but I didn't see Scala in the list at all.

    I also know for a fact it's failed on a few client sites I (or previous employers) have built. It's good, it's not perfect.
  • Dusty
    Dusty
    You Ecks Posts: 11,550
    C#
  • subtlestarling
    subtlestarling
    New Old School Posts: 1,612
    Sites with complex business logic usually move away from traditional CMS towards frameworks. Rails, Laravel, Flask, Symfony etc. Others go for a more 'from scratch' route using nodejs packages or Go for example. Those can fail spectacularly when technical debt kicks in.

    Depending on who you are talking to you'll also hear about 'microservices' where each aspect of the site is completely separated. Eg the app authentication runs on one server, search runs on another, logging on another, etc. This is 'web scale' and most websites/teams wouldn't justify it.

    Personally I'm happy with Rails for making coding fun again but damn is it slow if you don't spend ages tweaking. Elixir/Phoenix is on my radar because it is 'Rails like' (sort of) but also insanely quick, reliable as a brick, supports concurrency out of the box and has other nice toys. It isn't hugely popular yet though.

    For others I'd recommend going with the one with the best balance of productivity / speed / ecosystem / dev availability. Php fameworks tick all of these nicely despite what anyone says.
  • Limbo
    Limbo
    Established Norm Posts: 27,388 edited October 2016
    technical debt

    Care to expand on this? You talking about site maintenance?
  • switchMode
    switchMode
    edited October 2016
    (I'm subtle, new account)

    Site maintenance is part of it, depending on the package management system and quantity/maturity of the libraries you used - even something as simple as npm update can take an entire afternoon - or longer. And if you rely on many packages (node seems to encourage this) what happens if one of those many libraries you were relying on gets abandoned? LeftPad was hilarious but a good example of what can go wrong with even very minor packages.

    Another aspect is code quality/style. Last I checked Node JS doesn't enforce strong coding conventions (configuration over convention). This means hopping into a new project or even an old one of your own can mean a lot of hunting through code just to get started. If you expand that to company scale - especially one where the people that originally wrote it have left or weren't very good, well it can get messy. Developers like writing new code, not understanding old code - so you can end up with layers of code that no one understands.

    Course, that is true in any language or framework, Rails-like frameworks just tend to be more pushy about eg putting your models in *here* call them *this* and you talk to your database using *this* or *that*. You can bend it a bit, but its quite easy to tell when you aren't doing things the intended way because it gets very hard very fast. This isn't great for everything or everyone (not all apps can be made to work in a traditional way) but for new-ish developers and most projects this is usually a good way of knowing where things are, and usually (rails can be ambiguous due to magic) where to look when you want to find something.

    Probably worth noting I'm talking about big sites here, although even on my wordpress sites I tend to put things in the exact same places in every project.
  • Limbo
    Limbo
    Established Norm Posts: 27,388
    Yeah. I get this a lot. Working on an existing project/site. Doesn't really matter if it's very big (assuming it's using CMS or something). It's really hard to both document and track work/changes IMO. Even with GIT and the best intentions there's going to be 'technical debt'. I'm fairly festidious about code, but I'm also continously evolving - so best practices/code/systems now are not the same as 4 years ago so it's bloody difficult.

    What would you say are the best tips for keeping projects as 'evergreen' as possible?
  • switchMode
    switchMode
    edited October 2016
    I can only speak about my own experience which doesn't involve large teams - but it does involve full stack over a range of platforms and at least one Rails site with six figure monthly views and seven figure yearly sales. There was another but I handed it off - it was a bit much to support two sites like that.

    For the first couple of years every project (mostly wordpress or opencart) would basically be done from scratch, I'd rarely carry anything over because I didn't feel like anything was done well enough last time to build on. Also because writing code was still new and fun (ha).

    When I left my salary job (early 2013) to go it alone I took an early version of my system with me, for an example of how rough it was at the time I had one giant less file and one giant js file, with just a fairly unique way of arranging them. I still included bootstrap although by that point I was barely using any of it.

    Since then I went through grunt and later gulp, moved to sass and es6, formed my own naming and folder systems and slowly built up a frontend framework that can literally be copy pasted from one project to another and do just about anything. It's fairly stable but I will occasionally swap something out, like the most recent version has replaced jquery with zepto. Backend is a different story ofc, but similar stuff can be done.

    I've built in the range of 100 sites with this frontend while freelance (holding pages to largish ecom) and right now I'm using slight variations of the same framework (semi) actively on about 30 sites. Sometimes I have to work on something a bit older and I'll spend some time bringing it up to speed (within reason, not really worth spending 8 hours on maintenance for a 20 minute update although it is tempting). It's served me pretty well so far and I don't really have any problems working on my own old sites,

    I'm not including angular, react, webpack, etc at the moment but if something sticks around for a while (like 2 years+) I'll eventually pick and choose what works well with my flow. If I was in a studio or contracting where I didn't have a choice about what tech I used and forced to interact with others code I might be a 'better' developer - but I don't know if I would be able to put something solid together as quickly as I do now.

    Christ this post got long, okay one other thing to say. Don't try to be 'clever'. Every time I've had a late night stroke of genius to solve a problem with some dense complicated code and come back to it later it's taken ages to unpack what I was thinking/trying to do. Often I end up rewriting it in a clearer way. Writing clear, simple, generic code seems to come with experience. It isn't sexy, but imo it makes for better options when you need to expand or make it do something quite different 6 months+ later.
  • switchMode
    switchMode
    edited October 2016
    Other thoughts
    • Keep dependencies down (solve your own problems where reasonable)
    • Don't take on other peoples code, or if you do vet it first
    • You can think of code for each individual project a bit like code for one never ending project - each project being an iteration of the last
    • Copy-pastable code is good code
    • No code is the best code
  • Limbo
    Limbo
    Established Norm Posts: 27,388
    Thanks for this, useful.

    I've got a similar method - only on a more basic level (we have a thread about that too... I'll dig it up).

    I don't use react/gulp or anything as useful as that right now — seems to me that dependencies on these (sometimes) newfangled libraries/processes could cause long term headaches. So I have a stable set of files/folders set up: css/images/sprites/includes/common modules/page type and code snippets + a quick to boot install of EE. And all of the source files for them (AI, PSD, SASS etc). Tested to IE9 + an easy to work up IE8 conditional.

    I use a simple SASS library for imports, variables etc etc and have a jQuery script that accounts for 95% of most sites day-to-day interactions. I use GIT but I don't have any other system of deployment than (s)FTP right now. It's still quick enough for me, because it's simple, but would be annoying for teams.

    I would however like ot be able to compile SASS files on the server - that would make maintenance on staging before moving to live much easier...

    100% agree that the framework should be constantly evolving to meet new and reliable methods, functionality or standards. Mine is updated after most builds. Even if it's to rewrite a small section of code to cover off an obscure browser bug. Stable/Repeatable is the key. Right now it doesn't use too much of HTML5s really useful tools like flexbox/grid but I've started to iterate with those in testing on site's where the audience is less likely to be in the dark ages.

  • Dusty
    Dusty
    You Ecks Posts: 11,550
    I've started using flexbox for the general public this last week. Dropping support for ie9 now. The future is here!
  • switchMode
    switchMode
    Limbo wrote: »
    I don't use react/gulp or anything as useful as that right now — seems to me that dependencies on these (sometimes) newfangled libraries/processes could cause long term headaches. So I have a stable set of files/folders set up: css/images/sprites/includes/common modules/page type and code snippets + a quick to boot install of EE. And all of the source files for them (AI, PSD, SASS etc). Tested to IE9 + an easy to work up IE8 conditional.

    The way I use it something like gulp just takes files, transforms them and puts them in a different folder. So for JS this might be as simple as just minifying it and copying to a new folder. As long as you use popular stuff like SASS (and keep it simple) it would be trivial to swap out gulp for anything else, even a server side version of the same process.

    When it comes to stuff like webpack or brunch what I'm getting is the impression of complexity/magic that doesn't actually help. It's one of the reasons I haven't made the jump to them. Trying a webpack example recently just had me shaking my head. Gulp is easy to read + get my head around and very configurable.
    Limbo wrote: »
    I use a simple SASS library for imports, variables etc etc and have a jQuery script that accounts for 95% of most sites day-to-day interactions. I use GIT but I don't have any other system of deployment than (s)FTP right now. It's still quick enough for me, because it's simple, but would be annoying for teams.

    The system I have at the moment is to work directly on the local version and use git (either directly or through capistrano) to deploy to the server. I did use ftp a long time ago, but having to either reupload the entire folder or hunt through and find the edited files did get to me in the end. Also being able to jump between branches or rollback if a bug is found is very handy.
    Limbo wrote: »
    I would however like ot be able to compile SASS files on the server - that would make maintenance on staging before moving to live much easier...
    I did use a php library to compile LESS (before I used a js build flow). But these days I just add the compiled .css file to the git repo. What sort of maintenance do you mean?
    Limbo wrote: »
    100% agree that the framework should be constantly evolving to meet new and reliable methods, functionality or standards. Mine is updated after most builds. Even if it's to rewrite a small section of code to cover off an obscure browser bug. Stable/Repeatable is the key. Right now it doesn't use too much of HTML5s really useful tools like flexbox/grid but I've started to iterate with those in testing on site's where the audience is less likely to be in the dark ages.

    I've been using flexbox for various things for a while, I think it's pretty safe. There are a few quirks like the way margin:auto works on various browsers. It's usually for vertically centring/spacing things in a predictable way. Audience size and demographic plays a huge role though, luckily I usually get to make stuff for recent browsers.
  • calder12
    calder12
    Senior Member Posts: 13,496
    I agree Webpack is complex, I've only used it running through tutorials that use it and I'm not seeing the huge benefit. I know it can do a lot more than Gulp like keeping dev and production builds etc, but it just isn't that relevant to my workflow, at least not right now.

    I have an interest in React, have played with it a few times but never done much in it. Maybe someday I'll find the time and get the urge to really dig deep but not now.

    I only have a few projects left that use FTP and I cringe every time I have to update one. Just always makes me nervous, will I forget a file, what if production breaks and I have to roll back? Honestly GIT or Capistrano (God I love my WP Cap installs) make life so much easier.

    I do the same thing as Joe does with SASS files, the compiled files are part of my repo and deploys. It's not perfect for teams, but it works just fine for single users like me.
  • calder12
    calder12
    Senior Member Posts: 13,496 edited November 2016
    *double post
  • damponting44
    damponting44
    As far as I know.
    [1]Google
    Main:C++, Python, Javascript
    Other: Go, Java, Objective-C

    [2] Facebook:
    Main: PHP, Hack, C++, Javascript
    Other: Java, D, Objective-C

    [3] Yahoo:
    Main: C++, Objective-C
    Other: Python, Java

    [4] Amazon:
    Main: C++, Java(AWS + Data)
    Other: Ruby

    [5] Twitter:
    Main: Scala, Java, Ruby
    Other: Go

    [6] Square:
    Main: Scala, Java, JRuby

    [7] Airbnb:
    Main: Java, Scala

    [8] Uber:
    Main: Node.js, Python

    [9] Linkedin:
    Main: Scala, Java

    [10] Tumblr:
    Main: PHP, Scala.
  • cybernext
    cybernext
    CyberNext Posts: 9
    It really depends on the website requirement. What all functionalities are required.

    Government websites use mostly Java, .net.

    For small websites PHP is considered as the best one.

Sign In or Register to comment.
© Copyright 2003 - 2016 - DT by Kooc Media