JavaScript framework for frontend web apps

[Picuino]

I am completely new to developing JavaScript applications with web frontend frameworks.
So far I have developed some programs by hand directly in JavaScript to perform calculations or to present quiz type questionnaires.

I have also modified the source code of the Falstad circuit simulator (https://www.falstad.com/circuit/) to adapt it to my website. This simulator is programmed in Java, which is then translated into JavaScript with Google's GWT library.

After tinkering with the Falstad program I have been encouraged to make more elaborate applications in JavaScript, but I find the Java+GWT programming model a bit confusing and little used by programmers.

Do you know any JavaScript framework that is well suited to develop such applications with menus, drawings, simulations, etc.?

[Picuino]

There are many comparisons on JavaScript frameworks and libraries, but in general they do not describe in depth the different frameworks to be able to choose between them.

https://hackr.io/blog/best-javascript-frameworks
https://www.lambdatest.com/blog/best-javascript-frameworks/
https://ninetailed.io/blog/best-javascript-frameworks/


Edit: What I am looking for is something similar to Visual Basic, but to make web applications that run on the user's computer and use JavaScript languaje.

[Picuino]

Drawing libraries in JavaScript:

https://code.tutsplus.com/best-free-and-open-source-drawing-libraries-in-javascript--cms-37731a

[dferyance]

Most of what people consider JavaScript frameworks don't give you a GUI application framework but are just ways to avoid modifying the DOM directly. Angular and React are the common ones for that.

It sounds like you more would be interested in a component library like extjs or wijimo.

I agree with moving away from GWT, but be careful in the javascript world. Libraries go in and out of vogue very quickly. Many web applications end up going through multiple re-writes as frameworks popup and get replaced.

[Nominal Animal]

Do you need a framework to create your frontend web apps?  What for?

While I prefer to not use any because the ones I create just don't need them, I do realize there are some use cases where they can be very useful.  The point is to try it first without, so that 1) you find out what you need most help with, so you can evaluate different frameworks based on how well they support you with that, and 2) you may find out that you don't really need one (that libraries for stuff like FFT/DCT/iDCT suffices), and can make yours more lightweight and avoid the downsides of the existing frameworks.

In short, if you try and do some web apps without any frameworks, you'll learn how to evaluate the different frameworks for your specific needs.

[Picuino]

Do you need a framework to create your frontend web apps?  What for?

There are two main reasons:
1. to standardize and make it easier and more homogeneous the menus and drop-down windows that the application has.
2. The most important. To easily draw on screen and manage the screen drawings (for example air tubes, valves and pistons in a pneumatics simulation program).

[Picuino]

Since there are so many frameworks and libraries out there, it's easy to get lost or stumble around, so I wanted to get an opinion on where to start.
I think I'm going to start testing with React + paper.js, but I don't know which React framework to start trying to make a pneumatic simulator type application (Maybe Gatsby) I'm kind of lost with so many options.

[Nominal Animal]

1. to standardize and make it easier and more homogeneous the menus and drop-down windows that the application has.

I use HTML and CSS for this.

2. The most important. To easily draw on screen and manage the screen drawings (for example air tubes, valves and pistons in a pneumatics simulation program).

I use a mix of Canvas and SVG for these.  Canvas is useful when you need to do pixel-level manipulation, but SVG gives you crisp visuals on any resolution.

[Picuino]

And what about SVG.js?
https://svgjs.dev/docs/3.0/

[Nominal Animal]

And what about SVG.js?
https://svgjs.dev/docs/3.0/

What about it?  The library provides just another API that trades execution speed for somewhat shorter source code.  For single use statements the longer native expressions are fine in my experience, and if repeated I write dedicated functions.  (For node properties like in the example you linked to, I prefer a function that takes a node reference, and an object containing the attributes to set for the node.)

In development terms, getting the code structure and approach right from the get go is the most important thing.  For example, you don't want to do any kind of heavy calculation in an event handler; you want the event handler to trigger e.g. a timeout, so that the actual heavy computation is done in a background thread (preferably a web worker) and does not block any UI events.
(The same applies to desktop GUI toolkits like Qt and Gtk, too.)
Stuff like how many consecutive lines of code you need for a specific task is basically irrelevant; anything repeated can be refactored and combined later, when you know approximately what kind of operations you need.

I often stride for a library-style modular approach, mostly so that I can refactor any part I consider in need of it; nothing is absolutely final, ever, but I carefully track any cross-dependencies and internal interfaces I need.
My first version often ignores most visual details (often using crude HTML table and input fields for the UI), and simply tries to implement the functionality.  That way I find out exactly what the implementation needs.  It also tells me what kind of DOM manipulation is common, so I can design a function to optimize those.

I am not telling you that frameworks are evil/bad.  I am only saying that I personally do not need them for HTML+CSS+SVG+JavaScript applications, and that knowing how to do that kind of "bare browser" apps should help you a lot in evaluating what kind of frameworks and libraries work best for your needs and workflow.  You might find you don't need a framework, or you might find you gain a lot from using specific frameworks for specific kinds of apps.

The idea that you need some kind of framework for web apps is demonstrably false.  They can be useful, and using dedicated libraries for stuff like FFT definitely makes sense; but the situation is very different from e.g. desktop application development where you do need a widget toolkit or framework, be it portable or OS-specific.

[dferyance]

IMO web frameworks don't really help solve the problems that modern web development has. They used to though. Back when browsers behaved differently, there were DOM differences, AJAX worked different, SVG vs VML that were all complications that a web framework could help. And don't get me started on box model! Now DOM manipulation is easy and standard. I've spent a lot of time troubleshooting odd react bugs, angular build issues, package upgrades and so on. I've grown to doubt that the advantages of these frameworks make up for the time-sink they cause. Now if you enjoy those kinds of problems then by all means have fun with a framework. But I see this as a distraction and not really a helper when it comes to modern web development.

But I would recommend adopting some form of control library. The browser built-in controls for forms are quite limiting and designing your own takes time away from what your project is about. You may have to adopt a web framework just because the control library you want to use depends on one. But if this is the case, it doesn't mean you have to use the framework for all the code you write.

[Picuino]

OK. I'm going to continue with JS+CSS+HTML bare metal. And I'm going to try SVG without framework. Only hope not to die trying.

[Nominal Animal]

Only hope not to die trying.

Do remember that if you encounter a particularly intractable problem, you can always do a mini-project to test how to solve that detail, that hill, by using different libraries or frameworks.

There is no need to die on any particular hill.  When you are in control of development, you can at any point teleport back and try another approach, even picking a completely different hill if needed.

I personally have a habit of mapping interesting/steep/scary hills beforehand, whenever they occur to me.  I have thousands of these, in various programming languages (and some in pure math), each in their own directory, with a README file describing the problem and the solution approach.  It is addictive and fun.  The main thing I've learned doing that is that often the actual hill is very different than it looked like up front, and the only way to die there is to stubborny stick to ones own preconceptions and refuse to learn and adjust.  That is, surprisingly often one finds that the problem one is trying to solve is easily avoided altogether by adjusting ones approach.  (If you do a search on "underlying" in my own posts, you'll see what I mean.)

[Picuino]

I have found an interesting library from which to take ideas or, directly, to use in projects for drawing on infinite canvas.

Repo: https://github.com/excalidraw/excalidraw
App: https://excalidraw.com/