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]

[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]

[KevinM1]

[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.