>Manually handling the DOM is probably the biggest cause of spaghetti code.
This isn't true. The biggest cause of spaghetti code in "traditional" JS is due to having multiple conflicting sources of truth for the same pieces of state information (usually split between JS variables and DOM) and subsequent multi-directional synchronization.
Having a model that drives all DOM is one way to solve this. However, having "canonical" representation of your state in DOM works as well.
I think manual DOM manipulation and lack of canonical state representation are both sources of spaghetti code; which one hurts more depends on the type of app you're building.
Having the DOM as your canonical representation of state is only suitable for apps with limited state IMO, because your state effectively has to be turned into text (CSS class names and element attributes) whenever it is mutated, which becomes a liability as the complexity of your app state grows.
I will have to disagree with you on this. The answer is not cut and dried though. Code slowly starts to become spaghetti when you start putting in more and more UI logic into it. At one point of time, it just becomes a complete mess of if conditions, $.each loops and when you start putting $("#div").("data-something", "value"), you know its spaghetti time.
Personally, I feel the components approach keeps it sane. Just let your v-dom layer do all the work. Use a state management library if needed.
Yep. And this problem was "solved" long ago via client side templates, MVC from the server to the front-end.
Keeping the model as a single source of truth was still up to the developer though. As was rendering the template after every change. (You controlled how often you wanted to render it.
Backbone tried to organize this via a simple convention. All your Models were backbone models, basically the same as regular arrays/objects but they emitted event. Your Views listened to these events and called render accordingly.
The boilerplate switched from maintaining the models and rendering to setting up what was basically a simple pub/sub.
Still, this boilerplate was too much to actually have to think about for most people. Many from jquery backgrounds, being forced to use Backbone figured out they could just cram all the logic into the render functions. Everything was wrapped as a Model or View despite those features not being used.
Even today there are many Backbone legacy apps written in this shitty way. The existence of backbone just flails around the logic rather than organize it. They are wrappers for the sake for saying "this app is modern because it uses backbone".
What React did with the virtual DOM was eliminate the boilerplate and responsibility of DOM updates. It even combined logic and templating into one thing. With this reduction of concepts, many people or just now getting what MVC actually is.
Keeping a single source of truth is the MAIN thing and it has a long history. For web development with heavy user interaction state management is massively complex.
It would be great if everybody slowed down to truly get what MVC at its core was about. And for the "older" deriders or modern web development to realize that the real-time interactivity exploding the complexity of state DOES necessitate new tools. In fact, more traditional web development is becoming more and more commoditized with less technical skills needed. There is however a large market for JS developers to develop tools (heavy interaction) to replace what traditionally were JVM crud apps. Developing for the web is easier than the JVM. JVM was easier than developing for every OS.
Sadly, the popularity of Java means there was a lot of bad code, poisoning its popularity. The same may happen to javascript with people years from now (or even currently) looking at old backbone, angular, react, node code and deriding shitty "javascript shop culture"
I don't do any web-dev, so I apologize for the simplistic question: what alternatives to JavaScript exist for web-dev? The article hints to there being many alternatives, and that JavaScript may not be right for every project...but I can't think of any alternatives.
Python? C++? Do these languages have strong support for web stuff?
One "alternative" is to do the minimum possible in the browser, and do most of the work on the back end.
For example, if you inspect this page, you'll see that it has about 150 lines of Javascript.
There are two ways to change a webpage:
- manipulate it with Javascript
- reload a new page with the changes applied
If your page loads quickly and not all that often, you can get pretty far without Javascript. If you are willing to tolerate a pageload on each interaction, you don't need any Javascript.
You can use ClojureScript, Elm, TypeScript, or a myriad of other compile-to-JS languages on the frontend. You can use anything on the backend, but React server-side rendering only runs on Node.js AFAIK.
Our product, Elevate Web Builder, allows you to develop single-page web applications using Object Pascal. It uses a component-based approach to development along with WYSIWYG design (drag a component/control from the component palette and drop it on a designer) and a compile-to-JS compiler.
You can see an example of the various controls here:
Most of the code is either a) auto-generated by the IDE (all non-private/public interface code, and all event handlers), or b) part of the "particles" canvas drawing code.
Elm (http://elm-lang.org/) is a particularly elegant language for front-end web development that compiles to JavaScript, but includes things like immutability and strong, static typing right out of the box.
Other languages like C, C++, and Rust can also run on the Web thanks to WebAssembly, a new compiler target for the web that's on by default in Firefox, Chrome, and Safari Technical Preview, and available behind a flag in Edge: http://caniuse.com/#feat=wasm However, interaction between the DOM and WebAssembly is still pretty rough, so it's currently best at numeric / computationasl tasks, not replacing JavaScript entirely.
I have a friend who's currently doing a web frontend for an HPC application in C++ with Wt [1]. It's trying to be like Qt on the desktop; basically all events are sent from the frontend to the backend and handled there, in a normal C++ application. Then the widgets render their updated state and that gets sent back to the browser for integration into the client-side view. Then you're just building applications out of widgets like with a regular old desktop application, which my friend is really happy about since he has a bit of experience with Qt and the like, but absolutely zero experience with HTML/CSS/JS.
Usually you have a client/server architecture where HTML for the site is generated on the server by a multithreaded language. Practically any language can be (and is) used for this, like Perl, Python, PHP, C++, Java, Go, Ruby, C#, Scala, Clojure, Erlang, etc. It's to the point where it feels like literally every language has been used for web dev somewhere. And of course, Javascript, too.
JavaScript is basically the only option for front end web dev (unless you do web assembly, but that's pretty new). There are lots of different JavaScript frameworks that you can use, including react, so I think they are referring to the alternative frameworks rather than languages.
For front-end development some strong options in different languages are: Elm, TypeScript, Reason, Coffeescript (although Coffeescript usage has fallen dramatically every since the newer versions of JavaScript added a lot of its great features).
Python does, and C++ "does". Python has Django and other frameworks, C++ has CGI...but people usually avoid using it if at all possible. The most commmon languages for web development are: HTML, CSS, JavaScript, PHP, Ruby, and Java.
React is 38.7K + 7.3K = 46K minified + gzipped. Jquery is 34.6K. And React is not super-slow. What makes modern sites bloated and slow is definitely not React. Why not use it even for simple UIs (that may grow into complex after some time) if you find it useful and convenient?
React and jQuery are two quite different things. React is more a framework, jQuery more a helper library.
Saying one is slower than the other doesn't really make sense, since they solve problems in different ways. You can argue that in many scenarios with complex front end applications, it's easier to avoid performance or spaghetti issues when using React instead of jQuery, but there are also cases where jQuery is more convenient and leaves you with more control.
What about 'view state' such as which tokens have been typed into a typeahead/tagging style input? Or the expansion state of levels of a tree view? The active tab of a tabbed UI?
[+] [-] romaniv|9 years ago|reply
This isn't true. The biggest cause of spaghetti code in "traditional" JS is due to having multiple conflicting sources of truth for the same pieces of state information (usually split between JS variables and DOM) and subsequent multi-directional synchronization.
Having a model that drives all DOM is one way to solve this. However, having "canonical" representation of your state in DOM works as well.
[+] [-] mambodog|9 years ago|reply
Having the DOM as your canonical representation of state is only suitable for apps with limited state IMO, because your state effectively has to be turned into text (CSS class names and element attributes) whenever it is mutated, which becomes a liability as the complexity of your app state grows.
[+] [-] agnivade|9 years ago|reply
Personally, I feel the components approach keeps it sane. Just let your v-dom layer do all the work. Use a state management library if needed.
Just my 2 cents.
[+] [-] dlwdlw|9 years ago|reply
Keeping the model as a single source of truth was still up to the developer though. As was rendering the template after every change. (You controlled how often you wanted to render it.
Backbone tried to organize this via a simple convention. All your Models were backbone models, basically the same as regular arrays/objects but they emitted event. Your Views listened to these events and called render accordingly.
The boilerplate switched from maintaining the models and rendering to setting up what was basically a simple pub/sub.
Still, this boilerplate was too much to actually have to think about for most people. Many from jquery backgrounds, being forced to use Backbone figured out they could just cram all the logic into the render functions. Everything was wrapped as a Model or View despite those features not being used.
Even today there are many Backbone legacy apps written in this shitty way. The existence of backbone just flails around the logic rather than organize it. They are wrappers for the sake for saying "this app is modern because it uses backbone".
What React did with the virtual DOM was eliminate the boilerplate and responsibility of DOM updates. It even combined logic and templating into one thing. With this reduction of concepts, many people or just now getting what MVC actually is.
Keeping a single source of truth is the MAIN thing and it has a long history. For web development with heavy user interaction state management is massively complex.
It would be great if everybody slowed down to truly get what MVC at its core was about. And for the "older" deriders or modern web development to realize that the real-time interactivity exploding the complexity of state DOES necessitate new tools. In fact, more traditional web development is becoming more and more commoditized with less technical skills needed. There is however a large market for JS developers to develop tools (heavy interaction) to replace what traditionally were JVM crud apps. Developing for the web is easier than the JVM. JVM was easier than developing for every OS.
Sadly, the popularity of Java means there was a lot of bad code, poisoning its popularity. The same may happen to javascript with people years from now (or even currently) looking at old backbone, angular, react, node code and deriding shitty "javascript shop culture"
[+] [-] bmer|9 years ago|reply
Python? C++? Do these languages have strong support for web stuff?
[+] [-] elevensies|9 years ago|reply
For example, if you inspect this page, you'll see that it has about 150 lines of Javascript.
There are two ways to change a webpage:
- manipulate it with Javascript
- reload a new page with the changes applied
If your page loads quickly and not all that often, you can get pretty far without Javascript. If you are willing to tolerate a pageload on each interaction, you don't need any Javascript.
[+] [-] pitaj|9 years ago|reply
[+] [-] TimJYoung|9 years ago|reply
You can see an example of the various controls here:
http://www.elevatesoft.com:8081/controlsdemo/controlsdemo.ht...
The code for the example is here:
http://www.elevatesoft.com/controlsdemo_code.txt
Most of the code is either a) auto-generated by the IDE (all non-private/public interface code, and all event handlers), or b) part of the "particles" canvas drawing code.
[+] [-] callahad|9 years ago|reply
Other languages like C, C++, and Rust can also run on the Web thanks to WebAssembly, a new compiler target for the web that's on by default in Firefox, Chrome, and Safari Technical Preview, and available behind a flag in Edge: http://caniuse.com/#feat=wasm However, interaction between the DOM and WebAssembly is still pretty rough, so it's currently best at numeric / computationasl tasks, not replacing JavaScript entirely.
[+] [-] majewsky|9 years ago|reply
[1] http://www.webtoolkit.eu/
[+] [-] tboyd47|9 years ago|reply
[+] [-] GhostVII|9 years ago|reply
[+] [-] vmasto|9 years ago|reply
[+] [-] robojamison|9 years ago|reply
[+] [-] vinceguidry|9 years ago|reply
http://ruby-hyperloop.io/
[+] [-] ungzd|9 years ago|reply
[+] [-] blauditore|9 years ago|reply
Saying one is slower than the other doesn't really make sense, since they solve problems in different ways. You can argue that in many scenarios with complex front end applications, it's easier to avoid performance or spaghetti issues when using React instead of jQuery, but there are also cases where jQuery is more convenient and leaves you with more control.
[+] [-] z3t4|9 years ago|reply
[+] [-] mambodog|9 years ago|reply
[+] [-] iamleppert|9 years ago|reply
[deleted]