Dipping Toes Into Programming
-
@tim_g said in Dipping Toes Into Programming:
... where as JavaScript can be put into whatever existing pages you have...
That's true, but unrelated. So in the way you describe it, Python and Django would produce your JavaScript. So if you want to use JS in the way that you describe, JS itself does nothing for you. You need Python or something to output the JavaScript to go into the browser.
So in the way you are thinking of it, JS does nothing for you. Or you need JS in both cases equally and you still need to make the server component.
-
@tim_g said in Dipping Toes Into Programming:
...a simple HTML5 page (simply display the JS where you want), your own stuff, or whatever.
When making a web app, there are two places that code goes... the server and the client.
The server side is the only side we ever talk about, ever. It's the app, the part that matters. It's what talks to the database, where we talk languages, where things matter. This is where all the work is done.
The client side, in a web app, is always HTML and JavaScript. But we are never talking about this JS when we talk about languages. JS is the only language that runs here, there are no other choices, so it's never discussed. This part of your app is trivial and generally ignored when discussing it in this context.
No matter what you use as your server side code, it has to generate HTML and JS for the client side code. You can use Python, Ruby, Perl, Java, C#, JavaScript or any number of thousands of languages on the server side. But the output of all of them has to be HTML and JavaScript in order for the output to be a web app.
-
@tim_g said in Dipping Toes Into Programming:
The web browser will run it. But with Python, I can't call a python script to be displayed on a webpage from my HTML code for example.
No, you can't, but it's not relevant.
If you write your app in Python, it has to put output HTML5.
If you write your app in JavaScript, it has to output HTML5.The decision of server side language isn't affected by the fact that they will call HTML5 as their output format.
-
I think I understand a bit better now and believe I had some wrong ideas.
People who write articles about the benefits of JavaScript vs Python for web development like to push the fact that JavaScript runs both on the server and the client. But if everything runs on the server anyways (which I assume is what you want for security and web page performance reasons), what exactly is the benefit there with that former fact?
It would now seem to me that Python + Django would be the superior choice.
I may have to do more research on this, it seems I may sill not be completely conceiving the whole stack or the way it all works correctly yet.
-
Molten was built with JavaScript and ReactJS.
In an index.html file, it's called like this:
<!DOCTYPE html> <html> <head> <title>Molten Salt API UI</title> <link rel="icon" type="image/png" href="/assets/favicon.png"> <link href='/assets/contrib/toastr.min.css' rel='stylesheet' type='text/css'> <link href='/assets/contrib/animate.css' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Roboto:400,300,500' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/icon?family=Material+Icons' rel='stylesheet'> </head> <body> <div id='content'> </div> <script type='text/javascript' src='/assets/config.js'></script> <script type='text/javascript' src='/assets/molten/molten.js'></script> <script type='text/javascript' src='/assets/contrib/toastr.min.js'></script> </body> </html>And displays on the web page.
I was thinking that it's done like that, versus with Python, the index.html file would be what?
-
@tim_g said in Dipping Toes Into Programming:
People who write articles about the benefits of JavaScript vs Python for web development like to push the fact that JavaScript runs both on the server and the client.
They do, and this is a benefit. But the benefit is purely that you, as the coder, need only write one language, not two. It's a pretty minor point and while not worthless, isn't very important. All things being equal, we'd consider it. But they aren't, so it's generally just something to ignore.
-
@tim_g said in Dipping Toes Into Programming:
But if everything runs on the server anyways (which I assume is what you want for security and web page performance reasons), what exactly is the benefit there with that former fact?
It's not performance or security but rather... what good would a normal application be that only exists in the browser? If you were going to make one of those, and people do, then you'd not deploy it via a web server, but just make it a file that you download to your desktop.
If you want to see a "pure browser" style application, you won't find many because it's silly enough to be essentially pointless. What runs in the browser is so locked down (remember, it's not a full app but just the display portion of it) that you can't do anything useful. You could make a little Sodoku game or something like that that way, but that's about it.
Even "pure client" applications made with all JavaScript and web tech actually use a full web server stack with a server side application to give them powerful things like networking or the ability to write to files on the disk (client side JavaScript can't do that). Examples of these would be Atom and Visual Studio Code - those actually run a full web server locally on your machine in order to produce a desktop app using JS!
-
@tim_g said in Dipping Toes Into Programming:
Molten was built with JavaScript and ReactJS.
In an index.html file, it's called like this:
<!DOCTYPE html> <html> <head> <title>Molten Salt API UI</title> <link rel="icon" type="image/png" href="/assets/favicon.png"> <link href='/assets/contrib/toastr.min.css' rel='stylesheet' type='text/css'> <link href='/assets/contrib/animate.css' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Roboto:400,300,500' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/icon?family=Material+Icons' rel='stylesheet'> </head> <body> <div id='content'> </div> <script type='text/javascript' src='/assets/config.js'></script> <script type='text/javascript' src='/assets/molten/molten.js'></script> <script type='text/javascript' src='/assets/contrib/toastr.min.js'></script> </body> </html>And displays on the web page.
No, that's not what is happening. You are looking at the output of Molten and thinking that that itself is Molten. Molten is actually a large bit of code that is producing the stuff that you are looking at. That's not the same.
Web development is really not a good place to learn programming because instead of learning "code > output" you are learning lots of architectures and many different code pieces all at once. Normally developers learn by learning to write code that outputs words or numbers. You are trying to "learn to code" by writing code that writes its own code. That's how web development works - the code you are looking at is the code that the real code made itself! Not the code that the developers wrote.
-
@tim_g said in Dipping Toes Into Programming:
I was thinking that it's done like that, versus with Python, the index.html file would be what?
In all cases, index.html is written in HTML5, but all the code is elsewhere. Nothing of importance is in this file.
-
Think of the most basic program that you can realistically think of.... console apps. They run code (Python, JavaScript, Ruby, C#, whatever) and they output text to the console. It's simple. You run code, you get text out.
Now, with web programming, you write your program and it is not run in the shell, but on a web server. The web server doesn't output the resulting text to the console, instead it sends that text to the web browser. You could make it plain text, but people would hate you. So you format your plain text as HTML. Now it looks like a web page. The program that you wrote is not outputting a web page instead of plain text.
That's really all that is going on. The web server handles the network piece and telling the client what to expect. But other than that, you are still writing a console app that just spits out text. You are just carefully formatting that text so that the web browser can render it.
Have you written HTML by hand? If not, you should. It helps to make this more clear.
-
@scottalanmiller said in Dipping Toes Into Programming:
Have you written HTML by hand? If not, you should. It helps to make this more clear.
Yes i've written full plain HTML websites from scratch, I'm well versed in it, though it's been a while. I get HTML, that's easy.
That bit of HTML I gave before as an example, if you remove the javascript, you just see a blank page.
Now, with your explanations from above, it yet makes things even more clear.
So let's see if I have this right:
Above HTML displays a blank page, but one (combined with the others) of the pieces (i'm assuming
molten.js) loads via the <script> tag. This I'm familiar with too, back in the day I used already made javascripts on my sites to do cool things on pages.So what you're saying is that molten.js is doing all the behind the scenes work on the server, and then outputting it's own HTML (what you see when the webpage loads), on top of that blank HTML page going on in index.html? I'm thinking of it in the context of acting like an iframe if you know what I'm getting at.
I'm familiar with that as well then, in a way, as I have a PowerShell script that grabs all users from specified OUs plus some specified info as well as their AD picture, and outputs it to a .html file to be used as a company phone list. But in this case, the PowerShell script is generating the entire index.html file itself. Not being called and loading content after an existing page is already loaded.
-
@tim_g said in Dipping Toes Into Programming:
Above HTML displays a blank page, but one (combined with the others) of the pieces (i'm assuming
molten.js) loads via the <script> tag. This I'm familiar with too, back in the day I used already made javascripts on my sites to do cool things on pages.So what you're saying is that molten.js is doing all the behind the scenes work on the server, and then outputting it's own HTML (what you see when the webpage loads), on top of that blank HTML page going on in index.html? I'm thinking of it in the context of acting like an iframe if you know what I'm getting at.
I'm familiar with that as well then, in a way, as I have a PowerShell script that grabs all users from specified OUs plus some specified info as well as their AD picture, and outputs it to a .html file to be used as a company phone list. But in this case, the PowerShell script is generating the entire index.html file itself. Not being called and loading content after an existing page is already loaded.
Right, I think you are seeing it now. So in your PS example, PS outputs the ENTIRE HTML page. And that's a fine and valid way to do things. But a far more common approach today is to have HTML pages as templates which have places within them that the server side application fills in. The simplest form of this was was "Server Side Includes" or SSI back in the day. This was not done programatically but the web server would see hooks in the template and just inject a different partial into it to fill out the page. This used to be a popular way of making standard headers and footers.
Now our web apps do this and put all kinds of dynamic data all over the place, sometimes it's the whole page, sometimes it is a tiny piece of it. But the HTML that you see is really just a template to hold the new code that the server is generating.
iFrames is a good example, but works differently. An iFrame is completely separate. If you looked at resulting page source for an iFrame, you see the "container" holding the other stuff. But with normal HTML/JS generated with a template, the resulting code is seamless.
-
Okay great.
Python + Django it is!
Also, some good news here I think: https://wordpress.stackexchange.com/questions/120259/running-a-python-script-within-wordpress if I would want to do WP plugins that use Python. At least it looks that way.
-
@wirestyle22 said in Dipping Toes Into Programming:
Many of my programmer friends have recommended this: https://learnpythonthehardway.org/ if you're interested in Python specifically
That's where I started, when it was free. Not sure if it is worth to pay for it. It uses a few good learning patterns, but you should just apply them to all code you learn.
Type out all code you're learning, don't copy paste. Try to read and understand it as you type it.
Then play with the code, figure out how it works, how you break it.
Get a simple project going that you can apply what you are learning to. Your own text-based game is a great way to start.
IMO, Learn Python the Hard Way doesn't do a great job with OOP, but maybe it is just something you have to play with a lot in order to get it. Definitely spend a lot of time here, understanding the basics of it needs to come as second nature. You can play with it in Powershell too.
There are some great free resources online, I can find a few links later
-
This is one good one
-
-
@Tim_G I am currently learning web development as well so we can help each other on this new path.
I would totally recommend two resources to start Mozilla MDN web developer guide and Freecodecamp. Freecode camp being completely interactive and the Mozilla docs being mainly reading guides but both are quite good and as a plus for the Mozilla guide is that they include a Django tutorial as part of the server side tutorial.
Freecodecamp mainly focuses on teaching you Javascript so if you would like to use a python backend framework you should also take a python course. But if you don't mind its javascript focus it is pretty complete. It will freshen up your html and css, teach you javascript for the front end (currently vanilla javascript and jquery but the beta curriculum adds react as well ), https://d3js.org/ for data visualization and node/expressjs for the backend
This is their current front end path, they teach you the basics and then make you build stuff to really put to practice what you learn.
My end goal is to be able to intelligently write bits of software that are able to communicate and interact with APIs like REST API, to display and manipulate data on HTML5 pages.
If you only want to consume and interact with already made REST APIs you should focus and start on the frontend stuff. This will lead you straight to javascript first which is what you will use to interact with them from the browser.
I would advise you to first learn vanilla javascript (focusing on ES6+ if you can) and then think about learning and using libraries like reactjs or vuejs.
-
Thanks for the helpful information and resource links. I'll definitely use those and they look like a great place to start.
I do agree that the front end dev and JavaScript would be a good place to start, but I am also very interested in Python + Django. I think that would be a good base to have, and then move to the front end dev stuff above after.
I probably won't be moving through this as fast as you are due to this only being a spare time thing for me, behind the directly IT related things I am doing. But as I come across things I'll share with you as well.
-
@tim_g said in Dipping Toes Into Programming:
@scottalanmiller said in Dipping Toes Into Programming:
@tim_g said in Dipping Toes Into Programming:
@flaxking said in Dipping Toes Into Programming:
@tim_g
Flask is an unassuming simple framework. It is good for creating something simple, or for creating something complex and cutting edge where you need flexibility. In order to build out a webapp, you would need to learn more components than just Flask.
Django is a monolithic framework, batteries are included. You just have to learn Django in order to build a web app. You don't have to create things from scratch, but there are certain ways to do things, so there is less flexibility. It takes longer to learn Django, because there is so much more there. But when you do learn it, you can pump out web apps pretty fast. With Flask there are other things you have to learn, and you have to figure out how you want them to interact.
Once you have a decent amount of Python, you can learn at least the basics of Flask in a day, and then look at learning Django too.
If you're interested in messing around with Salt, I think Python is the way to go. Salt's code is pretty easy to understand and work with for junior devs, and you can start making your own customizations.
Thanks for the explanation, it helps a lot.
This narrows it down to the following:
- Python / Django
- JavaScript / ReactJS
ReactJS is just an interface layer, it's not a framework like Django.
Yes I'm not as worried about having a full framework like Django for JavaScirpt. ReactJS seems to hit all the check boxes I'm looking for though.
I wouldn't even start touching ReactJS until I would be well into JavaScript anyways. And at that point, it may be that I change my mind and want something else once I understand everything much better.
With Django, I would start both at the same time, as my focus would purely be on the web side first, I think.
I will recommend you read more about server-side rendering and client-side rendering to really decide what are you going to use when building your apps/web pages. There is really nothing to compare between Django and ReactJS, they can even work together since one can be used as backend and the other as the frontend.
Django is batteries included framework which by default is used to render web templates server side; It can just as easily be used with the Django-Rest-Framework to create Rest APIs and be consumes by your client-side javascript libraries/frameworks.
ReactJS is a library mainly used for client-side rendering and building SPAs, you can use is to render server side using something like Nextjs but that is not its most common usage.
-
@romo said in Dipping Toes Into Programming:
@tim_g said in Dipping Toes Into Programming:
@scottalanmiller said in Dipping Toes Into Programming:
@tim_g said in Dipping Toes Into Programming:
@flaxking said in Dipping Toes Into Programming:
@tim_g
Flask is an unassuming simple framework. It is good for creating something simple, or for creating something complex and cutting edge where you need flexibility. In order to build out a webapp, you would need to learn more components than just Flask.
Django is a monolithic framework, batteries are included. You just have to learn Django in order to build a web app. You don't have to create things from scratch, but there are certain ways to do things, so there is less flexibility. It takes longer to learn Django, because there is so much more there. But when you do learn it, you can pump out web apps pretty fast. With Flask there are other things you have to learn, and you have to figure out how you want them to interact.
Once you have a decent amount of Python, you can learn at least the basics of Flask in a day, and then look at learning Django too.
If you're interested in messing around with Salt, I think Python is the way to go. Salt's code is pretty easy to understand and work with for junior devs, and you can start making your own customizations.
Thanks for the explanation, it helps a lot.
This narrows it down to the following:
- Python / Django
- JavaScript / ReactJS
ReactJS is just an interface layer, it's not a framework like Django.
Yes I'm not as worried about having a full framework like Django for JavaScirpt. ReactJS seems to hit all the check boxes I'm looking for though.
I wouldn't even start touching ReactJS until I would be well into JavaScript anyways. And at that point, it may be that I change my mind and want something else once I understand everything much better.
With Django, I would start both at the same time, as my focus would purely be on the web side first, I think.
I will recommend you read more about server-side rendering and client-side rendering to really decide what are you going to use when building your apps/web pages. There is really nothing to compare between Django and ReactJS, they can even work together since one can be used as backend and the other as the frontend.
Django is batteries included framework which by default is used to render web templates server side; It can just as easily be used with the Django-Rest-Framework to create Rest APIs and be consumes by your client-side javascript libraries/frameworks.
ReactJS is a library mainly used for client-side rendering and building SPAs, you can use is to render server side using something like Nextjs but that is not its most common usage.
Yes I get they can all be used together, but I need to start somewhere. I don't know any Python or JavaScript. I need to start there. I feel Python is the best place to start, at least until a more general understanding of it, then get into Django with Python.
