You have ruined Javascript



  • I do enjoy a heartfelt rant.

    [quote=http://codeofrob.com/entries/you-have-ruined-javascript.html]...trying to wrap my head around all of the indirection in the above example is making me want to crawl under a desk and bang my head on the floor until the brainmeats come out so I don't have to subject myself to this madness any further.[/quote]
    :wave::grin:
      ^ brainmeats exploding from ear canal


  • SockDev

    :+1:
    would agree again.

    enterprise has infected all that we hold dear. it has infected us, turned us into unthinking factory zombies, spewing XML and popping indirection like it's candy.



  • I expected it to be a rant at Netscape developers since they did much more destruction to JavaScript than AngularJS, but it was nice reading nonetheless.



  • @accalia said:

    would agree again.

    ...if it wasn't for the fact that Javascript without all the enterprise cruft was not a well designed language. It was a bloody mess. Completely fucking unmaintainable. Trust me, I tried.

    I understand this sort of sentiment towards, say, Java, because in Java you're perfectly able to write clean, nice code without worrying about AbstractBeanFactoryDecorators. But JS desperately needs some structure - and I haven't really used Angular, but while it seems heavily overboard with the abstractions, it's still better than pure JS.



  • The following is a real world example made up for this question

    Are they fucking serious?



  • John McEnroe - You Cannot Be Serious – 00:44
    — davemings


    I'm going to award a point against you, Mr. @Rhywden



  • I agree with you, but Angular is far from giving this structure to JavaScript, or at least doing it in a right, simple way. The only framework I could wrap my head around was ExtJS and, kind of, React. Daily I work with an internal JS framework and it doesn't have any of this Abstract Factory Composer bullshit.

    Also, JS is "powerful" enough that if you need any of this patterns, you can go ahead and write them, they're not that hard.

    And this guy didn't try EmberJS. His brain would melt the first time he had to run the stupid ember-cli shit.



  • Well yeah, the JS frameworks are their own can of worms too. But it's not like they ruined anything, since there was hardly anything to ruin in the first place.



  • I have to admit: I'm not really sure what those factories, assemblies and whateverelsethereis are actually supposed to achieve? I'm confused by this hodgepodge of abstracting stuff away while using real-world idioms (like: factory).

    Is there a tl;dr somewhere? Or is it not really worth my while?


  • SockDev

    @Rhywden said:

    Is there a tl;dr somewhere?

    yes, there is.

    there are people who think that this book is the gospel and should be followed wherever possible without regard to the practical application or reasoning behind the patterns.



  • Oh, I get the intent behind this stuff just fine. I'm just not sure about the advantages it offers above something like MVC/MVVC however.


  • SockDev

    depends on the situation and business needs.

    to be fair i also see MVC/MVVC fanboys who solve every problem with /MV{1,2}C/ regardless of practical considerations


  • I survived the hour long Uno hand

    There's a point at which all of this makes sense.

    I wrote BusFactor to be able to interface with git, svn, or (thanks to boomzilla) hg. But I ask the user to supply a command-line switch to indicate which type of repo to use. What if there wasn't a user at runtime to provide it, but instead, this was a back-end service? Well, I might maintain a list of what repositories have what source control system, maybe in a database somewhere. Then I'd have my code just call into some sort of module whose purpose is to figure out what kind of repository it is and give back the correct implementation so my code doesn't have to care about what source control systems are installed on the box. But let's say each implementation needs to know things, like which line endings to use or which path separators to use. So the module that fetches them probably wants to inject this information. That lookup module is a "factory".

    Notice how I didn't actually use a factory in BusFactor. It would be massive overkill.Almost every node app I've seen, it would be massive overkill for. And there's no fucking reason to do that shit on the client, jesus christ, Angular, wtf. But I can see how we got to enterprise bullshit via good intentions.



  • @Rhywden said:

    Are they fucking serious?

    They are, and don't call them Sirius.

    Wait, shit, wrong quote.


  • SockDev

    @anonymous234 said:

    @Rhywden said:
    Are they fucking serious?

    They are, and don't call them Sirius.

    Wait, shit, wrong quote.

    i think the correct quip would have been.

    "Only if they got informed consent ahead of time. :giggity:"



  • @Yamikuronue said:

    But let's say each implementation needs to know things, like which line endings to use or which path separators to use. So the module that fetches them probably wants to inject this information. That lookup module is a "factory".

    Injecting configuration parameters smells more of a Builder to me.

    The factory would be better at fully abstracting out the communication - you'd call RepositoryObjectFactory.GetRepositoryObject(string pathToRepo), and the factory would figure out the type of the repository based on the path, and return SvnRepository, GitRepository or HgRepository as an IRepository object exposing things like GetAllCodeFiles() and such.

    Then again, my knowledge of design patterns is no better than "sometimes I accidentally end up with something that resembles one".


    Filed under: and then you find yourself having to manage multiple repositories and create a RepositoryRepository


  • I survived the hour long Uno hand

    Yeah, you're right, I confused factory and builder. But the general idea stands



  • I've heard that joke before.

    Also the one about Mickey Mouse saying he wants to divorce Minnie because she's fucking goofy.


  • SockDev

    ah. that is a good joke....



  • @Yamikuronue said:

    I confused factory and builder.

    Careful you don't end up building a FactoryBuilder when you actually need to manufacture a BuilderFactory.



  • What about the EntityBuilderFactoryFactoryBuilderEntity?


  • BINNED

    @powerlord said:

    EntityBuilderFactoryFactoryBuilderEntity

    Palindromic Enterprise Bullshit



  • Implements IPalindromicEnterpriseBullshitEntityBuilderFactoryFactoryBuilderEntity_real



  • @Rhywden said:

    MVVC

    @accalia said:

    MVVC

    MVVC?



  • Model-Viewmodel-View-Controller

    It's a C# thing.



  • It is? I use mvvm frequently for wpf, but I haven't heard of this one.

    I just go learn It and apply It to all my projects!



  • @coldandtired said:

    MVVC?

    Men's toilets



  • @Magus said:

    It is? I use mvvm frequently for wpf, but I haven't heard of this one.

    I just go learn It and apply It to all my projects!

    Yeah, just figured out that I mixed things up. :frowning:



  • The thing with MVC is that it's pretty much broadly known by almost every developer. The problem is that by being so broad, some people do it in the wrong way.

    BTW, Angular is not MVC but MVCSM (Model-View-Controller-Service-Manager)



  • Thank god! I thought that, just when I was sorta getting the hang of MVVM, something new had come along to mess with me :)



  • I've heard people talking about Angularjs. Now I'm just glad I'm so lazy. Saved me a headache.

    It's all due to my standard mode of operation:

    1. Ignore it
    2. Try to get away with not understanding the concepts (aka Stackoverflow)
    3. Grudgingly try to read the docs
    4. Confusion Despair Anger
    5. Realising that it all reduces down to simple concepts

    More often than not, the concepts are mistaken and confused, so if you can avoid getting to stage 5, congratulations, you just saved your brain from integrating potential illogic.


  • BINNED

    Isn't Angular the one that's being completely orphaned for V2 anyway?



  • If MVVM takes you more than about 2 hours to get the hang of, someone is doing something wrong. If I ever manage to publish my MVVM project template on Nuget, I'll post it here somewhere. Maybe even before. Our interns, who hadn't used C# or VS before, and came from primarily a 'C and Python on Mac OS' background figured out the whole thing really fast.



  • @Maciejasjmj said:

    ...if it wasn't for the fact that Javascript without all the enterprise cruft was not a well designed language. It was a bloody mess. Completely fucking unmaintainable. Trust me, I tried.

    Yeah, but you can write your own abstractions (assuming you're not an incompetent, what is the word, "script-monkey") and do a MUCH better job than Angular.js or most of those other open source JS frameworks. Which seem to be built specifically to be impossible to debug.



  • @Rhywden said:

    I have to admit: I'm not really sure what those factories, assemblies and whateverelsethereis are actually supposed to achieve? I'm confused by this hodgepodge of abstracting stuff away while using real-world idioms (like: factory).

    There is a large class of programmers now who assume you've read "the design patterns book" and refuse to write any code that can't be described by "the design patterns book".

    "The design patterns book" is maybe useful, but the name of every design is FUCKING AWFUL. "Factory" is a good example of a terrible name. Especially if you were writing software to manage, say, factories.



  • @coldandtired said:

    MVVC?

    Yeah. It's MVC, but you add a view model-- the Model is what the database sees, the ViewModel is what the Controller sends out to the View.

    It actually makes a lot of sense to me since it's pretty rare that the Model in the database matches the Model the front-end's trying to display to the user.



  • @blakeyrat said:

    "Factory" is a good example of a terrible name.

    An interesting point. I'm not certain I agree, but only because the only alternative I can think of is along the lines of UniqueInstanceWithTheSameStuffBuilder, which wouldn't do at all. I'd be quite interested in a name that makes more sense.



  • @blakeyrat said:

    Especially if you were writing software to manage, say, factories.

    BeanFactoryControllerInterfaceFactory?



  • You can, but everybody rolling their own abstractions means that you have to relearn all the workings every time you jump projects.

    Plus, not all programmers are good. And while digging through bad code is not the most pleasant experience, digging through bad code additionally obfuscated by ten layers of ABSTRACTING ALL THE THINGS is insanity waiting to happen.

    With Angular or Ember or whatever, as silly as they can be, they're at least some standard.



  • @Maciejasjmj said:

    With Angular or Ember or whatever, as silly as they can be, they're at least some standard.

    So is HL7. So is SOAP.



  • And they suck, yeah. But would you rather have every, say, medical equipment manufacturer implement their own proprietary stadard - some of them maybe better, others even more unusable, and all working on different principles - standard A has comma-delimited fields, B has constant-width, C encodes the length...

    Which also means that with less popular standards, you need to write everything from scratch, because there are no utility libraries.

    It's cholera vs ebola, but I'd stick with HL7.



  • @Maciejasjmj said:

    And they suck, yeah. But would you rather have every, say, medical equipment manufacturer implement their own proprietary stadard - some of them maybe better, others even more unusable, and all working on different principles - standard A has comma-delimited fields, B has constant-width, C encodes the length...

    No; I'd rather them get together in a big conference room and figure it the fuck out.

    Short of that, I'd rather skin myself with a rusty butter knife than have to parse HL7 again.



  • @Maciejasjmj said:

    But would you rather have every, say, medical equipment manufacturer implement their own proprietary stadard - some of them maybe better, others even more unusable, and all working on different principles - standard A has comma-delimited fields, B has constant-width, C encodes the length

    Doesn't matter. All of the widely used standards are so flexible that they create an inner platform. Oh, you use EDI? Ok, now we have agreement on delimiters, let's have a four hour meeting about which document types and segments your system uses to do the same thing every other company on earth does completely differently.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    Especially if you were writing software to manage, say, factories.

    I think the FactoryFactory joke was already done.



  • I wouldn't say it was quite so simple. I don't work as a programmer, though, so my programming time is pretty limited and mainly Java at the moment :frowning:

    MVVM starts simple but once you start having list items each with their own ViewModel and hooking up commands and actions it gets fiddly fast.

    Possibly it's just that I hadn't really learnt enough to be comfortable with MVVM when Windows Store apps came around and I had to learn all the lifecycle stuff that goes with those.



  • @blakeyrat said:

    There is a large class of programmers now who assume you've read "the design patterns book" and refuse to write any code that can't be described by "the design patterns book".

    +1. The problem is people who read the book and mistake it as a how-to for designing software, rather than a collection of some patterns that are occasionally useful (and maybe an attempt to standardize the name of said patterns as to facilitate communication between different people).

    IMO by the time somebody reads the book, they should already recognize most of the patterns (not necessarily by name, but by what they do). If that's not the case, you end up with people who just write patterns instead of solving problems.



  • @gleemonk said:

    More often than not, the concepts are mistaken and confused, so if you can avoid getting to stage 5, congratulations, you just saved your brain from integrating potential illogic.

    You forgot alternate step 5: run a gauntlet of cocksure little hipsters who are completely certain, and very keen to point out to you, that you're just a luddite who fears change.



  • @coldandtired said:

    MVVM starts simple but once you start having list items each with their own ViewModel and hooking up commands and actions it gets fiddly fast.

    Sounds gross. I'd normally have the data objects the list items are bound to handle change notifications and nothing else, and send that as the command parameter, and only have one method in your viewmodel. It's definitely easy to overcomplicate it, but it's still pretty easy. I think I'll post that template somewhere here tonight...



  • Love nice rants :smile:!

    Especially when my inner DJ supplies (in this case) the voice of Stephan Fry.



  • @flabdablet said:

    You forgot alternate step 5: run a gauntlet of cocksure little hipsters who are completely certain, and very keen to point out to you, that you're just a luddite who fears change.

    I've not experienced this much, spent my time inflicting overengineered technical solutions on a populace in need of my wisdom :trollface:


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.