/tech/ - Technology★

>>1041262 (OP)

add to the list

>makes threads on h8chan about himself when attention starving

Who is this nigger?

>>1041263

I never used PHP, so please tell me, is its badness just a meme or is it really so awful? It is used everywhere on the web, so there must be something it's doing right?

>>1041304

im not a programmer, but I assume it is so hated BECAUSE its used all over the web. So people can see the very worst and most annoying implementations of this language. But I'm not a programmer, so what the hell do I know?

>>1041311

>>1041304

PHP is just retarded because you're wondering to yourself "Why the fuck is it compiled into C code and then compiled into machine code once more?" and shit BREAKING because it wasn't designed to be good and last in the first place. But you can write something relatively fast and it just werks on apache.

>>1041300

His name is in the subject of the thread retard

>>1041304

It's made by Jews.

>>1041304

>is its badness just a meme or is it really so awful?

http://news.php.net/php.internals/70691

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design

https://whydoesitsuck.com/why-does-php-suck/

https://www.reddit.com/r/lolphp/

https://en.wikipedia.org/wiki/PHP#Security

He was cute though.

>>1041262 (OP)

His mom is hot.

>>1041304

It's really that bad. And new versions require rewriting all the code.

If you saw the thread about the anon having to "upgrade" 100 PHP websites in one week, now you know why that's so hard.

>>1041304

https://eev. ee/blog/2012/04/09/php-a-fractal-of-bad-design/

Here's a giant blogpost on why it's bad. Rewriting it every time makes no sense.

>>1041340

m8, have you tried reading the thread before posting?

>>1041341

I know we're shitposting about (((Josh))) who can't into PHP but it won't make the language less of a slow clusterfuck.

>>1041262 (OP)

Hes become a transgender.

>>1041347

>he still hasn't read the thread

>>1041357

you smart

>>1043720

>Null tells NZ government to fuck off

>HW says he regrets shit

APOLOGIZE TO JOSH

>>1043750

josh did nothing wrong

>>1043720

I'm not reading that

>>1043788

>hotwheels what do you think about 8chan regarding the christchurch massacre?

>it's become a festering pit for national socialism and another shooting will happen some day. i'm glad i'm done with 8chan and i'm never using an imageboard again.

>>1043800

Mark is right though. Stormfags were, are, and always be, pure cancer.

Is that his mom or a gf? lel

>>1041262 (OP)

No the question you should ask is when were you right to start with

>>1043793

Thank you for the summary.

>>1043720

Check his twitter, he's been "quoted" incorrectly

>>1043997

https://twitter.com/HW_BEAT_THAT/status/1100939220149886976

>>1044033

We believe that most of the web does not need to be dynamic and increasing complexity on server-side applications is one of the main reasons for the web obesity crisis. The common approach nowadays is to do everything on the server, including parsing requests, modifying files and databases, generating HTML and all that using unfit languages like PHP or JavaScript, which is a security and efficiency nightmare.

Over the years we have seen massive amounts of security holes in numerous applications of tools commonly used for these jobs (PHP, node.js, CGI-implementations, ...). The reason why we are in this situation in the first place is due to the fact that the jobs of data processing and data presentation, which should be separate, converged together into one.

The solution is to rely on static regeneration independent from the web server, which just serves static files. You can still implement e.g. form handlers for dynamic content which run as their own network instance and operate independently from the web server. What's left is just to generate the static content using the database and repeating this process in case the database is updated.

This way the jobs of data processing and data presentation are separate again, with many advantages. All requests are handled with constantly low latency, with the possibility of serving everything directly from RAM (using a ramfs). Separated concerns make it very unattractive to attack the web server itself and the attack surface that is left, if it is present at all, is the separate form handler, which can be implemented in a very simple, safe and efficient manner.

In case there is an attack on this infrastructure and the attacker manages to DoS the form handler, the serving of content is still unaffected.

>>1044033 is a code monkey and >>1044139 is a software developer. Night and day difference.

tried to singlehandledly build successor to underlying tech powering chans with bad designed prototypes in shitty languages, failed

blamed his software inability to handle bandwidth on few things he couldnt get fixed in time, got fired anyway

even if it was true, doesnt matter, you were given a job, you should do it in time and how you promised, nobody is going to wait for you to fix site-killing superbugs in next 6 months because you are tired

>>1044140

But nothing of what he said made any sense, you samefag. It's true separation of concerns sucks in most web frameworks (PHP itself is a really bad offender, by making PHP pretty much based around coding inside a template, which tempts a lot of shitcoders), but everything after that is nonsense. Dynamic websites are necessary; how else would you run a search query and don't tell me "download the whole website and run the search client-side"? Would you cache all possible searches ahead of time? Of course you won't. There are more usecases for dynamic website generation, but this is the most blatant one. Not to mention his proposed solution is exactly what brought 8chan down before getting Alacrity, which I suspect lazily evaluates each URL only when needed.

If you want my opinion on why webdev sucks as an actual webdev, it is because HTML sucks. Everything about it does, and it only brings bad practices with its shittiness. It was not made for dynamic content generation, nor to reduce serverside (or clientside) complexity. It was made for simple, static documents. It was (understandably) made without CSS3 in mind. Modern HTML + CSS3 code is hard to reason about, and pretty much write-only. Just look at the fucking huge amount of boilerplate there is in your average HTML5 document, just to make CSS render it correctly. How do you know which rules apply to a certain element with nontrivial CSS, without executing it in a browser? You don't, because rules may come from a thousand places. It just sucks.

My recommendation for a better web? Ditch HTML, ditch CSS, and keep a small subset if HTTP. Start anew with another ecosystem, with simpler documents and more "prefabricated" components (user/password forms shoukd lretty much be a built-in in browsers and web frameworks, for example). Learn fron HTML5's mistakes, and build the new web with efficiency and simplicity in mind. Don't be afraid of being slightly opinionated with it, and hopefully you will keep most browsers easily under 100k lines of code as God and Terry intended.

>>1044256

>Dynamic websites are necessary; how else would you run a search query

You don't create a monolithic dynamic piece of shit that uses 100 javascript libraries for a simple search.

You can still have separate form handlers from the web server _WHICH IS WHAT WAS SAID BEFORE_.

>You can still implement e.g. form handlers for dynamic content which run as their own network instance and operate independently from the web server

>>1044147

That's the one of the most cucked and kosher ideologies possible. You'd love Africa it's full of Christians.

>>1044527

>I'd be 100% fine with getting rid of most "web technologies", though, including replacing HTML and CSS with something better and having a scripting system replace JavaScript with something less powerful but much more secure. Making JS turing-complete was a mistake, and it should only have the power to engage CSS effects, for the purpose of animation and the like

No, this makes no sense. JS isn't bad because it's Turing complete, it's bad because it accesses stuff it shouldn't be accessing. JS would be fine did it not have access to everything it does, because it becomes a security issue the moment you are able to access your browser's window dimensions (CSS is also guilty of this) and also contact the server without user interaction. It's either one or the other, not both.

A scripting language is also, by definition, Turing complete. What you are looking for is a declarative language, which doesn't have to be Turing complete, and would actually be a good idea, considering most of the shit JS usually does can be reduced to just a handful of things.

>We should just use desktop software connecting to servers for anything we want to do.

You would love smartphones, which is the real-world implementation of what you are thinking. Yes, it would be neat if we could just reduce everything the web is to a few protocols, but that won't happen. What will happen is each big company will produce a buggy app running with full privileges inside your desktop, and smaller websites will cease to exist because they can't afford to build a full app. Having a generic platform everyone can build on is a good idea, but maybe this is too generic. We need to separate the web between "documents with simple forms" and webapps, and run the earlier with mout any privileges in simple browsers eithout many features, and the latter in a more flexible and generic VM, where the user fully knows what he is installing and the permissions it is giving.