Hi Ravinder,

It seems, at least based on your posts, that you are still thinking about web development in terms of the "obsolete" or more politely the "legacy" or "original" model of the web where the server is doing the heavy lifting as far as the UI goes.

In the current web development model JSON objects are sent around the network and these objects are processed "heavily" on the client side. So, from a web UI perspective, does not matter if the server is running PHP, Python, Ruby, or Node.js. From a web UI perspective it could be a big fat hamster processing the data on the server side as long as the hamster is pushing out JSON objects into the net, the data can be processed by clients (generally browsers, but not always) or others servers.

This is not a criticism, so please do not take it as negative; but you seem to primary view the architecture of the web based on a server pushing out HTML documents rendered for the UI. This model is "obsolete" (to be very direct) or at best "legacy" to be more kind to that very good, but very old model.

The current web dev model is to decouple the rendering of data from the data itself; and so that is why the strong trend in web development is to build Javascript based UIs that receives JSON objects from "devices on the net" and render the data in the UI using Javascript. The actual "plain vanilla HTML" in a modern day web apps is very little except what has been embedded in the Javascript chucks. The DOM is manipulated by client JS, not by the server.

So to answer your question about the fake JSON data site more directly (I hope), that site is a service (one of many) to web developers which returns "fake" JSON objects via REST'ful API calls so web developers can focus on developing in the UI, which mean in Javascript, and not spend a lot of time worrying about setting up a server to send out JSON data. You have all you need for data to learn from using the myriad free web dev tools and sites and "fake data" available on the net today. Plus, each month more and more tools and site are going live on the net.

The server side is important, but many web developers create very powerful web sites in today's world without an SQL based backend because of the rise of No SQL based models for storing and retrieving data objects, more likely than not, JSON objects.

It's no coincident that many young tech savvy web developers have their business cards and presentation contact information listed as a JSON object. It makes a statement to everyone when you list your contact information as a JSON object. It's basically tells everyone "I get it". You should be thinking in terms of JSON as well. If you have a database in MySQL already and the current logic is in PHP, you should think "how to I query and return JSON objects". If you are using Amazon (AWS) you should think the same. If you are using hamsters with big buck teeth to grab data, those hamsters need to send you a JSON object. If you don't have any database or data, then use free and fake JSON on the net and go from there!

The same is true for the buzzword we mostly loath, "the Internet of things". I'm not a huge fan of the "IOT" buzz; but the client-server model on the Internet is rapidly becoming "legacy" in favor of "peer to peer" and "publish-subscribe" communication models. What will all these devices send to each other? By now you should know, based on my text above, that is will more than likely be JSON objects over the next few years or more. Multiplayer gaming, team collaboration, messaging, command and control; all of these areas and more depend on peer-to-peer communications where the underlying data transmitted between devices is serialized JSON objects zipping across across cyberspace.

As you know, I am currently working on a publish-subscribe prototype toward a way to embed real-time peer-to-peer messaging in forum threads. So, in the future, when reading a thread or discussion here at unix.com, you may be able to comment and communicate with others (everyone, not just members) on these discuss threads, peer-to-peer in real-time. The technology at the heart of all of this is Javascript processing object encoded in JSON. It's not XML. It's not HTML. It is JSON encoded objects. As long as the hamster pushes out JSON, the other hamster can process the data.

Code:

{ name: "Neo", role: "Advocate", location: "Cyberspace", age: 999}

Or an array of objects:

Code:

[
{ name: "Neo", role: "Administrator", location: "Cyberspace",  age : 999},
{ name: "Ravinder", role: "Moderator", location: "India", age: 33},
]

The same is true for gaming, cybersecurity, AI, machine learning, location tracking, news, and more. The model of client-server as greatly evolved for the most part and the frontier is peer-to-peer messaging. This means your browser is communicating directly with mine. Of course there needs to be the infrastructure in place for peer-to-peer and publish-subscribe communications, and much of that, of course, will be based on servers that provide the infrastructure to enable peer-to-peer, device to device, browser to browser communications.

So, to answer your question more directly (I hope!), you do not need PHP to query the data in the fake JSON site mentioned in my earlier posts. You should query this in the UI, which means in Javascript, because your browser does not run PHP, Python, Fortran, Lisp, or the UNIX shell.

If you want to be a savvy web developer in 2019 and beyond you just think "Javascript and JSON object" first. You need to develop in a modern syntax checking code IDE like VSC, Sublime or Atom. The strong trend for most web developers today is VSC. It used to be Sublime and Atom and some still use them. You need to develop on your desktop in a Javascript engine that runs on your desktop, and that is called node.js, a Javascript engine based on V8 written in C++ that runs on "just about everything". In addition, you use use node package manager (npm) to manage your packages and dependancies. Generally, you need a templating engine for HTML, so that is generally done in a modern JS library like React.js, Vue.js or Angular.js. As you know I like Vue.js because it cleanly separates the HTML template from the Javascript and CSS like this:

Code:

<template>
</template>
<script>
</script>
<style scoped>
</style>

Personally, I am not a React.js fan because I'm not a fan of JSX (embedding the HTML into the Javascript directly), as I find this too confusing to maintain. YMMV. Some love React. I'm also not an Angular.js fan because since Javascript runs in the browser and node.js is based on Javascript, I prefer the templating framework to be in Javascript, but Angular is mostly based on TypeScript. However, there is a growing trend toward TypeScript as well, so the future is not clear; but I think it is safe to say that Javascript will continue to play a key wrote unless browsers are designed to render in TypeScript. Actually, I am not fully up-top-speed on TS and am typing over the end of my skies; and so I better stop commenting on TypeScript until I get smarter.

My recommendation is that you follow a more modern day tutorial (versus the older one you are following now). Here is a good one:

Modern JavaScript Tutorial #1 - Intro & Setup

This guy, "The Net Ninja" guy, is really good, to the point, and very fast and you can learn a lot from him if you watch and code along with his various series. He is currently pushing out free "modern JS" tutorials and they start out very basic, but are jammed pack with the information you need to be a savvy web developer in 2019.

Hope this helps!