• Activity
  • Votes
  • Comments
  • New
  • All activity
  • Showing only topics with the tag "javascript". Back to normal view
    1. Honest Question: What benefits can I hope to achieve by switching from jquery to react?

      I'm a freelance coder who builds small-medium apps and my front-end stack primarily consists of Bootstrap+jquery. This combo has never let me down until now even with all kinds of features,...

      I'm a freelance coder who builds small-medium apps and my front-end stack primarily consists of Bootstrap+jquery. This combo has never let me down until now even with all kinds of features, functionality and complexity thrown at it. I've built dashboards with line charts, puzzles and MCQs, grids and tabular components to edit data, etc. and it was all very seamless.

      But when I keep hearing the discussions here and on other places in social media, they make me feel like I'm stuck in a very different century! There is no doubt that React is a well-known, popular and robust piece of software but one thing that dissuades me from getting into it is the whole monstrous npm system of components around it. It seems to be quite integrated with node when it comes to some react components like next, nuxt or whatever. Is it not possible to just like include react through CDN with link or script tags and still make good use of it?

      More specifically, I want to know what can I hope to achieve if I migrate from jquery to react? I'm quite tied to the jquery way of doing things right from DOM manipulation to event handling to things like cloning and reusing HTML components in <div> blocks. Is there any established guide or path for folks like us to migrate from jquery and react? And to begin with, is this a good idea even?

      22 votes
    2. Why do the arrow functions won't return "this" object in a jquery event handler?

      Consider the following simple jquery event handler code I've been using since ages: $("body").on("click", ".dome .btn", function() { console.log(".dome .btn onclick::"); console.log($(this)); });...

      Consider the following simple jquery event handler code I've been using since ages:

      $("body").on("click", ".dome .btn", function() {
      	console.log(".dome .btn onclick::");
      	console.log($(this));
      });
      

      The this object here returns the button element in question which is the proper way. But today, I decided to use arrow function just to upgrade myself with the modern times:

      $("body").on("click", ".dome .btn", () => {
      	console.log(".dome .btn onclick::");
      	console.log($(this));
      });
      

      But in this case, the this object won't return the button element. It will return the window object instead which is the parent of all parents! What kind of atrocious quirk is this? Few days ago, someone on the /r/webdev subreddit told me that arrow function is just a modern way of writing the old function(){} syntax.

      10 votes
    3. React: Some comments from a beginner

      New job. I've been wanting to learn something new for a while, so I took a project where a lot of React is done. I'm learning it from scratch while I work with React. I have some comments about...

      New job. I've been wanting to learn something new for a while, so I took a project where a lot of React is done. I'm learning it from scratch while I work with React.

      I have some comments about it.

      1. React makes front end work a lot more like programming -- I like that!
      2. Javascript has changed a lot, and for the better, since I last used it over a decade ago.
      3. The React-Redux tool kit is the bomb. It should be integrated/absorbed into React. I can't see any reason not to use it, even for small applications as it is less wordy wherever you use it.
      4. The updating of state values should be more automatic, especially for flag variables not tied to GUI components. It is the major source of hassles with React
      5. Udemy React videos. My company makes them available free of charge to employees. I've sampled videos from a number of courses. I'm not a fan of the instructors showing you how to do things in older, less efficient ways first in a learning/demo project, the ERASING that code to do it a better way. The should include copies of the project at each stage if they do that. I finally figured out that the best way to take notes I can use later is to comment out the old code and put the new more efficient next stage stuff on top.
      6. React tests really need to improve. They are often more time consuming than the code itself. The tests have forced me to change my code or do needless testing to get the tests to pass. I had one situation where no matter what I did React test said I didn't cover the code until I broke an else clause off into it's one if clause. Blech.

      All in all I've been enjoying learning React. It is neat new ( to me ) thing.

      I feel sad that I will likely forget it all when I go back to my specialty language.

      16 votes
    4. Node's "Single Threaded, Event Driven" programming model seems highly deceptive and farcical

      The more I think about it, the more I'm convinced of it. The biggest selling point of Node folks has been the "single threaded, event driven" model, right? Unlike JavaScript, other languages work...

      The more I think about it, the more I'm convinced of it.

      The biggest selling point of Node folks has been the "single threaded, event driven" model, right? Unlike JavaScript, other languages work on a "blocking" basis i.e. you run a statement or command and the program "waits" until the I/O is complete. For example, you issue open('xyz.txt', 'rb').read() in python and the program waits or blocks until the underlying driver is able to read that whole text file (which could take arguably long time if said file is too large in size).

      But with the Nodejs equivalent, you just issue the statement and then pass the "event handler" so that your program is never in the "waiting state". The whole premise of Node/JS event-callback is that "you don't call us, we will call you".

      This is all nice in theory but if this were indeed true then Nodejs scripts should be blazing fast compared to Python and even Java considering that most programs we write are I/O heavy and 99% of time, they're just waiting for an input from a File/URI/User? If this event callback model indeed worked as effectively as claimed, Node would have been the numero one and only language being used today?

      I think I'm starting to understand why that isn't the case. This whole "single threaded, event driven" thing is just a farce. You can also replicate the same thing that Node.js is doing in your Java or Python too by applying multi-threading (i.e. one thread just "waits" for the I/O in the background while the other keeps doing its job). All you've done here is just handed or delegated that complexity of multi-threading to Node.js?

      Realistically, it's impossible to wait or block an I/O request while at the same time also letting the other part of the code engage in other tasks, that's the very definition of multi-threading. Doing "async" is impossible without multiple threads in that sense. Node must have a thread pool of sorts where one of them is engaged in the wait/block while another is running your JS code further. When the wait is over, the control is then passed to the "event handler" function it was bound to in that other thread.

      What Node is selling as "single threaded" applies to application or business logic we are writing, node itself can't be single threaded. I feel it's better to just implement multi-threading in your own code (as needed) instead of using something convoluted and confusing like Node.js. What say you?

      8 votes
    5. Markdown helpers for the comment block

      I submit a lot of posts from mobile, and I find some of the markdown tedious to enter on a mobile keyboard. I know JavaScript is supposed to be a last resort, but I'd really like to have some...

      I submit a lot of posts from mobile, and I find some of the markdown tedious to enter on a mobile keyboard. I know JavaScript is supposed to be a last resort, but I'd really like to have some assistance in the post authoring and comments fields.

      I assume this could be a user script. Looking at the wiki, it looks like none of the current ones do this.

      Thoughts on this? Things people are already using? Ideas for existing tools to build on? Would it be better as a user script or as a feature of the main site, perhaps with an option to disable it? I'm medium at JavaScript but would happily take a crack at it.

      Here is my inital feature list:

      • link button - select text, press the link button, get a prompt for the URL, replace the selected text with the markdown formatted text and URL.
      • quote block- select multiple paragraphs and click the button to block quote them all
      • bold, italic, strike though buttons - apply the markdown to selected text
      • spoiler - insert a details block at the cursor. If text is selected wrap it in a details block and prompt for the summary.

      if I were to develop it, what else would people like to see on this list?

      18 votes