Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Sites and JavaScript
- Thread starter zoran
- Start date
-
- Tags
- javascript
- Sort by reaction score
Absolutely! Too many to name.
Look up SPA ( single page applications ). My area of expertise.
One of my favorite:
http://www.sbs.com.au/theboat/
Given that JS's createElement method lets you put anything on a page that you can put there with HTML, there's no reason there can't be. It's just that most pages have a lot of static elements - that is, the elements are always there even though their content and properties might change - and it's usually easier to put them in directly.
I think we need a few more details - per above, you can use JS to generate a site, purely through code, but in cases where there are consistent, static elements, you might find it trickier, especially with complex layouts and designs. In those instances, it would make more sense to use JS for the dynamics elements - in that type of architecture, especially with a large scale app, you'd probably also migrate to some libraries for assistance, or even complete front end frameworks.
You could also, potentially - not sure if this was what you were asking - not have any backend processing, just static files, that are consumed by a JS frontend, with all sorts of database-like functionality (sorts, filters), even some local storage to defer reload, etc. I mean, generally, if the datasource isn't static, it's being generated somewhere, that's usually a backend component (even if it's using something like a serverless architecture).
[?]
You could also, potentially - not sure if this was what you were asking - not have any backend processing, just static files, that are consumed by a JS frontend, with all sorts of database-like functionality (sorts, filters), even some local storage to defer reload, etc. I mean, generally, if the datasource isn't static, it's being generated somewhere, that's usually a backend component (even if it's using something like a serverless architecture).
[?]
That's actually a good answer, I think your original question is framed a little better now!
A lot of sites use JS to provide the dynamic interaction that we are all comfortable with these days. There are numerous frameworks built with JS that can be used to either automate page by page or create a SPA..
But JS isn't the only technology, there's also ASP(X) from Microsoft that works well..but JS is more common and not tied to any one specific browser and ASP just generates JS to power itself anyway..
I'm a little confused by the thread though, if you aren't a programmer and don't know anything about front/back-end, then why ask a question where the answers will make no sense to you?
But JS isn't the only technology, there's also ASP(X) from Microsoft that works well..but JS is more common and not tied to any one specific browser and ASP just generates JS to power itself anyway..
I'm a little confused by the thread though, if you aren't a programmer and don't know anything about front/back-end, then why ask a question where the answers will make no sense to you?
Just to clarify, ASP.NET, is a server side, web development framework, built on .NET, and in the context of "JS in the browser", they're not really analogous. While there is Javascript generation in some ASP.NET moules, it originates from a server, and can even be "server only" without any browser involved (like a web service). JS runs, standalone, in a browser, it can run from a page loaded from your desktop, the runtime engine is in the browser. ASP.NET runs [mostly] in Windows, on Internet Information Server (IIS), with the proper IIS extensions. Nothing is "run" from the browser, it only provides a request to IIS (this doesn't even have to be a browser, could be a native mobile client for example).
To confuse things a little further, several years back, Nodejs was released which provided a runtime for JS on the _server_, so we stopped being able to say, "JS runs on the client, X runs on the server".
Yeah, it's probably a bit overwhelming if you're not involved in development, tech, etc., I've been doing this for 25+ years, in various capacities. 
This might help a little, or make it much worse ...
Let's just talk browsers. So you've got this application running on your desktop, let's say Chrome.
You enter an address, some magic happens with networks and routers and data is fetched from some machine. That data can be - what is basically plain text files - the server reads the requested file and send it over the network to your browser. If the content (to keep things simple) is HTML it parsed the data and displays a web page, you know, text, images, in different positions, and size. That plain text file can also have Javascript code in it, again, the browser reads this code and executes it, right in the browser - it's not unlike you downloading an app and running it from your desktop.
Now, here's the server / backend part: when the request is made from the browser, sometimes the page isn't a simple text (html) file just sitting on the server, it's a file that's been coded in a server side language, and it "runs", this can be things like the server fetching data from a database. Then the server, on the fly (dynamically) puts the data into a format defined by the programming language, builds the "page" partially from a template, in memory, and sends that over the network.
So think about when you search for products on Amazon. There's some parts of the page that are static like the Amazon logo in the top left, other parts like the product listings aren't in that template file, the server reads the template, fetches the data, then creates a new version of the page combining the static template with the dynamic data, which is what you see.
So opening a purely static file/files, with HTML, and/or Javascript, doesn't require a server, just the browser opening the file, though it is often sent over a network _by_ a server. If the file is just a template, that loads in dynamic data that's served by, for example, a database server, then it requires a server to process the request, load the template, fetch the data, build the resulting response, and send it over the network to your browser.
Clear as mud?
This might help a little, or make it much worse ...
Let's just talk browsers. So you've got this application running on your desktop, let's say Chrome.
You enter an address, some magic happens with networks and routers and data is fetched from some machine. That data can be - what is basically plain text files - the server reads the requested file and send it over the network to your browser. If the content (to keep things simple) is HTML it parsed the data and displays a web page, you know, text, images, in different positions, and size. That plain text file can also have Javascript code in it, again, the browser reads this code and executes it, right in the browser - it's not unlike you downloading an app and running it from your desktop.
Now, here's the server / backend part: when the request is made from the browser, sometimes the page isn't a simple text (html) file just sitting on the server, it's a file that's been coded in a server side language, and it "runs", this can be things like the server fetching data from a database. Then the server, on the fly (dynamically) puts the data into a format defined by the programming language, builds the "page" partially from a template, in memory, and sends that over the network.
So think about when you search for products on Amazon. There's some parts of the page that are static like the Amazon logo in the top left, other parts like the product listings aren't in that template file, the server reads the template, fetches the data, then creates a new version of the page combining the static template with the dynamic data, which is what you see.
So opening a purely static file/files, with HTML, and/or Javascript, doesn't require a server, just the browser opening the file, though it is often sent over a network _by_ a server. If the file is just a template, that loads in dynamic data that's served by, for example, a database server, then it requires a server to process the request, load the template, fetch the data, build the resulting response, and send it over the network to your browser.
Clear as mud?
Hello Raz0rEdge, Can you help me, I have a MacBook Pro. Recently upgraded to High Sierra, but had a problem previously. A lot of my files have been saved in Javascript and I don't know why? I have up todate JS, Reset google, and downloaded JavaForOSX.pkg . I have important files which have been affected this way and would hate to lose them. Rather ignorant regarding code I'm afraid. THANKS
D.T. makes some great technical points here. My addition is to explain to zoran that although it is absolutely possible to generate a web page completely through JavaScript, it should NEVER be done client side for a legitimate website (server-side through node is perfectly acceptable of course).
The concept of Progressive Enhancement (https://en.wikipedia.org/wiki/Progressive_enhancement) is as critical to the modern web as it has ever been. In short, progressive enhancement dictates that any responsible web developer will first and foremost deliver a fully usable HTML document to the browser. Then, and only then, should client-side JavaScript be used to "enhance" the usability or performance of the site. Not following the concepts of progressive enhancement not only destroys a sites compliance with accessibility standards but also means that the site will be not be viewable by any visitors that have disabled JavaScript. Although disabling JavaScript would have been an atypical site visitor choice in the past, it is becoming a much more prevalent basic web browsing security measure employed by informed web users tired of the threats that results from pervasive JavaScript abuses (i.e. tracking, replay, pop-overs, auto-play video, cryptomining, adware, fake alerts, ...)
The concept of Progressive Enhancement (https://en.wikipedia.org/wiki/Progressive_enhancement) is as critical to the modern web as it has ever been. In short, progressive enhancement dictates that any responsible web developer will first and foremost deliver a fully usable HTML document to the browser. Then, and only then, should client-side JavaScript be used to "enhance" the usability or performance of the site. Not following the concepts of progressive enhancement not only destroys a sites compliance with accessibility standards but also means that the site will be not be viewable by any visitors that have disabled JavaScript. Although disabling JavaScript would have been an atypical site visitor choice in the past, it is becoming a much more prevalent basic web browsing security measure employed by informed web users tired of the threats that results from pervasive JavaScript abuses (i.e. tracking, replay, pop-overs, auto-play video, cryptomining, adware, fake alerts, ...)
Nearly every website will make some use of JavaScript.
Putting everything inside JavaScript to run/render by hand is the work of a sadomasochistic devil I tell you
But how long is a piece of string, there are benefits to do stuff at the client side, but also lots of negatives.
And where it is used at the server side then you wouldn’t know it on your browser that it is.
From an example perspective the user wouldn’t and shouldn’t notice any difference.