React might suit Facebook but it probably isn't a good solution for someone who's application only gets a few hundred hits a day.

AWS has 150 services or so now. How many of those does a 12 employee small business need? None most likely. That business's site gets maybe 1,000 or 3,000 or 10,000 hits per month. It's an absurdity to throw all the new tools, libraries, cloud tech etc. at that. Most of the Web looks like that small site, most sites on the Web get very little traffic. So little that you could run it on a $5 Digital Ocean instance and have over 95% of the droplet's use capacity to spare.

Does my insurance agent, who operates his own small business, need machine learning? No. And to the extent he does, it'll be built into the tools provided by various insurance carriers, entirely hidden from his daily business operation activities.

So who actually needs all of these tools? You nailed it, it's almost entirely isolated to the 0.1% group, the Facebooks, et al.

I have a friend who has his own navy. It's a small navy. He does like boats.

Once he had a men's yacht trip. There I met a guy and his son who ran an insurance agency.

Well, AI or not, one of the keys to his insurance business success was his ability to separate good customers from risky ones. Basically he knew nearly everyone in town, or at least every one of his customers, down to what they ate for breakfast or some such. That knowledge helped him get a good loss ratio and made good bucks for his business.

So, maybe what he did was not AI but real I!!

I'm sure that if someone had an AI tool that would help his loss ratio, then he'd us it!

For a second example, my father in law was on the local bank board. So, a guy in the community applied for a home loan. Well, at that bank, the loan application went to the BoD of the bank -- no joke.

Then at the BoD meeting, everything about the applicant got exposed and discussed right down to the details of his lifestyle. So, again, if some AI application could help that bank make better loan decisions, then likely they'd use it.

Lesson: That local insurance agent and that local bank both were really big on gathering, analyzing, and using all the data they could get. If AI could help, then they'd use it.

And you're right that most sites don't see traffic numbers to justify exotic AWS setups. I personally think most web businesses grow pretty linearly, so the focus on "overnight" scaling problems is more of a sales tactic than it is reality.

I do think you're underestimating the amount of companies that do need these tools, though. It's not as binary as "insurance broker" and "Facebook". Logistics companies, payment processors, restaurant groups, grocery stores, etc. all have pretty complex backend services and some of these tools are critical to even compete in their industries.

If he has a fixed mindset you are right. But if he has a growth mindset and has the intellectual curiosity to learn what ML is and if he can apply it to his business and finds out that he could maybe he can increase his business 10 fold. Even if you take a stance that he is not interested in growing just the fact that living in this age and time gives him(or his kids) the option to learn/play with powerful tools at a click of a button is worth appreciating on so many levels

E.g. a particular technology feature might cost $100k to implement in your business and get you a 10% revenue increase. For a large business, doing so is a no-brainer; for a one-person business doing the same thing is clearly a waste of money and effort. And there are many things like that, causing the bifurcation between the needs and common practices in large companies vs small.

If you zoom out and think about it for a second what most technology is doing today is making a small guy look big

Agree with this 100%. I keep hearing coworkers trash a particular open source project/framework with no understanding of what kind of problems it solves.

Also I often think:

I keep hearing coworkers adopt particular open source project/framework with no understanding of what kind of problems it solves.

Very often teams will use ages getting up on new frameworks to avoid a little hard programming, only to end up with hard programming wrapped in a huge framework they don't really grok and lots of incidental complexity.

Wordpress or whatever will make an email widget easy to source, but if that's only 1% of your project, why impact the other 99% without considering its impact? It's so easy for intuitive maps of the "hard parts" to dictate insanity across the whole development process.

It's a spectrum of complexity over numerous components, inside the context of a greater development environment which also impacts decision making. As boring as it sounds this is why I force myself to estimate as close to "everything" as best I can early in the project... Not so much to use as an estimate, but to map out areas where my intuitive understanding is inadequate, and to give some rough data to drive decision making. Mapping out the pain points at least gives you a semi-objective breakdown of where the actual work lies, and to what degree that pain will be mitigated/exacerbated by major frameworks. DIY has its limits ;)

The real problem here is that all these comp sci "geniuses" want to make a name for themselves with a "real" project and so they create all these garbage tools (compilers, pre-processors, etc) that make things worse by introducing and encouraging more complexity when just using plain JS would work better.

A lot of them are Java/C++ people with no experience in web development who see the simplicity of JS as a flaw and want to recreate the s--tshow they are used to working with because the complexity makes them feel smart and special.

That is just human nature though. The same argument has been going on for decades between C and C++ people. Nothing new here.

I think the ones doing it to make a name for themselves rather than solve a real problem are a lot less common than you're making it out to be.

A decade ago, the requirements for supporting all/most clients (devices) were radically different. Different requirements mean different solutions and perhaps new tools must be used.

But HTML/CSS/jQuery still work to solve the problems they always did. And they're still used in production today. According to W3Techs, jQuery is still present in 96.2% of the sites they could determine a JavaScript framework for in the Alexa top 10M.[1] And the very popular CSS framework Bootstrap still has it as one of its dependencies.[2]

"If it ain't broke, don't fix it."

1: https://w3techs.com/technologies/details/js-jquery/all/all

2: https://getbootstrap.com/docs/4.0/getting-started/introducti...

But that doesn't mean jquery was used exclusively on these sites. Look at any major website, in addition to some modern framework, they will often include jquery for just a few old hacks (I've seen popular sites include 3-5 different jquery versions on the same page).

Why can't I use tables?

I think it's harder to make design changes to the page. You also end up doing crazy rowspan and colspan things. You end up with more html tags (though probably less css). It's probably fine. Though it's probably hard to make mobile-friendly. A lot of html emails use tables for layout because they can't trust the layout will work with divs+css.

For mobile, I'm just assuming that the users smartphone has a Web browser. For fitting on the smartphone screen, each page is just 800 pixels wide, and smartphone screens are that wide? But even if not, my pages are still usable with only 300 pixels wide.

My most complicated page sends for just 400,000 bits which seems small enough. There are just two files, HTML and JavaScript (JS). The JS file is written by ASP.NET and is small and optional -- so I'm expecting fast page loading.

I didn't see any good reasons to do anything special or different for mobile. What am I missing?

Go watch the original iPhone unveiling - https://thenextweb.com/apple/2015/09/09/genius-annotated-wit... - at 01:00:00 or so he shows the New York Times website front page. It's in three columns, like on desktop, meaning you can read nothing until double-tapping to zoom in. 10 years ago, because nobody owned a mobile, this was considered acceptable UX.

Now visit it today - https://mobile.nytimes.com - with a narrow window. The layout changes and the first headline is immediately visible. That can't be done in table layouts. If somebody visited a news website on a mobile today and saw a desktop-optimized layout, they would likely immediately leave.

Actually I have been guessing that smartphone users would somehow magnify my Web pages by a factor of two (2X) or three (3X). Using the horizontal scroll bar, they can get by with just the left 300 pixels. So, with 2X, they would be using 600 pixels on their screen; 3X, 900 pixels. Doing a Google search on smartphone screen pixels, the 900 seems fairly common.

I don't really see a way to present the information to users with fewer than 300 pixels horizontally. My Web pages are so simple I don't see any way to make them still more simple for smartphone screens.

The situation on tables versus DIV, JavaScript, etc. for me versus others appears to be: (1) I'm only developing one Web site and where the screen content is under my control from my design of my user interface (UI) and is especially simple. So, for my Web site, with just two main Web pages, I can do well with tables. (2) If I were Web site front end developer for many different Web sites, responsible only for the Web pages and not for the content, the site overall, or the business paying for the site, then too soon I'd find that tables were too limiting. So, instead, I'd use JavaScript to look up screen sizes, window sizes, pixels, the physical width of the screen in inches (millimeters, points, etc.) and then use DIV elements, more JavaScript, etc. to try to redesign the page for the screen of each user individually.

Net, from (1) and (2) what works for me for my just two Web pages for just my startup is not flexible or powerful enough for Web pages in general. Okay.

For the Apple announcement video, apparently that is blocked in the US on copyright grounds by NBC.

I didn't realize that Web page designers were going to so much trouble to accommodate tiny smartphone screens.

Really, for my Web site, getting a good user experience (UX) for smartphone users will be a strain unless, say, smartphone users are wearing special glasses or are very near sighted!

Thanks for the tutorial.

If your entire site was wrapped inside a table, nothing would load until it all did. If I remember correctly.

I'm not sure if that's still an issue with modern browsers, and our faster connection speeds, it if increased processing and network speeds have made it insignificant now.

Edit: SE answer with more: https://webmasters.stackexchange.com/a/6037/3403

Nothing is new under the sun, something old becomes something new in a different context in a different time, same thing happens in music and fiction... so what?

> There may be edge cases that the new solutions helps with that the old solution couldn't handle

It's pretty condescending to reduce the work of many smart and passionate programmers down to "a bunch of edge cases". People put real work and thought into these projects based on their professional experiences and it's depressing to me that others can be so cynical that they're unwilling to imagine that maybe there's something they aren't seeing about why so many of their colleagues are excited about what these tools make possible.

> but that begs the question, why didn't we just improve the old tool instead of making a brand new one?

Setting aside the clearly obvious reasons why we don't (and can't, and often aren't welcome to) contribute to existing tools rather rather than roll our own - who is worthy enough to determine which projects deserve eternal tribute and which projects are allowed to even exist? Your question is absurd. Why don't all these hugely popular tools with active open source communities just disappear? Umm, why should they have to? Why don't all the people who have a problem with it disappear back to a world where they can manipulate individual DOM nodes to match their application state with imperative instructions... you know, the present world they live in right now?

> This leads to a lot of outside pressures that fall upon developers/companies who are trying to stay relevant in the field

I'm not understanding the complaint. "Pressure to stay relevant in the field" sounds a lot like "keeping up with advances in the field". I understand you don't agree that they are advances, but a lot of people disagree, including many individuals leading companies and organizations highly regarded for their engineering talent.

> When everyone around you is moving to "B", do you want to be the one that is still using "A" because it works just fine? Do you want to risk being irrelevant in a few years to prove your point?

If you're tasked with the responsibility of deciding which technologies are the most appropriate choices for a project and you decide to pick "B" because it's popular, rather than "A" because its a tool that you understand and claim is "just as good" as "B", YOU are to blame; by your own logic you're just giving yourself an intentional handicap so you can look cool.

> Naturally, many people don't want to take that risk, and so they go on learning the new technology even though it's not really necessary for 95% of developers

Who's to say what 95% of developers need? Some would say 95% of developers don't need javascript at all, so I guess that settles that.

I'm not trying to argue that new tools shouldn't be created, and I'm certainly not suggesting that their creators are not passionate or hardworking, so I was wrong to say that we should just improve the old tools. But it is worth questioning who should be using these tools - should the way everyone makes websites completely change because someone created a new framework or tool? There are always going to be new sites that push the limit of technology and will need new tools to get there. For sites like the author of that article creates though, which are often described as "brochure websites", those tools simply aren't needed, and yet there is conforming pressure within the community that pushes developers to make sites like that using the new tools, which is overkill and can turn something simple into something complex. If you're the person responsible for choosing these things, you will eventually face that pressure. If you're not responsible, you may not even have a choice. You can't pretend that people conform to social pressures.

I understand what you're saying, but the bottom line is that "the conforming pressure" is illusory. At the end of the day the engineering team must deliver a product that works to specification and is not difficult to maintain, that is the only real pressure, there is no rational justification for choosing a tool that is less likely to accomplish that goal when a suitable one already exists. If someone is in charge of building a "brochure website" and they select a complicated SPA pipeline with many build steps as the solution then they are objectively doing the wrong thing and that's the end of the story, nothing in that scenario reflects on any aspect of the actual tools.

> You can't pretend that people conform to social pressures.

I don't, but those people are the problem, not the tool.

It's EMCAScript [0], the spec of which JavaScript is an implementation. New features will come out in the spec, and it takes a bit for browser's JS engines to implement them.

[0] https://en.m.wikipedia.org/wiki/ECMAScript

A concise feature list can be found here: http://es6-features.org

Most developers don't just grab their tools based on what they want to play with at the moment. Actual software engineering today involves working with other people and their code. Code reviews, integrations, maintenance, enhancements, technology overhauls, system decommissioning, working with vendors.

The fact that this simple reality didn't even cross your mind tells me everything I need to know about your opinions on tooling.

And? What's that point you're making? If it's not your job to pick the tools then the point is moot because you'll work with whatever the technical leads decide, all you have to do is get to work.