Help me with my new website!

[SteelCurtain]

I know C/C++ isn't used for webdesign, but perhaps such a tool should be developed. A tool that enabled you to do high level design, but also allowed to get to the micromanagement.

I hear people complaining about how hard pointers are, and segfaults are a thing, but direct access to memory by location alows for neat tricks. It adds much more customization.

Eh, outside of the Hiphop compiler and, later, virtual machine made by Facebook to translate PHP into bytecode, there's really no need for the average web developer to touch C++. Web sites, by the very nature of HTTP, are stateless. They're not programs in the traditional sense, but rather one-shot affairs that live and die per server request.

Regarding better tools, that's why I use a framework like Symfony. It's really modular, and it handles a lot of the low level, "every site needs this and it's pretty much the same" crap (routing) while allowing the developer to write real code to solve real problems. It uses a MVC architecture, whose point of entry is just a simple Front Controller that parses what the user sends in the address bar... it's up to the developer to write the code to handle such requests.

It also comes with an event model, which you can use (or not), a service model, which you can use (or not), etc.

There's other frameworks that do the same kind of thing (Laravel also for PHP, Django for Python, Rails for Ruby, ASP.NET MVC for .NET/C# (which I find to be far, far superior to web forms (no more stupid page lifecycle BS) ), etc.). And it's really the best of both worlds, IMO. If you want to whip up something custom, there's nothing in the way stopping you.

The barrier to entry is higher. You need to know how to:

Program in the language the framework is written in
Understand the basic design philosophy the framework employs
Understand SQL, and the particular ORM being used (Doctrine 2 in my case)
Understand HTTP (not hard) and how routing is different between GET and POST requests (also not hard, but seems to trip up newbies)
Understand the template engine used for creating views (read: pages... Twig in my case, Razer in ASP.NET MVC)
Understand HTML, CSS, and JavaScript because that shit isn't going to write itself

But you can do so, so much more with it than with prepackaged software that never looks or feels or works quite the way the client wants.

Yeah, full stack development is where it's at. The last production site I built from scratch, I used a modified MEAN stack (MSSQL instead of Mongo), and oh my. I mean, the power of tools like Angular and ExpressJS are insane.

I'm an Angular fan for life.

[FlatAssembler]

OK, I get what you are saying. I've chosen a wrong language and a wrong framework because C# and Unity are much better for making simple games than JavaScript and JQuery are. I'll try C# sometime later. For now I only know that JavaScript sucks much less than C++ does at both making GUIs and writing string-manipulation algorithms.

Anyway, do you have some ideas on how to improve the JavaScript game about linguistics I already made that are easy to program?
http://flatassembler.000webhostapp.com/etymologist.html
It takes some 6 minutes for me to play it all and score all or nearly all points. If you don't want to play the first part of the game, I've made it possible to speed it up by pressing some answer right when the question is fading out (when you've pressed the OK button in the pop-up). Then the next question will be skipped.

I don't think I would be able to add anything complicated to it. I can barely manage the 2000 lines of code it has now. I've tried to make it modular by dividing the code into functions and by splitting it into two files, one with the algorithm (which later became the text-based version) and one with the GUI, I've written a few dozens of lines of comments in the algorithm, I've used some basic OOP a few times… But I guess that, to someone who hasn't done anything more complicated than a Pacman before, 2000 lines of code are simply too much.

[bennyboy]

The number of lines shouldn't really matter unless it's spaghetti code. Every main section of code has its job, every function has its job, every line has its job.

[KevinM1]

The number of lines shouldn't really matter unless it's spaghetti code.  Every main section of code has its job, every function has its job, every line has its job.

Yup... with server side languages, at least, each class is its own file, usually somewhere in a directory hierarchy that makes sense.  Like, the project I'm working on is:

Code:

/
   /app
       /config
           /bunch of config files, in YAML
   /src
       /controller
           /my controller files (PHP)
       /entity
           /my entity (database classes) files (PHP)
   /resources
       /views
           /my templates (Twig)
   /web (the web root)
        /js
           /JavaScript files
       /css
           /CSS files
       /images
           /images
       /app.php <-- the front controller of the application
    /vendor
        /all of the 3rd party packages I use

Like the old saying goes, a place for everything, and everything in its place.

[bennyboy]

OK, I get what you are saying. I've chosen a wrong language and a wrong framework because C# and Unity are much better for making simple games than JavaScript and JQuery are. I'll try C# sometime later. For now I only know that JavaScript sucks much less than C++ does at both making GUIs and writing string-manipulation algorithms.

Anyway, do you have some ideas on how to improve the JavaScript game about linguistics I already made that are easy to program?
http://flatassembler.000webhostapp.com/etymologist.html
It takes some 6 minutes for me to play it all and score all or nearly all points. If you don't want to play the first part of the game, I've made it possible to speed it up by pressing some answer right when the question is fading out (when you've pressed the OK button in the pop-up). Then the next question will be skipped.

I don't think I would be able to add anything complicated to it. I can barely manage the 2000 lines of code it has now. I've tried to make it modular by dividing the code into functions and by splitting it into two files, one with the algorithm (which later became the text-based version) and one with the GUI, I've written a few dozens of lines of comments in the algorithm, I've used some basic OOP a few times… But I guess that, to someone who hasn't done anything more complicated than a Pacman before, 2000 lines of code are simply too much.

It looks quite nice, I think.  I don't know how that could possibly take 2000 lines of code, but looks good.

I recommend that you make the background sky image full-screen and center the actual game window to the middle of the screen.  On my large monitor, I have to look too much up-and-left.

[KevinM1]

You can cut down a lot on the CSS with shorthand properties: https://developer.mozilla.org/en-US/docs...properties  I haven't taken a good look at the JavaScript, but if you find yourself repeating a lot of code, put it in a separate function and invoke it where needed.

Also, you really shouldn't stuff everything into one HTML file.  Separate it into at least three files:

1. CSS file
2. HTML file
3. JS file

It makes it a lot easier to maintain/debug/edit/etc.

Code:

<!DOCTYPE html> <!-- this tells the browser you're using HTML5/want the document to be parsed in standards mode -->
<html>
   <head>
       <title>Blah</title>
       <link href="styles.css" rel="stylesheet">
       <script src="jquery.min.js"></script>
   </head>
   <body>
       <!-- all your html -->

       <script src="game.js"></script>
   </body>
</html>

By placing the game script at the end of the document, you eliminate any runtime issues you may have as you're ensured that the document is loaded.  You won't get those errors stemming from undefined DOM objects.  And by placing it in a separate file, you create a clear separation of concerns.  Your HTML should be blissfully unaware of anything aside from HTML.  Similarly CSS and JavaScript.

EDIT: as you progress with your apps, you should look to use automated testing. Every language has at least one testing suite (here's JavaScript's: https://qunitjs.com/ ... I use PHPUnit for PHP). Basically, you set something up, like a function, import it into the testing environment (which is really just another script), and then attempt to use it in the context of the test. The testing environment has special helper functions, typically named assert<something>, that are the actual tests themselves.

So, say you have a function that, at the end, is supposed to return the number 10. You'd run the function and test it:

Code:

QUnit.test( "MyFunc test", function( assert ) {
  assert.equal( myFunc(), 10, "Passed!" );
});

While this example is trivial, unit testing is a useful practice to get into. I'm in the process of writing my own tests for my e-commerce PHP project so I can verify that the ORM (Object-Relational Mapper... it's middleware that converts OOP objects into database entries, and back again) entities I've setup are working properly. It's a lot better/easier to do it in a test environment (and a secondary sqlite db) than running it in production.

[FlatAssembler]

I recommend that you make the background sky image full-screen and center the actual game window to the middle of the screen.

There doesn't appear to be an easy way to do that. I was using absolute positioning many times in both JavaScript and CSS.

Separate it into at least three files.

I've been thinking about that, but I have a feeling that then the webhost would cause even more problems than it does now.

As you progress with your apps, you should look to use automated testing.

Sounds good. I made a few errors in the code (the algorithm), some of which caused JavaScript to fall into an infinite loop, that could have been much more easily fixed if I had used automated tests. I also have only recently found how to start the JavaScript debugger in Safari (I was debugging it using the alerts).

[KevinM1]

Why would the webhost care if you split your code up?

And, yeah, all (afaik) browsers have developer tools built in. I've found the CSS tools, especially the visual representation of the Box Model for individual elements (it's in Chrome, dunno about other browsers), to be really helpful over the years.

[bennyboy]

I recommend that you make the background sky image full-screen and center the actual game window to the middle of the screen.

There doesn't appear to be an easy way to do that. I was using absolute positioning many times in both JavaScript and CSS.

As happened earlier on in this thread, let me say it again: if you can't easily change the appearance of your site, then the site is broken. You should invest all the time it takes to redo things properly, preferably using only .css for formatting the UI. Basically, you've just learned firsthand why the organization principles Kevin is talking about are a necessity.

[KevinM1]

Yup, HTML and CSS provide the skin for your app. HTML provides the structure of the UI (tags) and CSS provides the basic appearance (size, colors, position, etc.). When a web app is structured properly, you should be able to change/replace these things without affecting the brains (the actual script(s)) of the app whatsoever.

And once you arrive at that separation, you can do some cool stuff, like programmatically applying holiday themes based on the current date, or having your entire UI dynamically change based on the user’s browsing device (mobile vs. desktop), all without the underlying functionality of the site being affected at all.