This isn't really true. jQuery's compatibility can stretch all the way back to IE8, up to the newest devices. If you require the web to be more than a document viewer, then you might in fact need some different tools; but HTML/CSS/jQuery didn't solve those if you're going back that far, Flash did.

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...

> According to W3Techs, jQuery is still present in 96.2% of the sites they could determine a JavaScript framework for

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).

Many sites hang onto jQuery solely for the Ajax abstraction that allows older versions of IE to function.

Also, WordPress includes it by default, but rarely are the site admins actually doing anything with jQuery.

You have to do responsive design, and yes, that's a big change (and a big PITA) but that doesn't require flex or grid or React or whatever. You can't go all the way back to tables, but good ol' div-based design with appropriate CSS works just fine. The new stuff may make some things easier (or not), but if you don't feel like shifting paradigms, you certainly don't have to.

My Web pages are based on tables and have not even one DIV element! Why do I have to use DIV? Actually, I never saw any good explanation on what DIV did. What the heck is DIV good for? Why use DIV?

Why can't I use tables?

> 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.

Okay. So far I haven't had to use the span thingys.

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?

The same font size on an 800 pixel wide smartphone as on an 800 pixel wide desktop screen will not be readable at all.

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.

Okay. Thanks.

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.

Having lived/worked through that period of time, it was due to rendering. The entire table had to be loaded before it could be rendered to the browser.

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

My largest Web page sends for 400,000 bits and as two files with JavaScript enabled and just one file otherwise. So, the pages should load and "render" very quickly.