The end of the web browser

6502 said:
real reason is lazy or incompetent programmers
Click to expand...
Right ...

Usually the lazy and/or incompentent programmers are given limited budgets, crazy timelines, and suboptimal requirements (with lots of eye-candy "must haves"). The only way you can have a hope of achieving all of those is to reach for the bloated frameworks. Or you can say "no" or "I'll write it all from scratch and it will take six months and it won't have the eye candy because that's wrong" and be out of a job.
 
drhowarddrfine said:
JSON and Ajax are not frameworks. JSON is a data format. Ajax is a transport method.

<snip>
Click to expand...
Are they not syntactic frameworks? How are we defining "framework?"
https://www.ecma-international.org/wp-content/uploads/ECMA-404_2nd_edition_december_2017.pdf © Ecma International 2017 iii
Introduction
JSON* is a text syntax that facilitates structured data interchange between all programming languages. JSON is a syntax of braces, brackets, colons, and commas that is useful in many contexts, profiles, and applications.
JSON stands for JavaScript Object Notation and was inspired by the object literals of JavaScript aka
ECMAScript as defined in the ECMAScript Language Specification, Third Edition [1]. However, it does not
attempt to impose ECMAScript’s internal data representations on other programming languages. Instead, it shares a small subset of ECMAScript’s syntax with all other programming languages. The JSON syntax is not a specification of a complete data interchange. Meaningful data interchange requires agreement between a producer and consumer on the semantics attached to a particular use of the JSON syntax. What JSON does provide is the syntactic framework to which such semantics can be attached.
Click to expand...

Maybe I misunderstand the meaning of AJAX Framework... I'm anxious to learn.
 
developer.mozilla.org

Ajax - Developer guides | MDN

Asynchronous JavaScript and XML, or Ajax, is not a technology in itself, but rather an approach to using a number of existing technologies together, including HTML or XHTML, CSS, JavaScript, DOM, XML, XSLT, and most importantly the XMLHttpRequest object. When these technologies are combined in...
developer.mozilla.org developer.mozilla.org
 
drhowarddrfine said:
If not JS then it would be some other web language to be made up.
Click to expand...
Yes, but I think, it should have been at the level of html and http.
Perhaps the problem is that html developed too fast, from sgml.
That is why it was continuously complemented, with CSS, javascript, applets, etc.
 
hruodr HTML is a textual markup language used for identifying portions of a document for computers to understand. It had little to do with styling because, in the beginning, it wasn't needed so they just didn't do that.

In fact, more and more, styling elements are being deprecated and removed from the standard. I mean, for example, the <em> element is no longer specified in the standard for its styling but, instead, for identifying a piece of text as being emphasized only. Styling is to be done with CSS.

From the HTML standard
The em element represents stress emphasis of its contents.
Click to expand...
The em element isn't a generic "italics" element.
Click to expand...
 
JavaScript is what makes your document sensitive to, and able to detect, mouseover events and mouse button click events when you interact with submit buttons. Using HTML only, each button will display only the look-and-feel of the client OS -- Windows buttons have their own unique looks and behaviors on the desktop, as do MacOS, MacOSX, and the various DEs available under FreeBSD and Linux. All these little editor widgets we use to post our replies depend on JS. Without JS, we wouldn't see those "more replies have been posted" messages above our posting text boxes.

JS makes it easy for the web server to interact with the client browser without the client initiating the interaction, in order to, for example, display such "more replies..." messages, update clocks, progress bars, etc., without entirely refreshing the page for each little text string, floating span, or other widget displayed or modified. JavaScript allows the web designer to change CSS styles and classes dynamically and in response to events occurring outside the browser.

This XenForo forum, for example, depends on JS extensively, for its drop-down menus, text editing features, cursor repositioning, FreeBSD background styles, and many other features. It simply would not be the same without JavaScript.
 
But that was not thought of at the start. The hyerlinked documents approach was stateless. Once web pages became a thing state was put on top and then web 2 came along including the underlying XML HTTP requests (underlying AJAX) etc. And the evolution continues today.
 
astyle said:
With ads being embedded straight into the video being played, that's a problem across the board, really. I do keep my eyes peeled for a solution, but AFAICT, there's nothing in sight... It would take reverse-engineering the very video format, and replacing the ad with a 'Your video is now loading' animation. That would take extra processing cycles on your device, too. At this point, browsers have nothing to do with ads any more, ads have infiltrated the very data we're after. ?
Click to expand...
That's not what happens - it would screw up their CDNs for a start.
Content providers can get a "sponsored" or "about" section added automatically, but that's different - besides, "sponsorblock" can skip those.

There are numerous android apps, and chrome extensions, and even programs in the FreeBSD ports tree! that seamlessly block ads, and work well. I presumably shouldn't link to them, but there is one that is actually on the Play Store (I've not tried it): https://play.google.com/store/apps/details?id=free.tube.premium.advanced.tuber
 
jamie said:
That's not what happens - it would screw up their CDNs for a start.
Content providers can get a "sponsored" or "about" section added automatically, but that's different - besides, "sponsorblock" can skip those.

There are numerous android apps, and chrome extensions, and even programs in the FreeBSD ports tree! that seamlessly block ads, and work well. I presumably shouldn't link to them, but there is one that is actually on the Play Store (I've not tried it): https://play.google.com/store/apps/details?id=free.tube.premium.advanced.tuber
Click to expand...
if there's ad blockers in FreeBSD's ports tree that you know about, please do list them here. These Forums' users are the kind of crowd who'd be quite receptive to spreading that kind of knowledge.
 
jamie said:
That's not what happens - it would screw up their CDNs for a start.
Content providers can get a "sponsored" or "about" section added automatically, but that's different - besides, "sponsorblock" can skip those.

There are numerous android apps, and chrome extensions, and even programs in the FreeBSD ports tree! that seamlessly block ads, and work well. I presumably shouldn't link to them, but there is one that is actually on the Play Store (I've not tried it): https://play.google.com/store/apps/details?id=free.tube.premium.advanced.tuber
Click to expand...
A comment : What is the point of an application that blocks youtube ads and spams with its own ads ?
 
astyle said:
if there's ad blockers in FreeBSD's ports tree that you know about, please do list them here. These Forums' users are the kind of crowd who'd be quite receptive to spreading that kind of knowledge.
Click to expand...
Fair enough. mpv configured with yt-dlp works perfectly. It even can link to the sponsorblock code I mentioned earlier.

Simply ensure 'yt-dlp' is enabled in the ports options, and then: (eg)

mpv https://<youtube-url>

Maybe multimedia/gtk-youtube-viewer too?
 
Alain De Vos said:
A comment : What is the point of an application that blocks youtube ads and spams with its own ads ?
Click to expand...

LOL, I didn't know it does that! Doh!

Anyway, I suppose it's ok for me to list stuff that's on github...

https://github.com/yuliskov/SmartTubeNext (Android tv / firestick etc.)

https://github.com/TeamNewPipe/NewPipe/releases (Android, but doesn't allow login to youtube account)

https://github.com/coffeerhyder/YouTube-alternative-Clients-and-Frontends-overview - a list of different clients for different architectures that someone has put together.

The best one was "vanced" ("ADvanced, but without ADs) which was basically the reverse-engineered youtube client, but whilst it's claimed the app still works fine, that project is dead after a cease-and-desist from google. You could google it for "research purposes"
 
hruodr said:
My only argument is that AJAX should have been basic functionality.
Click to expand...
It sort of was. The very early HTTP protocol (the thing which transports HTML-formatted things over the network) had GET, POST and PUT. Plus the GET method had query parameters in the URL string. So at a super rudimentary level it was already possible to do interaction with the human user (who is seeing the page and clicking on things or filling in text) and the server. But that early solution was so coarse, it didn't scale to the fine-grained things we want to do today. In particular, it often required re-sending and re-rendering the whole page. What really happens is that there is a "program" of sorts running in the browser, interacting with the user. With traditional HTML only, that program can only do a few things, like forms for text input and buttons. So something better had to be done: allow that program to have more fine-grain interaction, and modify the rendered web page. This all happened in fits and starts, with many dead ends being followed. For example, Java was one of the early contenders for a language to run in the browser (as an applet), and then use network RPCs to talk to the server (for example EJB or Corba). Well, that went nowhere fast, so JavaScript became the de-facto standard.
 
I remember a horrible kludge I did back in the late 90's for work. They wanted everything "webalized" as it was the new fad. Java at the time wasn't practical on the client machines, and javascript was rudimentary.

The data on a web page needed to be current, but constant page loading would be awful.

I ended up dividing the browser into frames - one invisible. It was set to http-refresh every 10 seconds, and if the main data had changed, the cgi backend would send the frame html that would open the URL (now changed to avoid caching.. I seem to remember IE ignored cache-control headings) in the main frame.

Horrible. Also bad if the frame didn't update for some reason, and then stopped looping - it wasn't immediately obvious that the main page had frozen. The solution was to make the invisible frame visible but small, containing just the text "Last updated: <datetime>"

Fortunately the idea was abandoned, as our current environment of curses/terminal window worked much better!

Ugh. I need a lie down now!
 
IMHO at the time of early web (near 2000) the plans were to use HTML for static hypertext pages and simple feedback (e.g. registration forms). For rich GUI people expected to use Java or similar language. Click link, browser loads and starts java executable. But security was in doubt. In addition Java was developed by Sun and browsers by other companies. And last but not least Java was very slow for computers at that time. “Knock, knock. Who’s there? (very long pause…) Java.”
 
You must log in or register to reply here.
Back
Top