Why are linked lists not used frequently in Javascript [closed] - javascript

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I’ve been working with JavaScript for around 4 years. In all the applications I’ve worked on, I’ve never once seen someone use a linked list. Why is that? Data structures are so prominently featured in most learn-to-program courses. Yet I almost never see them used in the real world.

This may not be the perfect explanation of this but I think will give you a fair idea about it.
The scenarios which will make sense to use Linked list on JavaScript
are very rare. You have been working on JavaScript for 4 years when
did you feel a need to use linked lists and not JavaScript Array
The main purpose of using linked list is performance improvements,
when there a is a huge collection of records and frequent changes to
them linked lists help in optimizing that. But that case may not be
true for most of the JavaScript applications. Arrays are pretty much
bale to do that for JavaScript.
Most of the frameworks rely on array's be it React, Vue etc.
In case of linked list methods like unshift, etc. are much faster.
while methods on Arrays, such as push, run considerably faster than
Linked Lists.
The use of linked list is justified when you need to make a lot of
modifications to a huge list — especially when adding or removing
items somewhere other than the end of the list and such cases are rare in
JavaScript/front end.
Last but not the least JavaScript has great support for Arrays but
you will have to code your own implementation or use some library
that provides linked lists implementation.

Related

using block scopes to organize complex code [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am building a three.js library and found placing comments and nesting content below the comment in {} made it easy to navigate lots of code. I was wondering if there are other better ways to do this.
Why I would like to do this
the main reason: I can quickly collapse code based on the comments I see above the block scopes. Thereby making it easy to focus on the code I want to change.
I'd only use this in the class initialisation, or very complex methods. Or rather, any areas where there is significant code use with applicable labels for those areas.
I would never scope a section without an appropriate comment accompanying it.
This helps me scale these different sections, especially if they are not something that would scale into a new class or object within reason
Im aware a common problem with code bases is they can be extremely overwhelming, especially when learning them. I think this way of organising code could help make it more approachable and less overwhelming to look at
I would love if there was a feature in IDE's to do something like this
Example of its use:
Collapsed:
Un-collapsed:
Collapsed:
Un-collapsed
I also see this as a compliment to refactoring, whether it's abstracting into functions or more classes. This seems to be agile and deals with uncertainty in the code base especially if you need to neatly layer problems solutions into themselves in ways that would not qualify a new class, or new method.
I would say it's better to break down into separate functions. Adding unnecessary blocks could have surprising consequences for future maintainers. Many editors support using a special syntax within comments to aid code folding and navigation without altering the syntax tree.
[Edit]
Whilst I am really an Emacs-only guy (TM), the docs (https://code.visualstudio.com/docs/editor/codebasics) for Vscode suggest something along the lines of
//#region

Is there a benefit in using Lodash in an AngularJS project? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Has anyone implemented Underscore or Lodash into their existing AngularJS project for a performance boost? If so:
Were the changes something noticeable or something that you would recommend?
Which functionality from Lodash did you find the most benefits?
I have not actually played with Lodash before and was looking into learning it. But I typically like to learn something and then actually use it shortly after, so that the concepts stick better. If I'll get some good benefits out of implementing Lodash, then I think it would be a good time to learn it now.
I do typically need to perform functions such as filtering or finding an object inside some sort of collection, so I'm thinking that's where I would utilize it the most.
Well they have really different purposes.
Angular is to build an application. It helps you to structure your code and separate responsibilities between your components (modules, controllers, services, directives, routers).
Lodash is nice to manipulate collections, arrays, objects, strings, etc. It helps your code to be shorter, cleaner and probably faster. It is really well tested and documented. In my opinion, it makes your job simpler.
I use Lodash for 4 years now. I found it useful in all my projects (Backbone, Angular, JavaScript, node, in the unit tests, in the build configuration files (Grunt, Gulp, Webpack)).
PS: Lodash is also a must-have to go into functional programming in JavaScript.
Edit: Example of searching that you can't easily achieve without Lodash

How to keep track of my data structures? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a javascript developer for a year now but I lack some architectural/engineering background as I was lazy in college.
In the beginning I was writing small scripts with relatively small and simple objects.
As my projects are getting bigger, I tend to use bigger and more complex objects which reflect 4-5 basic data structures which I use in various parts of my application.
I'm looking for the best way to document/keep track of the structure of these objects because when I make a new module that will use one the them, I have to make use they will respect their structure and interface so the previous/next modules using them won't break.
What I was doing until now was to document an object like this:
/** description of the object/data structure
var myObject = {
property1: "", //explain here what is this property and what type it is (number,string etc)
property2:blabla,
etc...
}
*/
This ended up to huge parts of comments which are ugly in the code and distructing too.
Could you suggest some ways of either visualize my objects/data structures or document them so I can fast recall how they should look like?
There are several tools for that out there, but here's a few:
njsdoc - "NJSDoc is a Documentation tool for JavaScript that
works by executing code."
JSDuck
jsdoc
YUIDoc
Natural Docs
DocumentJS
I think you might be interested in the information provided here:
http://javarevisited.blogspot.gr/2011/08/code-comments-java-best-practices.html
It's about java but they can also be applied in Javascript (some of them)
Summarizing the key points:
Focus on readability of code
Don't write what code is doing
Always write why you are writing this piece of code
Always try to finish your comment in as few words as possible
Always put comment while commiting code in source control repository
Give your code to fellow developer to understand
Regarding your code, I have to say that from personal experience I find that writing comments on the previous line rather than next to the code, is more clear and easy to read.
E.g.
var myObject = {
//explain here what is this property and what type it is (number,string etc)
property1: "",
property2:blabla,
etc...
}

technical considerations for including an extraneous javascript library in a Rails project [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I recently included Handlebars.js in a rails project, and a coworker balked at the notion. What are the realistic technical considerations when including an extra javascript library into a rails project?
Does the addition of an extraneous library significantly slow down the site delivery and user experience? Is this an example of engineering drama?
Has this been measured?
Adding additional libraries slows down the site delivery by several hundred milliseconds. It also requires some client time to parse and run its onload()-type functionality. From a human standpoint, it requires a bit of time to get used to using the new library. Depending on the level of complexity, usefulness, and time-saving of the library, this may be an acceptable tradeoff.
Handlebars is a great tool for templating, but you really need everybody on your team to be on board to use it. It's not very nice to simply introduce a brand new way of doing things without really discussing things. Handlebars is a big enough change to warrant at least a discussion, if not a vote.
If you were just wanting to put it there to see if it would work in the future, or maybe just convert over a page or two, then you should do that in a separate branch and do a quick prototype and demo for the team.
Depending on whether there is a valid business case and legitimate usefulness, you and the team can decide whether to convert your application to use it.

Building a JavaScript grid from scratch [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am curious to know what it takes to build a JavaScript grid from scratch. The grid should have features like jqGrid http://www.trirand.com/blog/jqgrid/jqgrid.html.
Can anyone please give me inputs?
Thanks
What it takes to build something similar to jqGrid:
A huge, HUGE amount of time.
If something similar to what you want exists already, why would you want to spend lots and lots of time re-inventing the wheel? Anyhow, if you have nothing better to do, want to learn from it or if you are just curious, here is a list of skills that are needed to create a similar system:
HTML object manipulation.
Style manipulation.
Tons of different event handlers.
AJAX to grab (pages of) documents to display. Probably some server-side stuff too...
Creating of a nice layout system wich works in every browser.
Creating handlers to read and manage the different file types to support (XML, JSON, etc)
Creating HTML forms and reading them out with JS and then use AJAX to resave an XML, JSON, etc document back to the server.
An Algorithm to allow searching in the data you display.
Keyboard manipulation and the toggling off of standard key-events.
10. Tons and TONS of debugging to make sure it looks nice in all browsers.
Of course, this is only a tip of the iceberg since I don't really know the jqGrid program myself. I created this list by looking at some of the examples and reading the Features page.
Again, I would not recommend to rebuild such a big system from scratch, but the choice is of course yours ;).

Categories

Resources