@iamscottcox
JavaScript Developer
Nothing here yet.
Nothing here yet.
No blogs yet.
Jason Knight Well... I'm always going to disagree with you on the idea that nice has been tried and it doesn't work, but maybe I'm a sucker for it. I can't help myself, and I don't think that will ever change. Where you see stupid, I see the potential to teach and to educate. It's a part of the web community that I love and cherish and I don't think that will ever change :) I'm curious as to what you would propose as a solution for a large scale application like the one that we build at my workplace. For us, React has been an invaluable solution and there are reasons why it was chosen. For reference, we're building large scale, enterprise level network analysis software with admin dashboards containing large amounts of data visualisation. A lot of the parts of the app need to know what other parts of the app are doing at all times. How would you go about solving a problem as large as ours without using any library or framework? Do you still maintain that Vanilla JS is the most viable solution? If yes, why? If no, what tools would you use instead?
I don't think componentWillUnmount() is getting deprecated. You refer to componentWillMount() later so I think you might have made a typo there :) Currently I add event listeners in componentDidMount() and remove them in componentWillUnmount() . It's worked really well for me so far.
Jason Knight I think a lot of your opinion stems from some very bad experiences and I'm sorry that you've had to deal with that. I'd feel similarly disenfranchised if I'd had to experience a similar set of circumstances. It looks like we agree on a lot of stuff, but I still disagree with your stance that a tool is inherently bad just because people have used it badly. It only serves as an indicator that people need to evaluate their use cases a little better and decide on frameworks accordingly, especially when it comes to CSS frameworks like Bootstrap. However, OP asked about JS frameworks like React and Angular and my point still stands. If you're building a cut and dry website which boils down to three pages('Home', 'Contact' and 'About'), then no, React is not your answer. Write yourself some good semantic HTML and style it up with CSS. Put some Vanilla JS on there if you need any extra functionality. If you're building something that has a larger scale, and could potentially scale upwards, React could help you out. That's the sort of thing that it was created for. With regards to saying negative things about frameworks: by all means, please do. It breeds constructive criticism and fosters ingenuity. However, you can catch more flies with honey than with vinegar. Proclaiming that frameworks are bad and slamming anyone who uses them because your experiences with them have been bad isn't a conducive way to communicate your feelings or to bring people on board to your way of thinking. My reaction to Mev-Rael 's comment 'RTFM' was because I would expect someone who has authored a fairly well used JS library to recognise their own impact and influence on the community and use a little more tact than what amounts to "Read the fucking manual."
Mev-Rael Goodness me! What a horribly rude person you are. Nevertheless, I will respond with respect and civility which you unfortunately cannot find it within you to extend towards me. You also have huge problems in organized team work and don't know who is doing what and have 50 people digging same hole in the same time what is physically impossible anyways. We are very organised as a dev team thank you, but sometimes changes overlap, especially when product can't make up their mind exactly what they want because the client has changed their mind about something. I'm sorry we don't all live and work in your perfect world where everything runs smoothly and nothing changes or goes wrong, but some of us live here, in the real world, where things undoubtedly can and will. (P.S. 15.000 results is extremely small number and server NEVER will return you 15k records in one API call lol...) It was an example for the sake of brevity. Please try not to be pedantic. Attention community, here is a busted myth. Vanilla JS 1 - React 0 Hold your horses there. What's this? however as per many conversations and per UX we changed it to replaceState() long time ago You mean to say that you're using something to manage the state of your application. A state management tool if you will? DOM is NOT slow and you DON'T need any new jargon like "state management" You're using state management yourself. I never said that it HAD to be Redux, I never said it HAD to be a JavaScript library. Sure, you can use VanillaJS to achieve the same result. I said that state management made DOM manipulations more predictable. You've done nothing more than prove my point. Myth busted. Good bye. Not really, no. My argument to you was that state management was a helpful tool for predicting DOM manipulation. I never once said that you couldn't do the same with Vanilla JS. If you're scoring the discussion we just had, you've just proved my point so... My argument for state management 1 - 0 Your argument against state management and via an own goal nonetheless. RTFM. Really? Could you try to be a little bit more professional in your responses?
Mev-Rael If a person don't know what he/she is doing in a math/engineering field where you either have 100% correct answer or not and if he/she can't predict results, probably, software engineering job is not for that person. Would you ever move your butt on a plane if you would know that a pilot doesn't know what exactly he is doing? I suppose you can understand that you wouldn't be able to land in that case and it would be a one way ticket into the heaven. 2 + 2 = 4. Period (I am not talking about higher math tricks). If you need a library to understand it, I am very sorry! The thing is, it's not just one "pilot." There could be up to fifty of you with your own individual controls. How do you know what DOM manipulation colleague #5 has made? How about colleague #17? Colleague #39? You could make your changes and hope for the best that it doesn't conflict with another member of your team. Or you could dispatch it to your state management and have your components render conditionally based on the changes made. It's a one stop shop to be able to tell exactly what the app is "thinking." I can only assume that you haven't worked on anything large enough to warrant using state management, or something that would provide you with the ability to build a component library like React does. I don't mean this as a criticism, but if it's true then please stop. You are spreading false and damaging information because you haven't found a use case for React or Angular that warrants that sort of library being used. I am still waiting for a real use case example where you need to know the change, what exactly kind of change and how it will be used and where this HTML "unfortunately can't do something at the moment", but for now I still hear the same - blah blah React/Redux faster, blah blah DOM manipulation without React/Redux is unpredictable. First of all, please try not to be rude. Second of all, I will provide you with an example: You are building a list out of raw data (let's say 15,000 or so results) returned to you from an API. You need to paginate the data with 100 results per page and provide search and filter functionality. If the user changes page, or changes any of the filters or the search terms, these changes must persist, even if they move to another part of the site and come back. How do you ensure that your user's changes and the snapshot of data (i.e the 100 or so results for that page) are maintained? Also, please tell me how I would construct this functionality using HTML.