So how is PHP programming doing these days?

Which is where the problem lay and what I was addressing, as most if not ALL of these major "frameworks" -- pretty much the minute they CALL IT a "framework" -- do not address in a sane or rational manner, generally piss all over the project they are used on, and sure as shine-ola do NOT create a better workflow.

Where you would say "until he notices" I would say "once you understand doing it with vanilla JS, you realize what bloated rubbish these "frameworks" actually are!

Which is a significant part of what's wrong with development today, clients who know jack about shit insisting you use some bloated crap they don't even know as anything more than a sick buzzword they saw in Forbes. If they know so damned much about it, what the **** did they hire someone like us for?

Actually, that's how I quit my last full-time job working for someone else; stormed into the office and pretty much said that. "If you're not going to take my advice on stuff you know nothing about, what the **** did you even hire me for?!?" -- and without me holding things up they tanked themselves in a month -- the boss showed up at my doorstep BEGGING for me to return after only two weeks. Told 'em to eat sand.

Apart from the fact it in fact IS a specific type of code encouraging client side asshattery of stuff that really doesn't belong on websites. It's a cute toy for making bloated slow crapplets and little else... which is why I've not seen anything built with it that couldn't have been done in a fraction the code without it... MUCH LESS that it actively encourages via things like ReactDOM innerHTML style thinking... the antithesis of sane JS development since you're triggering the bloody PARSER! DERP!!!

Even with time-wasting pre-compilation, that's full Pakled. You never go full Pakled.

It seems almost like it was carefully crafted for people using JavaScript who don't know enough HTML or CSS to be using JavaScript! That seems to be the be-all end-all of why React.js even EXISTS!

Accuses me of not reading his posts, doesn't even understand that Lodash is in fact 115k before minification and their claims of 4k is after gzip and minification -- laughable since they appear to not even HAVE a minified copy on their site?!? Not sure how they can claim that 4k number when what they provide is 24k.

To compare:

elementals.js RC4 WIP
Raw Size: 22778 bytes
Minified: 15752 bytes
Raw gZip: 6663 bytes
Minified gZip: 5445 bytes

lodash.core.js
(using JSCompress to minify since they seem to provide none)
Raw Size: 114872 bytes
Minified: 12687 bytes
Raw gZip: 23967 bytes
Minified gZip:: 4900 bytes

So I'm actually only 545 bytes larger, though I'm using a less efficient in-house minification routine for convenience on my end... JScompress gives me 4945, so I'm 45 bytes larger on the current in-house build (that will likely become the next RC). That may grow as I'm going to be adding some cookie simplification routines since I'm sick of the bloated rubbish I see people using to brute force on a dozen lines what a one line regex can do.

Admittedly a LOT of their 'bloat' is the ridiculous OVER-DOCUMENTATION in the code to the point their comments outnumbers the code 7:1. Hence why it minifies so nicely it's almost ALL comments! Seriously, 7:1 comment to code ratio there's something horrifyingly WRONG with either their code or their documentation.

The massive amount of repeatedly saying the same things over and over again even after minification helps it gzip nicely too since right down to brass tacks what it actually does? ISN'T MUCH OF ANYTHING! I see the mouth moving but I don't hear any words.

See, most of what they document as if it is part of lodash has in fact been built into JavaScript from day one!!! Math.min? Math.max? Math.floor?!? Why the **** are they wrapping THOSE?!? To what possible end could THAT be useful?!? Colour me unimpressed as they peacock their way to sounding more impressive than they are. They literally just blindly copy other objects methods into wrappers to... waste time during startup while providing zero improvement in functionality?!? Yeah, that makes sense. I mean if you're going to polyfill Math, Array, and String, FREAKING POLYFILL THEM! Don't wrap existing methods that have been in JavaScript from the BEGINNING for NOTHING!

I could probably match what little added functionality is present in ~half the code after minification, two thirds or less after gzip since, well... it doesn't REALLY seem to do a whole lot of anything other than wrap existing functionality because... uhm, well... they can use it to waste time during startup? Hell, just axing the endless pointless "Var on ever damned line for nothing" would work wonders. You KNOW it's derp when they create a function "arrayPush" to avoid doing array.push?!? Even more of a laugh is the dev's must be even LESS fond of abbreviations and single letter variables than I am, since they go full re-re using "index" and "innerIndex" instead of i,j,k like the rest of the damned world.

NEVER thought I'd encounter anyone who likes their code more verbose than I do.

No class manipulation, no node manipulation, no AJAX wrapper, no ECMAScript polyfills... since instead of providing polyfills for stuff that's actually in the spec, it provides wrappers even on stuff that can be properly implemented -- colour me unimpressed. All it does is dick around with arrays and strings in manners that really aren't all that useful. Probably why I never even heard of it until someone mentioned it was loosely based on "underscore". Looks like 70%+ of its codebase isn't stuff I would use or even advocate the use of, and again 80%+ of what they document isn't even stuff their "little" library should even be providing... that latter part being some serious Whiskey Tango Foxtrot... Are they LITERALLY just peacocking it? Puffing it up with redundancies to make it LOOK like there's more to it than there is?!?

Nice try though as return volleys go, certainly more competent than I'm used to seeing even if it did come up short.

 

To be honest, the only things I use lodash for, are as follows: { filter, find, forEach, orderBy, assign }. Starting ES6 which is now .. 2 years old, or so, they have given you the posibility to use named exports in NodeJS.
So, given that abillity, you can "extract" those exact methods using a build-time transpiler called Babel. Now, doing that, aside orderBy which is not in the core build, gets you down to .951 kB .. I may not be a native english speaker, nor fluent in that matter, hence no wise sayings, but one thing I know for sure. What you did with elementals, they did with lodash. Just because they did it for a wider variety of users ... which implicitly come with a wider variety of suggestions, your library will become just as bloat as theirs, if you get few thousand stargazers.


Given the ability to pick what methods I need from an existing helper library rather than spending time and doing it on my own, I am sorry, but I would take that any day of the week.
Now, I have to give you props for being a custom-stuff guy. I am that myself. It's not that I don't like doing my own stuff, or my own libraries when it comes to projects I do in React.. but it's heck of a lot faster.
After I'm done and the project works, sure, I'll get my hands dirty with code and start doing my custom stuff when a method gets too big for my taste.

Call it as you might, but I will finish up any type of medium sized app twise as fast the least than you going for the manual, custom made code.
While I understand that, because I do that when it comes to PHP, don't know shit about any framework, didn't ever tried one, aside looking at their "Get started" ... Javascript nowadays is too much of a complex ecosystem to just ignore the npmjs website. I often find myself in forking already-made components from there, then stripping whatever I don't need, and here you go.

 

Which is cute, but I've seen that go tits up one too many times.

I don't see how you're even comparing the two given they lack 80% of the important functionality I'm providing, and the only thing we have in common are some routines for String and Array that I polyfilled following the ECMA spec, and that they offer some _. wrappers for. Even then our implementations vary wildly since again, mine follows the spec and theirs clearly does not.

They don't even come CLOSE to doing the same thing! You either don't know enough about one, the other, or both!

Generally I prefer that method myself, but it turns out most people don't... that's why my objective was to keep the whole thing small enough where pissing and moaning about 200 bytes here and a hundred bytes there is just nonsense.

I have NEVER seen anything done in react that wasn't a bloated convoluted mess... and this is a Vivaldi user talking; it's built with react and runs on something VERY similar to node.js -- it's basically a web browser that is a web crapplet. (one of the few times that actually makes sense IMHO... the perfectly good rendering engine is already loaded, so use it!)

But every time I go to add custom user script or JS to the interface for even the simplest of things (like close tab and go to next, close tab and go to prev buttons) I butt heads with the fact it was crapped together with react that vomited up two to eight times the code needed that is uselessly and agonizingly cryptic!

Honestly that the result is such absolute shitty garbage code on a glorified web crapplet yet Vivaldi remains lightweight leaves me wondering just what asshat bullshit the codebase for FF or Chrome is. But then I've looked under the hood of FF and have my answer; there's a reason Netscape 5 was stillborn. Given the code of gecko and how much of it has now reached "black box" status, it's a miracle it works at all.

In any case I've not seen anything built with React that wasn't a fat bloated train wreck of how NOT to use HTML, CSS, or JavaScript. I'd LIKE to see something done with it "properly" but I've never seen it. Everything looks like MORE work, MORE time, and MORE convoluted a solution... and then people say "easier" or "quicker" and all I can think is "HOW?!?" ... and the only answer I seem to find is that the people using it don't know enough HTML or CSS to be writing a front-end!

Prove me wrong... Link to a project built with it you worked on, or at least one you think is well coded... Dimes to dollars it's either doing crap that has no business being done with web technologies in the first place, could be done in a fraction the code without react if the dev just understood HTML and CSS, or worst of all chews on batteries like they were a pez dispenser by CONSTANTLY tripping the damned parser dragging system performance into the 9th ring of hell!

Just like the "three things people do with jquery" I often list, those are the three things I see people do with React that just leaves me scratching my head going "How was this simpler or faster or easier?!?" -- 'cause from where I sit it is the opposite of all those things!

After I'm done and the project works, sure, I'll get my hands dirty with code and start doing my custom stuff when a method gets too big for my taste.

Ah, NPM, how to **** yourself in one easy lesson. So I take it you were nabbed by the little "depublished" problem a while back that broke half the web? There's blindly trusting others code, and then there's BLINDLY trusting others code... in the case of NPM it's the blind leading the blind. See that offending "simple" padding function that was shoddily coded and if you're using NPM that means a modern ES5+ capable engine meaning it didn't need to polyfill back to Nyetscape 4. (and even if you did you can do so in a fraction the code).

I also shudder and go into full on distrust mode when someone says "ecosystem" in regards to a programming language. I half expect the next sentence to talk about it being a "totally proactive paradigm" to be followed up with a metric ton of gibberish market-speak. It reeks of the propaganda type nonsense that lets the REALLY idiotic halfwit garbage like jQuery and Bootcrap continue to dupe nubes and rubes into using them like a second rate religion.

The way people talk about them does often come across as cultish -- your typical mindless faithtardery that allows dipshit nonsense like anti-vax, anti-gmo, alternative-facts and creationism continue to be 'things' despite it being the 21st century. Say hello to alternative facts and the new Ludditism.

 

Stop getting ahead of yourself. I didn't compare the two libraries or whatever you want to call your thing.

All I was trying to say is that the way you wanted to get something done, in order to help someone, they did the same, how they could best.

If you know better ways to do what they did, you're free to commit as it is an open source project.

Time for me to get some sleep. Think we drifted enough from the OPs question. Either way, you have your point, I have mine. It was a good talk though.

See you around mister

 

That wasn't what it sounded like -- sounded more like you were comparing functionality "they did what you did" and not "how they went about it" which doesn't even sound like a real topic to me. I think we can chalk that up to language barrier.
(Though honestly your English is better than half my fellow Americans right now...)

Things is, first thing I'd do is delete all the wrapping of existing functions... unless I'm vastly misreading their docs, the majority of their codebase and _. methods have no reason to even exist.

I actually took this to PM because I AM interested in your different viewpoint. As MOST of my current dev and testing 'inner circle' are ALL people who WON'T use frameworks, I'm slightly concerned about echo-chamber, so I have a question or two I'd like an outside viewpoint on, and it sounds like you might be the type of person to ask.

I hate "Yes men" and I've got the nasty feeling I might have a few too many "on the inside" or my current project set -- so taking it to PM as yeah, we've dragged this (now ancient) thread kicking and screaming a bit too far OT.

 

This is not so much PHP specific but more general ideas about frameworks. Laravel and Rails are quite similar in some respects, only differing in the language. If you know one you could easily master the other.

I like the idea of a framework because lots of things like security, UI helpers, and logins are taken care of. That is probably where things should end. I come from the desktop world where you deal with a "framework" like WPF or Windows Forms. Mixing up code in your print() statements is not good practice, and makes maintenance virtually impossible, unless you have a simple homepage. If something is written using a framework, another dev can theoretically come in be productive right away (well, in theory anyway, we know the story). Views simply display the data from the controller, and the only code in the view should be strictly for visual purposes(display red if you have a neg balance).

Now, when it comes to ORMs and databases(models), I've seen horrible things on the desktop from using them. There are people who think SQL is a dirty word, and let the ORM make server choking queries. Beyond simple scaffolding relying on a framework to pull your data is usually a bad idea.

 

Php is used with java script and sql as database.