6 ms·

When Does a Project Need React?

33 points by mambodog 9y ago

bmer 9y ago
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?
- robojamison 9y ago
  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.
- GhostVII 9y ago
  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.
  - vmasto 9y ago
    Certainly not the only language, see my reply above (or below depending). There are a lot of great languages which either compile to JS perfectly or have been built with that purpose in mind.
  - deleted 9y ago
    [deleted]
  - cholantesh 9y ago
    Does WebAssembly actually replace JS or is it another language that compiles into it?
- vmasto 9y ago
  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).
- pitaj 9y ago
  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.
  - vmasto 9y ago
    but React server-side rendering only runs on Node.js AFAIK. There are a few solutions for Ruby, PHP and Python although I have no experience with them and how well they perform/work.
    - drdaeman 9y ago
      Unless it's some real magic (please share if it is), I believe the best they can do is either spawn a node process from Ruby/PHP/Python, or use embedded v8 or similar interpreter. Which is not any different from running node "the normal way". React is implemented in JS and uses JS to declare components, and it would be fun if there is some working JS-to-Python (-to-PHP/-to-Ruby) translator that is good enough to translate React code to run "natively".
      - vmasto 9y ago
        Oh yeah you're absolutely right of course. Not saying it doesn't run V8 or some kind of interpreter in the background (I actually have no idea how they work), just think that's abstracted away and I don't think there's any JavaScript setting up required from the developer.
- callahad 9y ago
  Elm (http://elm-lang.org/ 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 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.
- elevensies 9y ago
  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.
  - GuiA 9y ago
    This advice only applies for non interactive stuff though. What if I want to build a spreadsheet, audio editor, vector-based illustrator, etc. in the browser?
    - elevensies 9y ago
      Yeah, if the system can't be represented as hyperlinked documents, then you're going to be married to the browser APIs which are in Javascript -- so you can either use Javascript or a tool that outputs Javascript.
  - jasode 9y ago
    >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. To put some concrete examples to that... The HN page uses javascript[1] for the upvote/downvote buttons and also to collapse/expand comments. It would be very disruptive and jarring to reload an entire page after someone clicks a vote button. Also, mobile phone users would be doubly punished since a page reload is slower than desktop highspeed internet. A good example of a website not requiring javascript without penalizing user-interface usability is Wikipedia text pages. [1] https://news.ycombinator.com/hn.js https://news.ycombinator.com/hn.js
- vinceguidry 9y ago
  I'm enjoying using Hyperloop where you write Ruby everywhere. http://ruby-hyperloop.io/ http://ruby-hyperloop.io/
- tboyd47 9y ago
  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.
- TimJYoung 9y ago
  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: http://www.elevatesoft.com:8081/controlsdemo/controlsdemo.html http://www.elevatesoft.com:8081/controlsdemo/controlsdemo.ht... The code for the example is here: http://www.elevatesoft.com/controlsdemo_code.txt 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.
  - rpeden 9y ago
    Looks like an interesting product, Tim. I've always enjoyed Pascal so I'll give your trial version a try.
    - TimJYoung 9y ago
      Thanks very much. If you have any feedback or questions, please feel free to contact us at support@elevatesoft.com . We're always looking for constructive feedback, especially if you normally use plain JS/HTML/CSS for coding or use a JS framework like Angular or React.
- majewsky 9y ago
  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. [1] http://www.webtoolkit.eu/ http://www.webtoolkit.eu/
iamleppert 9y ago
The simple answer: Never.
romaniv 9y ago
>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.
- mambodog 9y ago
  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.
- dlwdlw 9y ago
  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"
ungzd 9y ago
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?
- blauditore 9y ago
  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.
z3t4 9y ago
you should not store the state in the view layer. the easiest aproach is to store the state in the backend database layer.
- mambodog 9y ago
  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?
  - z3t4 9y ago
    If nothing depends on the tagging, tree view or witch tab is active, then it's fine. Or if the state is discarded once the user click the "post" button it's also fine. But as features gets added things tend to "entangle" and things get more complicated. You'll end up with weird bugs like when the user has the app open in two tabs, or on two or more devices, where for example a message is marked as "read" on one devices but not the other. Or if two models interacts with the same view and races to change the state or just overwrites it.

33 points by mambodog 9y ago

bmer 9y ago

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?

robojamison 9y ago
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.
GhostVII 9y ago
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.
- vmasto 9y ago
  Certainly not the only language, see my reply above (or below depending). There are a lot of great languages which either compile to JS perfectly or have been built with that purpose in mind.
- deleted 9y ago
  [deleted]
- cholantesh 9y ago
  Does WebAssembly actually replace JS or is it another language that compiles into it?
vmasto 9y ago
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).
pitaj 9y ago
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.
- vmasto 9y ago
  but React server-side rendering only runs on Node.js AFAIK. There are a few solutions for Ruby, PHP and Python although I have no experience with them and how well they perform/work.
  - drdaeman 9y ago
    Unless it's some real magic (please share if it is), I believe the best they can do is either spawn a node process from Ruby/PHP/Python, or use embedded v8 or similar interpreter. Which is not any different from running node "the normal way". React is implemented in JS and uses JS to declare components, and it would be fun if there is some working JS-to-Python (-to-PHP/-to-Ruby) translator that is good enough to translate React code to run "natively".
    - vmasto 9y ago
      Oh yeah you're absolutely right of course. Not saying it doesn't run V8 or some kind of interpreter in the background (I actually have no idea how they work), just think that's abstracted away and I don't think there's any JavaScript setting up required from the developer.
callahad 9y ago
Elm (http://elm-lang.org/ 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 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.
elevensies 9y ago
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.
- GuiA 9y ago
  This advice only applies for non interactive stuff though. What if I want to build a spreadsheet, audio editor, vector-based illustrator, etc. in the browser?
  - elevensies 9y ago
    Yeah, if the system can't be represented as hyperlinked documents, then you're going to be married to the browser APIs which are in Javascript -- so you can either use Javascript or a tool that outputs Javascript.
- jasode 9y ago
  >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. To put some concrete examples to that... The HN page uses javascript[1] for the upvote/downvote buttons and also to collapse/expand comments. It would be very disruptive and jarring to reload an entire page after someone clicks a vote button. Also, mobile phone users would be doubly punished since a page reload is slower than desktop highspeed internet. A good example of a website not requiring javascript without penalizing user-interface usability is Wikipedia text pages. [1] https://news.ycombinator.com/hn.js https://news.ycombinator.com/hn.js
vinceguidry 9y ago
I'm enjoying using Hyperloop where you write Ruby everywhere. http://ruby-hyperloop.io/ http://ruby-hyperloop.io/
tboyd47 9y ago
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.
TimJYoung 9y ago
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: http://www.elevatesoft.com:8081/controlsdemo/controlsdemo.html http://www.elevatesoft.com:8081/controlsdemo/controlsdemo.ht... The code for the example is here: http://www.elevatesoft.com/controlsdemo_code.txt 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.
- rpeden 9y ago
  Looks like an interesting product, Tim. I've always enjoyed Pascal so I'll give your trial version a try.
  - TimJYoung 9y ago
    Thanks very much. If you have any feedback or questions, please feel free to contact us at support@elevatesoft.com . We're always looking for constructive feedback, especially if you normally use plain JS/HTML/CSS for coding or use a JS framework like Angular or React.
majewsky 9y ago
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. [1] http://www.webtoolkit.eu/ http://www.webtoolkit.eu/

iamleppert 9y ago

The simple answer: Never.

romaniv 9y ago

>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.

mambodog 9y ago
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.
dlwdlw 9y ago
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"

ungzd 9y ago

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?

blauditore 9y ago
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.

z3t4 9y ago

you should not store the state in the view layer. the easiest aproach is to store the state in the backend database layer.

mambodog 9y ago
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?
- z3t4 9y ago
  If nothing depends on the tagging, tree view or witch tab is active, then it's fine. Or if the state is discarded once the user click the "post" button it's also fine. But as features gets added things tend to "entangle" and things get more complicated. You'll end up with weird bugs like when the user has the app open in two tabs, or on two or more devices, where for example a message is marked as "read" on one devices but not the other. Or if two models interacts with the same view and races to change the state or just overwrites it.