23
vortex
4y

I don't like React..😐

Comments
  • 4
    Well, that's it for you! Good luck finding a new job!

    Nah just kidding. Try Vue.
  • 4
    @ScriptCoded that's why I hate react lol
    After vue, react looks like something that was invented by someone with a head problem..not to mentions vuex vs redux
  • 1
    Just recently inherited a project in React.

    Still think using a loosely typed language for server side stuff is disgusting, but seems a pretty powerful architecture for client side stuff.
  • 0
    You know... It was simple to do a basic thing, then React suggested that they make things look complicated(Looking at you *useSetInterval*).

    or... Ditch react just as react ditched jquery
  • 1
    @M1sf3t It hasn't released yet, right? It's planned for sometime in Q1 if I'm not mistaken.

    @vortex To be fair I've only touched on React a little, but I do for sure like the simplicity of Vue.
  • 0
    I felt the same pain mate 😭
  • 1
    I'm gonna react by saying I can't blame you
  • 1
    Like @ScriptCoded said, try Vue :)
  • 0
    @jennytengsonM Hates us all!
  • 0
    And a bunch of former co-workers just got sucked into using React (division got sold) meanwhile I'm trying to bring my area of the company out of the dark ages of ASP
  • 0
    React's approach to component system is awesome as it allows some real meta approaches with higher order components (using variables as components in JSX, passing a whole component in a prop, stateless components). They make templates a lot of concise and easy to manage.

    Now the problem with it is redux and other 100+ js frameworks to solve state issue. And each of those has a inovative based-on-flux-pattern solution which is the best thing since sliced bread, and all of them still have issues in special cases.

    I would love combo of power of react component approach with state management and change tracking of angular. That would be the best of both worlds IMHO.
  • 0
    I am having trouble understanding your react shun.
  • 1
    I like vue
  • 1
    Vue is crap
    React is crap
    AngularJS is crap
    Angular is okay
    Vanilla.

    Redux? Doing it Vanilla.
    I ship the fastest apps inside the most aged and un-optimised software environment.

    AND I DARE TO START ANOTHER NON-STANDARD „REINVENTED“ FRAMEWORK. It WILL suck ass.

    If you really need some aspects or are in a hurry, just steal the underlying tech underneath.

    JSX? Use hyperscript. Preferably from preact, that’s why it exists.

    „<></>“ WHO DESIGNS SUCH CRAP

    And last but not least, Google and with some worthy interest Microsoft are trying hard to get all of that out and settle on one standard. There cannot be a „definitive“ standard, but many options comprised in the least amount of API.

    And wtf is svelte of an idea? It‘s already horrific to call webpack a compiler. I mean it‘s a good idea to put the vast amount of work into a compile step, but again, doing it non-traditionally e.g. by having xml as top layer.

    I repeat, do NOT start another webdev war.
  • 1
    And like why the FUCK would you want xml as language wrapper to contain the other one’s? That‘s worse than JSX! At least JSX is basically just a representation of a specific type of object. This idea already existed for years even outside the web.

    But even then, no one stops you for using template tags. No one stops you for using an html next to your js.

    So stay fucking vanilla or else use stuff that has already proven itself for ages and ages. The web is the first to have the primary language for logic not the primary language. Wtf.

    Keep them separated strictly or allow an syntactic sugar feature - jsx.

    If anybody still cares, I would suggest to look at stencil. If I recall right, it‘s bundle size was optimized yet again and should be lower, if not equal to svelte.
  • 1
    Devrant doesn't like my comment
  • 1
    OK so I rewrite because the iOS app is stupid. Svelte does not use webpack. I used it in contrast to svelte. It cannot be a compiler, if webPACK is not a compiler, hence why you usually don't see a webCOMPILE. Both svelte and stencil use rollup underneath. So basically, their just glorified thought out dev environments. That's where I hate the marketing of svelte, not only the name is kinda weird, but also the "cybernatically bla bla" crap. Just say it's static code analysis, wtf.

    The Problem rises with the "<script>" and "<style>" tags. If I see those in the context of web, I expect my <script> tag to be the script tag from W3C. But it's not. It's just a placeholder for the js to be ripped out in the compilation process. Same with CSS. Then, the remainder is the render() call. That's stupid.
  • 1
    Stencil does this using typescript and it's AST, a very known method. Typescript supports decorators, again, something very known in other languages.

    This "on:click" is so unconventional, I'd rather do it using this tool with an "addEventlistener" or like stencil with an "@Event" or inline types "onClick={actualJS}" and not some weird strings that just magically work if you do it right.
  • 1
    Bascially IMHO Svelte shouldn't be used unless it's contained in one of those weird projects using ruby on rails, python or something else (more or less) exotic.

    It kinda feels like it was made from the people who really wanted coffescript sooo badly. And we all saw how that turned out.
  • 1
    @M1sf3t First, it's stupid to declare your function name to-be-called as string. Second, using an arrow function isn't that much better, because at runtime, that arrow function will be created every time you invalidate your view. Binding has performance bottlenecks in non-chromium based browsers. Just declaring your function name will loose it's own scope, which is anti-pattern. Handling that by the framework is not explicit enough.

    "Normal attributes" as speaking in onClick="javascript:myCode()" is not the same as on:click="myCode()" one of the things I dislike about angular, also. But it's also disliked to use "className" over "class", because className is the official JS api, but tedious to always declare it that way.
  • 1
    Additionally, if you want to keep your code pretty, it's more difficult to implement that in your IDE/Editor/Pipeline, because it has this specific format of html+css+js in one. I mean, even WebStorm doesn't always get to format the inner language inside a specific tag to be formatted correctly. It's way simpler to use tslint seperated by some css beautifier and html beautifier, instead of painfully getting it all to work for one format. Even having to do that seperately for each environment (IDE may need use something different than the Pipeline, but basically doing the same).

    Don't get me wrong, if you're learning and doing it as hobby/having related infrastructure (eg. ruby), it's fine. But for everything else, it's kinda annoying. You also have to think about the future. There will be a point in any application to be re-done. Difficult in a specification like this.
  • 1
    eg. my current enterprise project will need to remove all jQuery, Bootstrap and all other 20+ plugins for jQuery/Bootstrap, including the replacement of gulp and some mixed webpack configurations into one singular, configurable webpack config, which also includes the stencil compiler in my case. I was never able to successively replace _only some parts_ while keeping the other things in tact (speaking in "trust", not having to test things). And this project is the first one not only do this, but also to do that without much effort and seamlessly.

    Speaking svelte, not only you are not really able to re-use the sources because of it non-standard format, but also not really be able to re-use the compilant, because of it's weird format. The resulting JS is not simple to understand for what it does in the sources. You cannot easily extend the compilant logic in case you want to stop using svelte. You will always be required to use their compiler.
  • 1
    Stencil, on the other hand, is only syntactic sugar (jsx) and typescript. You can re-use jQuery and it's Bootstrap libraries inside typescript without any type-checking and not have to worry about breaking shit. And if you wanna switch to any other new tech that's definetly coming some day, you can a) Implement framework hooks to re-interpretate your stencil sources and transform them into react, svelte, or whatever you feel like sources and re-compile those. Not only that, with b) you can use the compilant of stencil, because it's simple and human understandable code. And c) would be to stay typescript, remove stencil, but keep it's core-ideas. Meaning, you can overwrite the provided feature's and implement your own two-way databinds, state management pattern, whatever. Everything is replaceable, everything is understandable, everything has it's roots in basic concepts and do no interpret them differently.
Add Comment