The stacks run deep on both ends .. but I'm often not sure to what end.

Serving a static site on S3 can make you hundreds of millions of dollars. Of course thats because you put a metamask plugin and cater to crypto people and don't even have to build a backend to do anything impressive there.

But its scalable enough!

[0] https://lichess.org/forum/lichess-feedback/hardware-of-liche...

Our latest MVP - https://www.code-scope.com lets one interactively analyze and document GBs of source such as linux kernel.

It runs on Digital Ocean's $5 instance, build just with Jquery - bootstrap4.

The app binary that runs code-scope.com website is < 10MB including all the frontend and backend code.

Good old tech such as jquery works very well for us.

Complex js front-end tooling is a choice, not a requirement for develop web app.

I still annoy people by talking about my time at the high frequency trading firm, because working there was a revelatory experience. They were operating at a scale and velocity far beyond any place I've worked at, with lower tolerance for downtime, and very little hardware, relatively speaking. The traders had fun, of course, but it was frankly kind of boring to work there as a techie, what with everything ticking along so smoothly all the time.

And the way they got there was through an absolutely fanatical devotion to the KISS principle.

I've come to think that scale out is a self-fulfilling prophecy. If you choose a solution that's designed to support scale out, then all the mechanisms and limitations (yes, limitations) it needs to adopt in order to make distributed processing work will impose a burden of overhead that you will need to offset by scaling out.

I haven't seen any certificates that replace sweat and hard work yet, except in organizations where they cannot keep track of individual developer performance and simply count certificates.

There was a lot of homegrown software where others would use a library. That was deliberate. If you need five features, but choose an off-the-shelf package with 5,000 features, pretty soon you'll find that the list of features you're using has grown to 50, then 500, and so on, even if you don't actually need any of it. If a toy's in the box, the kids will play with it.

Maybe one thing to try is to focus on imposing constraints, and making people live within them. RAM, # of CPU cores, whatever. Software is like a gas. It will naturally expand to fill all available space.

What I do is put my database on a droplet and my files on another and it can handles millions of requests. Put them on the same machine and I need to increase ram higher than the cost of multiple small droplets.

If you ever reach those limits consider setting up a load balancer.

All the web queries are responded in <<< 1 second - so far....

That was 4 years ago and beyond basic patching they've barely touched their infrastructure and it runs around $100/mo.

Ok but is that static site primarily generating the $5B in revenue ? That's more relevant to know. Having a static site for a business where the revenue is generated elsewhere is not that big of a deal in my opinion. Yes I get your point that the $5B company is hosting a static site on S3 which is cool but what will be cooler is if THAT static site is the primary revenue driver. I bet it isn't.

Actually probably the output would be worse, because there's a significant amount of domain knowledge in building an effective website in this space. The only companies that are effective at it do it in house or go to specialists in the space.

Car dealership advertising is actually extremely similar in this regard. There are just a few big players working with hundreds to thousands of dealers.

- Insurance

- Loans

- Mortgage

- Attorney

- Credit

- Lawyer

- Donate

- Degree

- Hosting

- Claim

Still can't see it. But just to be sure, you're saying that the $100/month website was directly generating most of that $5B?

And not, for example, being just a bridge between users and an army of attorneys?

Keep in mind that a large number of law firms in this space do not try cases and just generate and sell leads.

Yes, obviously there's a lot more that goes into it, but my point was that websites can be extremely simple in their infrastructure and still be extremely effective.

I've talked at length about it before in comments. Not really looking for the repeat discussions.

Not that I wouldn't do it, a lot of times it does make financial sense.

Tbh, I find most engineering orgs don't have the competency to pull it off.

Consider for a moment that other people might in fact not be idiots, and might have legitimate reasons for choosing particular technology stacks that your snarky attitude has missed.

I've considered it many times, but I continuously find evidence to the contrary.

AWS has an absolute tonne of great and not so great services but you can easily use the basic stuff to get quite simple and cost effective solutions. You can YOLO it on the console and not even worry about cloudformation if you want, and if you have no customers it will likely be free tier to boot.

Even then, your founders might have made a bad business decision – which isn't unusual, and companies can often make bad business decisions, such as prioritising investment in scalability when it's not a required feature.

They can equally make good business decisions – such as rolling out a relatively standard technology like Kubernetes to gain the workflow and availability features, even though scalability is not required.

I agree that it is important to remember that sometimes "old-fashioned" approaches can be totally suitable for some use-cases, and they can be too often written off. But equally let's try not to assume that everyone who rolls out a particular modern technology stack is a gullible fool.

To be more specific: (1) they were not able to calculate the overall costs upfront. Yes there are many calculators, but you know the actual cost only when you receive the bill. Moreover, there is no hard cap on costs - people have been asking for it since 2006, and AWS was first saying they understand it's important and will take care of it, but in the end decided to ignore it.[0] Yes, you can set up alarms but that's not what people want. (2) AWS is marketed as saving on IT staff costs but it's ridiculous: you need competent staff to support it. The AWS infrastructure is huge, it's a whole ecosystem in itself, and it has its particular quirks. You definitely need smart people to run it and stay out of trouble. (3) Very often when you run a cost analysis of a particular aspect (like storage, processing etc.), it turns out the difference between AWS and, say, bare metal is enormous and, consequently, increases radically with the amount of resources used. There are several large companies who decided to move from AWS to bare metal just for this reason, saving enormous amounts of money.

Now, there are several scenarios where it doesn't matter, or it matters but it makes sense to use AWS anyway, but in my personal experience this is minority of cases I had to deal with. I have nothing against AWS per se - also, there are some aspects of AWS infrastructure that are a pleasure to work with. Nevertheless, usually it makes more sense to use a whole ecosystem, and the more you get locked in, the more difficult is to get out, and the sunk cost fallacy is omnipresent among companies of all sizes.

[0] https://forums.aws.amazon.com/thread.jspa?start=50&threadID=...

VPS servers are more capable than ever, and the manageability might surprise some who know cloud as the only way. It's not the only way, but it can be valid now often than realized.

I guess the difference between us is I'm in JS everyday while he's primarily backend. I've made peace with my tooling as has he. I've also made peace with the fact that my tooling is going to continue to change every few years. From Gulp to Webpack to Parcel to Snowpack and onwards.

As is the case with much of the front end tooling, once you peel back the curtain, it isn't too terribly complicated. The biggest issue is following the data transformations through the code base because JS being a dynamic language, a lot of magical transformations can happen, but thankfully TS and other compile-to-js languages are helping a lot on that front.

Meanwhile, trying to peel back the layers of k8s, the authors of which seemingly hellbent on bringing Java-esque levels of over-engineered, over-architectured coding styles to a language which ironically supports simplicity and readability over all is a brain melting exercise. I understand Paxos and SAML better than most modern backend cloud tooling codebases. Then like a parent commentor mentioned, throw in AWS services soup in the mix, call services that have a mixture of async and sync calls with a nice mixture of some responses being consistent, some eventually consistent, some probably consistent, throw some observability, and control and data planes and you got a nice recipe for a big bowl of spaghetti you will truly never understand.

But everyone demands these things now, so what are you going to do.

I am not sure if anyone has mentioned it already but in my experience, oftentimes it is not the particular 'complexity' of what is revealed 'once you peel back the curtain', but rather the sheer number of different curtains that must peeled in order to build a 'modern' solution.

My gut impression is also that the challenges are more about aggregate-quirks across the many tools that comprise a solution than it is due to the aggregate-complexity.

For frontend it's no longer enough to know HTML, CSS, basic JavaScript and maybe JQuery. It's not enough to render static templates on the server. You have to build a SPA with dynamic bindings and a build pipeline with webpack or whatever else.

It's all just ballooned like crazy and personally I found it incredibly hard to keep up with all of it. So I'm trying to transition into either front or back end, so I'm not trying to learn full stack everything anymore.

And yes, I was wrong, rails has been around longer than that, it was just a guess.

The reason I've been teaching it myself, despite Elixir being a young, niche language is that I believe it's an ideal choice for a solo-founder or small team trying to build an ambitious web app. It's a tool I personally want to have at my disposal.

Discord is a great model: start with a simple Phoenix app, ship way faster than the competition, build out more sophisticated infrastructure with scale, and then finally rewrite core loops as NIFs (natively invoked functions) that are implemented in Rust. They were in a crowded market with extremely well-funded competitors and they still built a considerable lead in product and infrastructure.

I am saying it does not matter if they are sufficient on their own. If you want to find professional work as a frontend dev in 2021 you will be expected to learn larger and more complex toolchains.

I am sure there are plenty of applications in maintenance mode using simpler tech (or possibly not, because the lower complexity means that there are far less bugs?)

I don't think it is, for the business-logic code portion any way.

For backend, the hiring is typically "you know Java" or whichever $backend_language.

For frontend, your job application will be terminated in the early stages of the pipeline because you do not know the latest 2 year old framework (that is written in JS that you know extremely well).

10 years of JS and web experience amounts to nothing because "you do not know Angular". I do not think this applies to backend at all, they just see a "langauge-X developer".

    I don't think it is, for the business-logic code portion any way.

Reality: data leak

I'm also tired of all those hyped technologies. Sure, containers, "serverless" etc. are neat and powerful things, but in most cases it reminds me of Top Gear's kitchen blender powered by a V8 engine. Yes, I could use TypeScript, React and a couple other libraries to build that website. But then I also need to handle 3 configuration files and their interactions, wait for the incremental compilation to run through after every change, waste time debugging because the incremental builds got the whole amalgamation into an undefined state and deploying the project now requires its own toolchain and scripts.

sadly, there is no kitchen blender powered by Node.js in the V8 engine.

    418 I'm a teapot

That reminds me, there should be a mandatory session variable that tells you which of those you actually use to sign up/in

    Kubernetes. Docker. AWS and its gazillion impenetrable product names. The days of security updates, pentests,     
    honeypots and captchas you have to go through in order to put up a webapp that won't be commandeered by (insert 
    bad guy here) within hours. The endless cycle of breakage on your server because LetsEncrypt or whoever have 
    upgraded their crypto libraries to fight against (insert bad guy here).

    The need for a lawyer to write you a privacy policy before you can let people log into your site. The endless 
    bullshit of dealing with "Log in with Facebook/Google/Apple" because that's what people expect these days. And 
    even then it's better than dealing with email verification because Gmail/Hotmail will kill your emails anyway.

So maybe, just maybe, not everything should be a web app, and be connected to everything.

EDIT: Corrected typo.

Every time I try I feel like I must be missing something because everyone says it's easy to get into, but all the information I can find is completely useless.

Computer games have a few things different than usual applications; you probably don't want to encounter all those differences in your first project. The user interface is generally completely different: instead of dialogs with buttons and input fields, you typically have one window with canvas, where you paint things. (If you also want buttons and input fields, you probably have to implement them yourself on top of that.) Things are in motion, they appear and disappear, interact with each other. You probably want to clearly separate updating of the game state from displaying the game state. (You probably also want to save and load the game state.) In addition to algorihms, there is lot of data: design of the levels, different units which are kinda the same thing but with different parameters and different pictures. (Will you also make a level editor? Or design a clever system for easily describing the level in a plain-text file?) Plus the details that still require lot of work, like the intro screen, help screen, option screen, high score table, etc. Plus you sometimes need to care about performance; a one-second delay to e.g. calculate the proper path through a maze may be unacceptable, because it would make the game freeze for a moment every time you command a unit to go somewhere. For network games, performance is even more complicated. You need to make semi-arbitrary choices about object dimensions, bitmap resolutions, etc. For a professional looking game, you also need music and sound effects.

None of this is rocket science. But each of these things requires some thinking and experimenting, when you do them for the first time. You might want to create a demo for each of them separately. Definitely don't use all of them in your very first game.

Start with a simple game, such as minesweeper. Open a game dialog with a canvas. Load bitmaps from resource files. Place the mines randomly in a memory array, then paint that information on the canvas. When user clicks mouse, convert the mouse coordinates to the click field, update the memory array accordingly, then repaint the canvas. That's all, but you need to think about all possible game states: each field can be "hidden", "hidden with mark", "hidden with question mark", "open", "open with number", "open with a bomb that killed you". Also, when you are killed, you cannot click anymore (other than the restart button).

As a next game, just make a simple animated demo: balls bouncing within a rectangle. (To keep it simple, balls only bounce from the boundaries of the rectangle, not from each other.) Your game state is where the balls are (x, y) and what is their speed (sx, sy). You need a method that will update the state when some times has passed; the time interval is provided as a parameter. The coordinates need to be floats, even if ultimately they will be rounded to int when you paint the balls. A linear movement is simple: add "time × sx" to "x"; if you passed a boundary, fix "x" and flip the sign on "sx" (and do the same for "y" and "sy".) Make a loop that waits for some time interval, updates the state, and repaints the state. Congratulation, you made your first animation! Now try supporting the mouse; when a user clicks find out if any ball was clicked, if yes, change its color.

When you have these two parts mastered, you are ready to make a simple animated game. On a very abstract level, there is a game state, a method that updates the game state when a time interval has passed, a method that updates the state when a mouse was clicked or a key was pressed, and a method that paints the state. And an infinite loop of: wait, update for time, update for mouse and key events, repaint; and again. For a more complex game, the game state is more complex, but the essence remains. (Plus you may want a method to save the state to a file, and load the state from a file.)

Moving a player character can be done the same way. You have an object with coordinates "x", "y" and speed "sx", "sy". When time passes, "x" and "y" update based on "sx" and "sy". (To implement friction, make also "sx" and "sy" move slowly towards zero based on time passed. To implement gravity, increase "sy" based on time passed.) When an arrow key is pressed, "sx" or "sy" is either increased or decreased. When the object hits an obstacle, it bounces. When the player object overlaps another object (a collectible item, or a missile), the other object is destroyed and the game state is updated accordingly (score increased, key collected, or hit points reduced).

How to implement shooting? The shots are also objects with their own "x" "y" "sx" "sy", which are generated when you press a key, and disappear when they hit something or get out of the screen. How to implement enemies? For starters, make them bounce off the boundaries of the screen, and shoot at random moment in a random direction. Check when your missile collides with an enemy (destroy the missile, reduce enemy hit points, destroy enemy if hit points get to zero), check when enemy missiles collide with you.

The next step would be to load levels from files. For example, imagine a rectangular maze M×N, loaded from a text file (where walls are represented by "x" characters, and empty squares by spaces), and your task is to walk from the start to finish. Optionally, add colored keys and doors (specified in the text file e.g. as "a" "b" "c" for keys, and "A" "B" "C" for doors), where you need to collect a key in order to be able to walk through the corresponding door. Make 10 levels like this; completing a level starts the next level. The easy way is to do this without animation: your positions are integers in the maze grid, and they update only when you press a key.

Now make the same version, but more alive. Make a rectangular maze with walls loaded from file. Make yourself and the enemies bounce from the walls (this will require a little math, but quite simple). Add shooting. (To keep it simple, enemies do not bounce from each other. Neither do you bounce from an enemy, but your collision removes hit points from both.)

Now all you need is to add more sophisticated behavior to the enemies. The constraints are that the enemy has a state, and the method that updates the state of the game will also update the enemy state. (The algorithm for enemy is implemented in small pieces. For example, instead of a loop "choose a random place on the screen, walk there", you would specify small increments, such as "if you have a place chosen, move towards it time×sx steps; if you reached the place, choose another"... essentially write a code which executed many times repeatedly will produce the desired behavior, but at each time only does a tiny part of it.) Make multiple enemies, specified in a configuration file: they will differ by bitmaps, amount of hitpoints, and maximum speed.

...and when this is done, you are ready for Unity. What Unity does for you is providing 3D graphics and 3D physics (it will calculate the bouncing and collisions for you).

We joked at my old place that the best thing for a web dev's sanity long term is to retire into SQL

In 2007, I was already long past done. DHTML [1997] and AJAX [1999] were distant memories. (Had to check wiki.) I mercifully forget what the hotness was during the final years of the Bush Admin.

Sure, some things get better. Fonts on the web are now pretty terrific. But React? Please kill me. Components? Code generation? Meta meta languages? Ya, no thanks.

But I am happy the kids are now finally rediscovering (reinventing) server side includes. Full circle.

Good times.

I was thinking exactly the same thing while reading the conclusion of the post. You leave frontend complexity for even more complexity, are you nuts!

The good old single PHP page is gone long time ago as well.

But then you get to integrate with some weird funky SAP extension some company wrote and they can't even configure their web service URLs right.

If you work in IT, you'll have to perpetually fight against people and technology. It's why people hate people who work in IT, because they always say "no".

Plus IMO you set up your framework for building once or twice and just reuse it everywhere, so doesn't end up as difficult as the faster changing front end work.

Not in my experience. I made the switch from front-end to back-end about 5 years ago and I never worked with k8s or AWS, and Docker very little only for spinning up local envs; those were always the job for devops. I guess it just depends on the company. I mainly read code and wrote code.

Do you have some sources for that? Just curious.

I personally avoid having to login via FB, Google etc.