5

"Guys best idea to fuc... help the javascript developers. We make a framework with its own events/states and it will not change inputs or anything unless specified in state. Clearly easier to test... I mean how hard can it be?

Even better our framework will be so fuc... Helpfull that they will put an plugin so they can make it work... I mean improve...

Did i say we just throw the html and put everything in our own butchered way? Even better remember that easy
, Style= ? Hahaha we will make it an object...

O yeah and the state must be immutable objects... What immutable means? Who the fu... I mean its easy...

And we make our own virtual dom because... Fu browsers"
-Facebook developer who hates javascript probably

P.S: thanks vue for keeping the double binding.

Comments
  • 1
    - I'm thankful that state and input-values are always the same. To have different values for the same thing causes problems, and two-way-binding is not a good option if you want to validate before saving
    - having a wrapper around the native events makes sense, than you as a application developer don't have to worry about weird browser quirks
    - style as an object is better to
    maintain than a string
    - immutability is great, makes reverting values easy
    - shadowdom works great, gives the applicationdevelopers the possibility to do all sorts of things
  • 0
    @plusgut they are never the same.

    And users dont care about states they care about what they insert... Its always the same as in "always the same as the state"

    Why have a layer on top of native events that are the the same rather than wait for react or have yourself fix the event.

    More than that... If react was so good and state was easy and could have been used so easily redux wouldn't have been so needed....

    I dare you to make lots of forms in react with lots of modals when the developers aren't that good in react. It blows up... Never had that problem in any other framework...
Add Comment