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.
-
@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.
-
@tim_g said in Dipping Toes Into Programming:
I wouldn't even start touching ReactJS until I would be well into JavaScript anyways. .
The selection of language would never lead to a change in desire for a framework. Frameworks are identical regardless of the language uses. JS gives you nothing that Python doesn't. So if you want a framework with one, you want it with the other. If not with JS, then not with Python either.
-
@tim_g said in Dipping Toes Into Programming:
With Django, I would start both at the same time, as my focus would purely be on the web side first, I think.
Why treat them so differently?
-
@scottalanmiller said in Dipping Toes Into Programming:
@tim_g said in Dipping Toes Into Programming:
With Django, I would start both at the same time, as my focus would purely be on the web side first, I think.
Why treat them so differently?
From my understanding, Python doesn't do jack for front-end output on a web page without something like Django... where as JavaScript can be put into whatever existing pages you have... be it WordPress (or WP plugin), a simple HTML5 page (simply display the JS where you want), your own stuff, or whatever.
-
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.
-
@tim_g said in Dipping Toes Into Programming:
@scottalanmiller said in Dipping Toes Into Programming:
@tim_g said in Dipping Toes Into Programming:
With Django, I would start both at the same time, as my focus would purely be on the web side first, I think.
Why treat them so differently?
From my understanding, Python doesn't do jack for front-end output on a web page without something like Django...
That's incorrect. Django is just a framework. Python has to render HTML for you to see a webpage. Django is just Python. So anything Django can do, Python can do. The end result is using Python to write HTML and hand it to a web server to display.
-
@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.
