10 ms·

Ask HN: Is there a sane alternative to Angular and React?

Slightly tongue-in-cheek but nonetheless serious question. I've recently started looking into JavaScript UI frameworks and have the uneasy feeling they are actually worse than the now defunct Flash and Silverlight. Angular and React seem to be a mish-mash of proprietary syntax and technologies (AtScript, JSX, TypeScript etc.) that paper over some of the cracks in JavaScript and CSS. Are these transitory technologies that will be replaced by something better in the near future? Is there a better alternative available today?

elviejo 9y ago
Excellent question. Turns out there is: http://elm-lang.org http://elm-lang.org Is a Haskell inspired programming language that makes developing front end a delight. It helps to build Reliable front ends. Watch this conference to get a sense of what Elm does. Making the Backend Team Jelous[1] Plus the Elm architecture makes everything orderly and easy to understand. Quite a change from the mess of react components and Angular rewrites. [1] https://youtu.be/FV0DXNB94NE https://youtu.be/FV0DXNB94NE
- martijn_himself 9y ago
  This looks great, and thanks for providing the links. Is Elm production ready? Have you used it to build any apps?
  - lisardo 9y ago
    I talk about my experience. I deployed Elm to production in several projects for the biggest group fitness company in the US. It's incredible. Compiler errors are incredible. No undefined bullshit. It's purely functional, so the code you need to understand at the same time is always gonna be inside 20 lines. And you can use it with javascript if you want too. You will learn a lot using a pure functional programming language. Programming is about transforming data, so even if I go back to any OO language I learned that state can cause several problems.
    - martijn_himself 9y ago
      That sounds great. Did you have to convince anyone to adopt Elm or were you free to pick your language of choice? Using a pure functional language appeals to me as well.
  - lsjroberts 9y ago
    NoRedInk use it in production and are quite big advocates (having hired the BDFL) - http://tech.noredink.com/ http://tech.noredink.com/
- citrusx 9y ago
  Obligatory counterpoint: http://reasonablypolymorphic.com/blog/elm-is-wrong http://reasonablypolymorphic.com/blog/elm-is-wrong
elviejo 9y ago
Excellent question. Turns out there is: http://elm-lang.org http://elm-lang.org Is a Haskell inspired programming language that makes developing front end a delight. It helps to build Reliable front ends. Watch this conference to get a sense of what Elm does. Making the Backend Team Jelous[1] Plus the Elm architecture makes everything orderly and easy to understand. Quite a change from the mess of react components and Angular rewrites. [1] https://youtu.be/FV0DXNB94NE https://youtu.be/FV0DXNB94NE
fiiv 9y ago
Both TypeScript and JSX are optional, you don't have to use either with them. There is a ton of different choices out there to choose from if React and Angular are not your thing. One example: Ember.js recently moved their rendering into a standalone library called Glimmer (https://glimmerjs.com https://glimmerjs.com), which is a bit React-like in its approach but nonetheless different. They advocate Typescript as well but don't require it. Elm seems like a thing people like as well, check it out here: http://elm-lang.org http://elm-lang.org - but it's a js compiler so it's also what you might classify as a "proprietary" tech. If you haven't already, check out http://todomvc.com http://todomvc.com - it's the same sample todo app built in a buttload of frameworks so you can compare which one you like.
- martijn_himself 9y ago
  It is interesting you are the second person replying in this thread to point to Elm. I must check it out! I suppose both TypeScript and JSX are optional but they are symptomatic in a way in that their existence suggests the alternatives are sub-optimal (i.e. a combination plain JavaScript or a clear demarcation of markup and styling).
  - ooqr 9y ago
    Elm is neat but definitely goes against the very properties you're looking for. But if you want to take a peek down that road: http://mutanatum.com/posts/2017-01-12-Browser-FP-Head-to-Head.html http://mutanatum.com/posts/2017-01-12-Browser-FP-Head-to-Hea...
daleholborow 9y ago
http://aurelia.io/ http://aurelia.io/ I am a backend guy with some experience in Angular 1.5, Backbone etc, but currently dabbling in the front end again, and Aurelia looks pretty cool. It seems like the least "learn our custom syntax and voodoo" option, so I'm going to give it a spin.
Marazan 9y ago
React is, in many ways, a take on Flex's excellent MXML updated for a JS world that understands that 2-way data binding is the devil. It is very sane.
- taude 9y ago
  I agree, I feel React, much like Flex's MXML forces the developers to componetize the entire UI as part of the development process in a way that feels natural.
roro5678 9y ago
https://vuejs.org/ https://vuejs.org/ is my favorite alternative
subsidd 9y ago
If you haven't yet you must look into Vuejs as well - https://vuejs.org/ https://vuejs.org/
- idkfa 9y ago
  and Quasar too - http://quasar-framework.org/ http://quasar-framework.org/
skl_ 9y ago
https://mithril.js.org/ https://mithril.js.org/
rlp 9y ago
I think React is actually quite sane to use now. However, if you're looking for the future, you may want to check out Web Components and Polymer: https://www.polymer-project.org https://www.polymer-project.org
- coldtea 9y ago
  Correction: if you're looking for what was once touted as the future, but never came to be and probably never will, and has been surpassed by React (and/or Angular), check Web Components and Polymer. It's a committee driven over-engineered spec that's not going to be any more succesful than XHTML...
  - ergo14 9y ago
    Yeah, sure that is the reason lots of big enterprises adopted it for their front facing products :-)
coldtea 9y ago
>Slightly tongue-in-cheek but nonetheless serious question. I've recently started looking into JavaScript UI frameworks and have the uneasy feeling they are actually worse than the now defunct Flash and Silverlight. Angular, at least up to 2.0 which I've checked, it's a conceptual mess. React, on the other hand, is conceptually better than Flash and Silveright, and even has more powerful abstractions in several areas. The problem is that React handles a small part of the logic that Flash and Silverlight do (or, something like Flex would), and does so at various levels of the whole stack (some low level like diff-ing repaints, others at higher level like component nesting), and all the wiring and extra handling is left to the programmer to handle. For all the progress with React and co, it's still the wild west as far as programming efficiency is concerned. Elm is not much better either.
leke 9y ago
VueJS is kinda got parts of both, but is entry level friendly. I'm probably not the best to give this advice though.
robinhouston 9y ago
Svelte is pretty elegant: https://svelte.technology/ https://svelte.technology/
taude 9y ago
Server-side rendering with partial views? You're never going to get something as simple as Flash, with a write-once works everywhere. But your user's aren't going to be annoyed at the crappy UX that Flash (or Flex) applications brought us. EDIT: I'm dead serious about this, with the concept of isomorphic apps, I'm not convinced building thick Javascript-based clients is necessarily the way to go for a lot of use cases, including the traditional business information worker-type of application. With these modern JS frameworks working on the concept of rendering virtual DOM diffs, why not just render the partial diff on the server and swap out the specific DOM on the client page?
- ooqr 9y ago
  The application I've inherited and support is a Rails app that does this. I hate this pattern. It's very difficult to change things and burdens the backend developer with the responsibility.
  - fanpuns 9y ago
    I'm pretty new to Rails, but I'm implementing something very similar to this. Is there's any open source mature Rails app that might demonstrate what your seeing/maintaining? I'd be curious to see how this pattern looks as it grows.
PaulHoule 9y ago
Definitely worse than Silverlight!
Clownshoesms 9y ago
This whole JavaScript "revolution" seems surreal to me. I still can't believe they snuck JavaScript onto the backend. Edit: Angry is a better word.
- nebabyte 9y ago
  'Angry' will be me once they start publishing metrics on how optimized JS (or what, webASM or something?) beats out native. Oh, I'm sure it's being done already. At this point I'm just back in my comfort zone. Let them battle it out for a few more years, I can probably make my peace with whatever's left over or stay in my niche.
  - martijn_himself 9y ago
    Out of curiosity, what is your niche?
- marcins 9y ago
  Server-side JS has existed as long as JS itself. Netscape had something called LiveWire as part of their Enterprise Server in 1995.
ZenPsycho 9y ago
No, none of this platform is sane. It's not designed, it's evolved. Embrace the madness or fail. The web is not desktop applications. The network is always there, the network is slow, the network is asynchronous. The network can fail. You cannot abstract over this with a clever library. Unless you don't care about pushing out 4mb of javascript before first render, you can't ignore it. The front-end is not a server based application. It's relatively straightforward to just echo out some html from a server. This works pretty well, and conceptually it's easy. But the UI has events. Events are asynchronous. You cannot abstract over this. It cannot be ignored. Unless all you need is the off the shelf components and no custom interactions, animations or logic. Every UI framework for the front end is aimed at solving a specific problem, a specific complexity. Before adopting ANY of them, you have to seriously ask yourself if you actually have that problem before just jumping on the bandwagon- in most cases, in my experience, you probably don't. But by adopting some "framework" you've just added a problem. you've added a complexity. If you had the problem, it might be worth it. You might have netted less complexity. But probably not. Browsers have come a long way in 10 years, if you haven't been paying attention. Most of the cross browser problems have disappeared unless you're using new things like web sockets, web rtc or indexedDB, or something crazy like that. The browser is already a UI framework with all the basic widgets, text layout, image manipulation, audio processing, etc. etc. From a perspective of a user of your website or service, ask yourself what value something like react is really adding.
- martijn_himself 9y ago
  This is one the most insightful responses, so much of this rings true to me. It's relatively straightforward to just echo out some html from a server. This works pretty well, and conceptually it's easy. I remember reading an article recently (I can't find it) that argued that the human readable part of the web should have been just this, a place for static pages to render and be read. The reason it works so well is because that was what it was designed and build for. So it has basically just completely escalated by its attempt to replace native applications. Except it is and always will be worse at everything a native application does. You have to seriously ask yourself if you actually have that problem before just jumping on the bandwagon. I suppose that is sort of complicated by the fact that every framework out there tries to sell itself as the best thing since sliced bread, except advertising what is for. Browsers have come a long way in 10 years, if you haven't been paying attention. It is absolutely amazing what has been achieved.
CosmicShadow 9y ago
ASP.NET MVC for the back end is beautiful, clean, simple, and then you can use a bit of jQuery on the front or use Knockout JS if you want to do data-binding with MVVM and not have to learn with or deal with all the other crap of those frameworks mentioned as that is what MVC already does for you. Don't reinvent a browser in the browser or waste more time on JS than you need to, you'll feel so clean separating things.
- stephenr 9y ago
  I think this could be simplified a little, and still remain true: > 'Boring' language OOP/MVC for the back end is beautiful, clean, simple, and then you can use a bit of jQuery on the front This bit should be considered golden advice IMO: > Don't reinvent a browser in the browser or waste more time on JS than you need to,
- n0rm_ 9y ago
  Please don't. I already have a really hard time communicating reason to m$ people. They get these ridiculous ideas from the likes of you, and waste countless hours beating a dead horse. There will be no servers to configure in the future. We will be spinning up containers in a swarm, and communicating with those services via de-centralized lambda function pools. Bulk of future devs will spring up in frontend. m$ lost its monopoly in backend to AWS and the likes. Do you think they started OSS because they are nice? They are desperate and throwing money at the problem. > jQuery on the front or use Knockout JS if you want to do data-binding with MVVM I'll say the same thing to someone who tried to make a case for PHP; you are doing a disservice to the clueless reader (likely a new grad). Kids, listen to me; don't ever say that in a job interview. You'll be politely rejected, and never hear from them again. If you started to use jQuery after 2016, just keep that to yourself. It shouldn't matter that much, but it does. It signals you are comfortable with being mediocre. > waste more time on JS than you need to Again; just don't. Just because your past 10 years of acting "1337 programmer" through drag-n-drop some VC (nuget?) modules vanished doesn't mean future programmers need to go through that soul crushing m$ travesty. What is the UNIX philosophy? What is m$ (still) trying to do? Do you think those guys don't know how to pick successful ventures? Think. You are up against a company here, not a friendly group of developers. Not that you can really resist the change, mind you. I'm not asking you to stop peddling your inferior wares because I'm afraid you might stop progress. I'm suggesting it because you will be left holding the bag when m$ finally starts chopping bits off the MSDN network, and Oracle silently discontinues Java after v9. Try to advance, not defend your crumbling castle. p.s. Had to create a new account just to reply to this. Hadn't logged in in a couple years.
unherd 9y ago
vue.js ... absolutely amazing.
dz0ny 9y ago
Vue.js is saner because it does not have that JSX nonsense and you can still write most of the code however you like, and later upgrade to babel,typescript etc. Particularly I like component structure https://vuejs.org/v2/guide/single-file-components.html https://vuejs.org/v2/guide/single-file-components.html which kinda does the same in more traditional approach.
- Traubenfuchs 9y ago
  It also works well in non npm/node.js environments.
- heidar 9y ago
  The main reason I didn't consider Vue was because I like coupling HTML and JS like React does. But this seems like a much nicer way of doing it than JSX. I'll have to give Vue another chance.
  - masklinn 9y ago
    > But this seems like a much nicer way of doing it than JSX. Note that there is no requirement to use JSX, JSX is just syntactic sugar for the underlying function calls which you can use directly: https://facebook.github.io/react/docs/react-without-jsx.html https://facebook.github.io/react/docs/react-without-jsx.html That's useful when you don't want to add a local compilation file when developing/debugging.
    - jazoom 9y ago
      And Vue can use JSX.
    - dlwdlw 9y ago
      This argument doesn't make sense because doing it like that is even worse that JSX.
- jonheller 9y ago
  Hear hear. I used Angular for about a year and tried to use React for about six months. Then I tried Vue and I couldn't not believe just how much more sense everything made. Give it a shot.
mb720 9y ago
You can use Scala.js[1] to transpile your Scala code to JavaScript and have type safety between client and server. You don't need to use any frameworks if you use Scala's features on the client well. [1] https://www.scala-js.org/ https://www.scala-js.org/
cies 9y ago
Let me take your question apart a little... > Angular and React seem to be a mish-mash of proprietary syntax and technologies (AtScript, JSX, TypeScript etc.) that paper over some of the cracks in JavaScript and CSS. They are not "proprietary", but such they are partly an attempt to overcome "some of the cracks in JavaScript and CSS". > Are these transitory technologies that will be replaced by something better in the near future? I do not think so. > Is there a better alternative available today? As you mentioned JS (and to a lesser extend CSS) is the problem. A problem that Angular and React do not fix. People in this thread will mention Vue and Svelte as alternatives to Angular and React, but these also do not fix the underlying problem: JS. TypeScript and Flow fix some of JS's problems. But a real next level approach that is available today is given by real compile-to-JS languages: Elm, PureScript and ReasonML. It deserves to be mentioned these are all primarily "functional" languages. And not for no reason, FP is kind of the best option we have to avoid the OO/imperative-dramas we become tired of. And Reason is particularly interesting as it can also compile to native (PureScript as well but not very mature in that regard), it is backed by Facebook (25% of messenger.com is ported to ReasonML already) and thus has well supported React bindings (allowing interop with the React ecosystem).
- a-saleh 9y ago
  I have been playing around with PureScript (more for the fun of learning interesting FP concepts than creating anything useful) and really liked the Purescript Book [0]. Is there something similiar for Reason as well? [0] https://leanpub.com/purescript/read https://leanpub.com/purescript/read
  - cies 9y ago
    Not really. This you've probably seen (the home page): https://facebook.github.io/reason/ https://facebook.github.io/reason/ This is also quite nice (see the example app section at the bottom): https://github.com/vramana/awesome-reasonml https://github.com/vramana/awesome-reasonml Also these talks are interesting (but nothing close to the format of the book you mentioned): https://www.youtube.com/watch?v=_0T5OSSzxms https://www.youtube.com/watch?v=_0T5OSSzxms https://www.youtube.com/watch?v=8LCmLQ1-YqQ https://www.youtube.com/watch?v=8LCmLQ1-YqQ (really bad audio, sorry)
loftsy 9y ago
Dart is a sane language with great tooling. It has its own version of Angular which works great. It is available today!
awjr 9y ago
I cannot fault the communities around React and Angular and the support that they give to each ecosystem. I would say that the React community seems to be 'stronger' these days. I note some people are mentioning other JavasScript frameworks (e.g. http://aurelia.io/ http://aurelia.io/ https://vuejs.org/ https://vuejs.org/ https://mithril.js.org/ https://mithril.js.org/ https://choo.io/ https://choo.io/ https://svelte.technology/ https://svelte.technology/ ) They ALL have their merits, but it all comes down to the development community around them, and for me, the jobs out there. Recently somebody asked in our local JS group what framework to learn and everyone responded with React. The jobs are there, the dev community is strong, and more importantly the learning curve is good, particularly with the hand holding create-react-app now does. Yes, down the line, you will have to learn react-router and maybe redux/mobx, but all in good time.
pcardoso 9y ago
http://intercoolerjs.org http://intercoolerjs.org I'm a big fan of Intercooler.
jonmann 9y ago
Polymer 2.0 is much closer to just writing vanilla HTML, CSS, and JS
jonmann 9y ago
Polymer 2.0 is much closer to just writing vanilla HTML, CSS, and JS
nottorp 9y ago
Speaking of sanity, I've heard that somewhere under these hundreds of layers of libraries that you're supposed to mindlessly install there is a "native" javascript API inside the browser. Is there any comprehensive documentation resource online or offline that teaches you how to use that in a modern browser?
- mcintyre1994 9y ago
  MDN is great: https://developer.mozilla.org/en-US/docs/Web/JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript If you're more of a "show me 30 cool things I can do with none of that baggage" person, I found javascript30.com really fun.
obsurveyor 9y ago
Ractive[1] is pretty good imho. Development runs hot and cold but I've found it a joy to work with. Documentation could be a bit better, especially when it comes to components. [1] http://ractivejs.org http://ractivejs.org
kozak 9y ago
You can also use just the JSX without React (using https://www.npmjs.com/package/nativejsx https://www.npmjs.com/package/nativejsx or similar) to combine parts your own way.
kirankn 9y ago
Elm
levosmetalo 9y ago
Since I discovered Clojurescript using reagent, re-frame and figwheel it is hard to go back to any JS framework, or JS itself. The feedback cycle is so short that it feels like doing Smalltalk properly. Now I wish I could use similar combo for mobile and desktop development.
- bschwindHN 9y ago
  > Now I wish I could use similar combo for mobile and desktop development. Check out "re-natal". That at least gets you mobile, and perhaps desktop once react native has a good desktop story.
dotdotcommadot 9y ago
Being both a TypeScript and Google Dart developer for a few years now (and a former Flash/Flex developer, and still missing lots of aspects of it), I can say: - On browsers: it is what it is. Neither React nor Angular will fix this for you. You're going to have to work with all existing browsers and their issues (which are quite a lot, especially when you want to go little 'deeper down'). - On styling CSS: Either use a framework like Bootstrap or Material Design Lite, or try to use a pre-processor like SASS. LESS and Stylus, also 2 pre-processors, are losing a bit on popularity, or so it seems. SASS is a good 'safe bet'. There's lots of documentation and fairly decent frameworks were made around it. - React and Angular are both really good, have amazing documentation and tutorials. But for me personally, React translates really well my experience from Flash/Flex. Angular is also a very nice framework of course, but it feels to me like it is still more something I would use to make webSITES in, instead of webAPPS (although I'm building a huge app in it right now), since it is not as 'fast' and 'snappy' to create components and an architecture as it is with React. (I'm talking development wise, not performance) - On dependencies: I really dislike the entire dependency hell I always end up in when starting a JavaScript project. Since both JavaScript and TypeScript use NPM (at least, that's the current de-facto standard), TypeScript does not solve this for you. For instance: how do you manage your dependencies? NPM, Nuget or Yarn? What's the difference, and do you have a day to look it all up? How are you building your project and your .sass files? Gulp, Grunt, Webpack, NPM scripts, or just vanilla commandline? If you're creating a new class, how are you going import it in your consumer class? Declare all external JS files in your index.html? Or maybe you prefer CommonJS, RequireJS, UMD, SystemJS or ES2015(=ES6) native modules? And what if one dependency uses another system than you do? - On languages: TYPESCRIPT: it's a very nice and powerful language, but like I said, it hooks into the standard JavaScript ecosystem. On top of the dependency hell, you'll have to use a lot of JS interops (to be able to use existing JS libraries), which aren't always that well maintained. ES6: You could use the ES6 version of JavaScript. You'll need Babel to transpile to ES5 JavaScript, so your code will run in all browsers. No problems with JS interops here, but dependency hell and ecosystem problems will stay. GOOGLE DART: Also an amazing language, written by Google. You can discuss on what's the better language (TypeScript or Dart), but the advantage here is the ecosystem. You build with Pub, you manage your dependencies with Pub, and there's only one way of importing external classes. A lot of modern API's you'll need, like Futures (kind of like Promises), and Streams (like Observables) are built in the language itself, meaning they are maintained and tested by Google. I've been using AngularDart (a Dart-based Angular) for over 6 months now, and it's going really well. So for me, this results in: - JavaScript ES6: + Simple and fun language + Close to old-skool JavaScript - Too limited in OOP features - Inconsistent and way too fast changing JavaScript ecosystem (dependency management, build tools, importing external libraries, ..) - TypeScript: + Very nice language + Projects like Angular and React are written in it, so it's easy to find tutorials in TypeScript + Popular, and well documented - Inconsistent and way too fast changing JavaScript ecosystem (dependency management, build tools, importing external libraries, ..) - Had a lot of bullshit with JS interops (Both with finding good interops for JS libraries, as with creating interops myself) - Google Dart: + Very nice language (very close to Java and C#) + AngularDart is fun to work with + Very consistent eco-system + Really well documented + Good support from Google and community members on Gitter chat + The most common API's you'll need are either included in the SDK, or written and maintained by Google themselves. - Third-party libraries are not always that well documented - The community is not (yet?) as big as the TS or JS community, so obviously it's a little bit harder to find code examples etc Conclusion: - React is awesome, but being dependent on TypeScript (or ES6), you'll spend lots and lots of time on managing your dependencies when your project grows even the slightest bit - Google Dart is awesome, but AngularDart, although it's a lovely piece of software, is still no React. But for now I choose AngularDart. Perhaps in the future I'll choose for React+TS again. But I'll continue hoping for a real ReactDart. :)
deleted 9y ago
[deleted]
carsongross 9y ago
If you wish to stay with the thick client model, Vue.js appears to be the simplest alternative. If you are willing to consider returning to the original RESTful architecture of the web, intercooler.js will dramatically simplify your application: https://github.com/LeadDyno/intercooler-js https://github.com/LeadDyno/intercooler-js
Bubb_A 9y ago
For a more functional/reactive approach, there is CycleJS (https://cycle.js.org/ https://cycle.js.org/).
acemarke 9y ago
I'll semi-answer your question by giving you my standard set of advice and resources for learning React. The article "A Study Plan to Cure Javascript Fatigue" ( https://medium.freecodecamp.com/a-study-plan-to-cure-javascript-fatigue-8ad3a54f2eb1 https://medium.freecodecamp.com/a-study-plan-to-cure-javascr... ) is a great place to start. It gives an excellent series of steps for tackling modern Javascript concepts one piece at a time: Javascript, React, ES6, and state management. On that note, definitely don't over-complicate the learning process by trying to learn many different things at once. Some people will say you should use a "boilerplate" to learn React, and they're wrong - boilerplate projects almost always come with too many pieces configured, and are confusing for beginners. Instead, the best advice is to focus on learning React itself first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later. You should start out by reading through the official React docs and tutorial at https://facebook.github.io/react/ https://facebook.github.io/react/, and I'd encourage you to use the official Create-React-App tool ( https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app ) for setting up projects. It creates a project with a solid build setup, with no configuration needed on your part. There's an excellent post called "Simple React Development in 2017" ( https://hackernoon.com/simple-react-development-in-2017-113bd563691f https://hackernoon.com/simple-react-development-in-2017-113b... ) that gives some more specific instructions on the actual steps to follow. Past that, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, and much more. I also published an "Intro to React (and Redux)" presentation at http://blog.isquaredsoftware.com/2017/02/presentation-react-redux-intro/ http://blog.isquaredsoftware.com/2017/02/presentation-react-... , which is a good overview of the basic concepts for both React and Redux. Finally, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at https://www.reactiflux.com https://www.reactiflux.com .
seangrogg 9y ago
React does not require JSX; it is just a sugar over React.createElement. By way of example: <h1 className="title">Hello World</h1> React.createElement('h1', { className: 'title' }, 'Hello World'); A very contrived example but it's pretty simple to see that if you're coming from a background where you previously used a lot of "JavaScript in HTML" and aren't used to "Markup in JavaScript" it makes for a good middle ground. As well, as you can likely infer from the example, when you start dealing with various nested children the pure JavaScript solution can get somewhat unwieldy; though that comes down to taste, mostly. While I empathize with your position (I'm not a big fan of the transpilation trend) I do find React to be much more sane than Angular 1.x was and much more relevant to what I build than jQuery.
borplk 9y ago
As someone else said the platform itself is not sane. However on the scale of things that we have, React is pretty sane. I have never seen someone who spent significant time with React and thought it wasn't sane. There are some people who are stuck with some 2005 MVC jQuery PHP AJAX mindset repeating worn-out lines like "don't mix logic with views". All their alarms go off when they see JSX. I don't for a moment think any of this crap that we have is "elegant". I hate TypeScript/Javascript/React/Redux/Webpack/JSX/Yarn/NPM/Node etc... and I also love them and use them. Those things that I listed in 2017 enable a class of web applications to be created that is simply not practical to build with send-html-from-the-server-and-sprinkle-jquery-event-handlers-on-the-client technologies. At this point it's Javascript vs everything else. I used to build applications with PHP/Laravel/Django/Flask/Sinatra etc... now I don't consider them anymore for web applications (still ok for content sites, not complex applications). The smooth robust magical UI/UX that I can achieve with TypeScript/React is miles ahead of all other options, it's still full of crap, but still miles ahead of other options. Again I re-iterate my main point, which is things have now changed in such a way that the competition has become Javascript/TypeScript vs everyone else. If you are going to build HTML in a string on the server and sprinkle some javascript on top it doesn't make that much difference whether you use PHP or Python.
bwackwat 9y ago
All you need is vanilla JavaScript! Seriously. Email me at john.has.come@gmail.com I will be glad to discuss my approach to completely avoiding these frameworks.
usgroup 9y ago
Try Elm as an alternative: http://elm-lang.org/ http://elm-lang.org/
leftrightupdown 9y ago
i asked myself the same 2 years ago when my team was deciding if we need all of that javascript framework madness. In the end we built whole product based on dartlang (http://www.dartlang.org http://www.dartlang.org) which compiles down to javascript. We used only Dart language and no frameworks and best thing that came out of this is that we don't feel bound by restrictions of some framework but add stuff as we feel like. What we did is email marketing app https://www.listshine.com https://www.listshine.com, something like mailchimp but faster and with less clutter.
buchanaf 9y ago
I don't really know what you are trying to get at. Almost every front-end framework is going to have some type of "proprietary syntax" -- that's basically what a framework is. Even backend templating languages have custom syntax that must be learned. Otherwise, I guess there is jQuery or web components if you are only supporting modern browsers.
joelhooks 9y ago
React is excellent. I've been building UIs for 20 years and it is by far the best development experience I've ever had. Watch out for contrarians and purist wonks. Set aside your preconceptions and bias against new things you don't understand. Embrace reality with an open mind. Fighting it and wishing for an alternate reality is not the path to happiness. I know that much.
citrusx 9y ago
So, one might ask, "Why do we have these frameworks, anyway?" Well, they're attempts to introduce sanity to the discordant relationship between HTML/CSS as a "Read a remotely stored document" system, and the desire to make the web browser into a fat client for every type of network-distributed application. Ever since "Web 2.0" was a thing, we've been trying to fit this round peg of delivering complex apps into the square hole of the web browser. Sometimes, we do a decent job. But, as we try to handle more total stuff, all of the moving parts overwhelm us. With all that in mind, I think that we shouldn't blame "insanity" on the very tools that have been employed to control insanity. If anything, such a viewpoint tells us that maybe the attempts of today aren't the full answer, so there will be more tries tomorrow. I'll leave you with these things: 1) If the only thing you're doing is creating a web page that serves as a thin visual layer over REST- or CRUD-based services, consider going back two generations to Backbone. Seriously. It does a few simple things for you, and lets you handle the rest in any way that you see fit. Those simple things may be the only thing that your app does. I suspect that this would be true for half of Silicon Valley. But, it goes against the constant pursuit of the new and shiny. 2) If your browser does more than just send a few CRUD commands from the user to a server, then maybe it's time to look into what's good about these frameworks, instead of just considering them "insane". Everyone has their own good parts and pain points to be addressed, and all these tools were built with the best of intentions, to solve specific classes of tough problems, which may happen to be yours. Look at the success and failure stories, and see who's happy with their decisions about their tools, and which problems were solved with what framework. 3) For those people telling you "just use vanilla JS", I'll leave you this: Any sufficiently complicated vanilla JS program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Angular or React.
ergo14 9y ago
As few others mentioned here - look into Polymer. I used all three Angular, React and Polymer - and for me it feels very natural way to build applications. Companies like MCDonalds, General Electric, IBM, ING, USA Today (gannet), Electronic Arts, Coca Cola, (and obviously Google) and others adopted it too. The 2.x version is quite nice, especially since it uses ES6 by default.
RUG3Y 9y ago
I've been dabbling with Riot.js and it looks promising. It's very lightweight compared to Angular / React and I was able to get going with it in ~30 minutes.
cguedes 9y ago
For java developers http://www.totalcross.com http://www.totalcross.com is an option.

elviejo 9y ago

Excellent question. Turns out there is: http://elm-lang.org http://elm-lang.org Is a Haskell inspired programming language that makes developing front end a delight. It helps to build Reliable front ends. Watch this conference to get a sense of what Elm does. Making the Backend Team Jelous[1] Plus the Elm architecture makes everything orderly and easy to understand. Quite a change from the mess of react components and Angular rewrites. [1] https://youtu.be/FV0DXNB94NE https://youtu.be/FV0DXNB94NE

martijn_himself 9y ago
This looks great, and thanks for providing the links. Is Elm production ready? Have you used it to build any apps?
- lisardo 9y ago
  I talk about my experience. I deployed Elm to production in several projects for the biggest group fitness company in the US. It's incredible. Compiler errors are incredible. No undefined bullshit. It's purely functional, so the code you need to understand at the same time is always gonna be inside 20 lines. And you can use it with javascript if you want too. You will learn a lot using a pure functional programming language. Programming is about transforming data, so even if I go back to any OO language I learned that state can cause several problems.
  - martijn_himself 9y ago
    That sounds great. Did you have to convince anyone to adopt Elm or were you free to pick your language of choice? Using a pure functional language appeals to me as well.
- lsjroberts 9y ago
  NoRedInk use it in production and are quite big advocates (having hired the BDFL) - http://tech.noredink.com/ http://tech.noredink.com/
citrusx 9y ago
Obligatory counterpoint: http://reasonablypolymorphic.com/blog/elm-is-wrong http://reasonablypolymorphic.com/blog/elm-is-wrong

elviejo 9y ago

fiiv 9y ago

Both TypeScript and JSX are optional, you don't have to use either with them. There is a ton of different choices out there to choose from if React and Angular are not your thing. One example: Ember.js recently moved their rendering into a standalone library called Glimmer (https://glimmerjs.com https://glimmerjs.com), which is a bit React-like in its approach but nonetheless different. They advocate Typescript as well but don't require it. Elm seems like a thing people like as well, check it out here: http://elm-lang.org http://elm-lang.org - but it's a js compiler so it's also what you might classify as a "proprietary" tech. If you haven't already, check out http://todomvc.com http://todomvc.com - it's the same sample todo app built in a buttload of frameworks so you can compare which one you like.

martijn_himself 9y ago
It is interesting you are the second person replying in this thread to point to Elm. I must check it out! I suppose both TypeScript and JSX are optional but they are symptomatic in a way in that their existence suggests the alternatives are sub-optimal (i.e. a combination plain JavaScript or a clear demarcation of markup and styling).
- ooqr 9y ago
  Elm is neat but definitely goes against the very properties you're looking for. But if you want to take a peek down that road: http://mutanatum.com/posts/2017-01-12-Browser-FP-Head-to-Head.html http://mutanatum.com/posts/2017-01-12-Browser-FP-Head-to-Hea...

daleholborow 9y ago

http://aurelia.io/ http://aurelia.io/ I am a backend guy with some experience in Angular 1.5, Backbone etc, but currently dabbling in the front end again, and Aurelia looks pretty cool. It seems like the least "learn our custom syntax and voodoo" option, so I'm going to give it a spin.

Marazan 9y ago

React is, in many ways, a take on Flex's excellent MXML updated for a JS world that understands that 2-way data binding is the devil. It is very sane.

taude 9y ago
I agree, I feel React, much like Flex's MXML forces the developers to componetize the entire UI as part of the development process in a way that feels natural.

roro5678 9y ago

https://vuejs.org/ https://vuejs.org/ is my favorite alternative

subsidd 9y ago

If you haven't yet you must look into Vuejs as well - https://vuejs.org/ https://vuejs.org/

idkfa 9y ago
and Quasar too - http://quasar-framework.org/ http://quasar-framework.org/

skl_ 9y ago

https://mithril.js.org/ https://mithril.js.org/

rlp 9y ago

I think React is actually quite sane to use now. However, if you're looking for the future, you may want to check out Web Components and Polymer: https://www.polymer-project.org https://www.polymer-project.org

coldtea 9y ago
Correction: if you're looking for what was once touted as the future, but never came to be and probably never will, and has been surpassed by React (and/or Angular), check Web Components and Polymer. It's a committee driven over-engineered spec that's not going to be any more succesful than XHTML...
- ergo14 9y ago
  Yeah, sure that is the reason lots of big enterprises adopted it for their front facing products :-)

coldtea 9y ago

>Slightly tongue-in-cheek but nonetheless serious question. I've recently started looking into JavaScript UI frameworks and have the uneasy feeling they are actually worse than the now defunct Flash and Silverlight. Angular, at least up to 2.0 which I've checked, it's a conceptual mess. React, on the other hand, is conceptually better than Flash and Silveright, and even has more powerful abstractions in several areas. The problem is that React handles a small part of the logic that Flash and Silverlight do (or, something like Flex would), and does so at various levels of the whole stack (some low level like diff-ing repaints, others at higher level like component nesting), and all the wiring and extra handling is left to the programmer to handle. For all the progress with React and co, it's still the wild west as far as programming efficiency is concerned. Elm is not much better either.

leke 9y ago

VueJS is kinda got parts of both, but is entry level friendly. I'm probably not the best to give this advice though.

robinhouston 9y ago

Svelte is pretty elegant: https://svelte.technology/ https://svelte.technology/

taude 9y ago

Server-side rendering with partial views? You're never going to get something as simple as Flash, with a write-once works everywhere. But your user's aren't going to be annoyed at the crappy UX that Flash (or Flex) applications brought us. EDIT: I'm dead serious about this, with the concept of isomorphic apps, I'm not convinced building thick Javascript-based clients is necessarily the way to go for a lot of use cases, including the traditional business information worker-type of application. With these modern JS frameworks working on the concept of rendering virtual DOM diffs, why not just render the partial diff on the server and swap out the specific DOM on the client page?

ooqr 9y ago
The application I've inherited and support is a Rails app that does this. I hate this pattern. It's very difficult to change things and burdens the backend developer with the responsibility.
- fanpuns 9y ago
  I'm pretty new to Rails, but I'm implementing something very similar to this. Is there's any open source mature Rails app that might demonstrate what your seeing/maintaining? I'd be curious to see how this pattern looks as it grows.

PaulHoule 9y ago

Definitely worse than Silverlight!

Clownshoesms 9y ago

This whole JavaScript "revolution" seems surreal to me. I still can't believe they snuck JavaScript onto the backend. Edit: Angry is a better word.

nebabyte 9y ago
'Angry' will be me once they start publishing metrics on how optimized JS (or what, webASM or something?) beats out native. Oh, I'm sure it's being done already. At this point I'm just back in my comfort zone. Let them battle it out for a few more years, I can probably make my peace with whatever's left over or stay in my niche.
- martijn_himself 9y ago
  Out of curiosity, what is your niche?
marcins 9y ago
Server-side JS has existed as long as JS itself. Netscape had something called LiveWire as part of their Enterprise Server in 1995.

ZenPsycho 9y ago

No, none of this platform is sane. It's not designed, it's evolved. Embrace the madness or fail. The web is not desktop applications. The network is always there, the network is slow, the network is asynchronous. The network can fail. You cannot abstract over this with a clever library. Unless you don't care about pushing out 4mb of javascript before first render, you can't ignore it. The front-end is not a server based application. It's relatively straightforward to just echo out some html from a server. This works pretty well, and conceptually it's easy. But the UI has events. Events are asynchronous. You cannot abstract over this. It cannot be ignored. Unless all you need is the off the shelf components and no custom interactions, animations or logic. Every UI framework for the front end is aimed at solving a specific problem, a specific complexity. Before adopting ANY of them, you have to seriously ask yourself if you actually have that problem before just jumping on the bandwagon- in most cases, in my experience, you probably don't. But by adopting some "framework" you've just added a problem. you've added a complexity. If you had the problem, it might be worth it. You might have netted less complexity. But probably not. Browsers have come a long way in 10 years, if you haven't been paying attention. Most of the cross browser problems have disappeared unless you're using new things like web sockets, web rtc or indexedDB, or something crazy like that. The browser is already a UI framework with all the basic widgets, text layout, image manipulation, audio processing, etc. etc. From a perspective of a user of your website or service, ask yourself what value something like react is really adding.

martijn_himself 9y ago
This is one the most insightful responses, so much of this rings true to me. It's relatively straightforward to just echo out some html from a server. This works pretty well, and conceptually it's easy. I remember reading an article recently (I can't find it) that argued that the human readable part of the web should have been just this, a place for static pages to render and be read. The reason it works so well is because that was what it was designed and build for. So it has basically just completely escalated by its attempt to replace native applications. Except it is and always will be worse at everything a native application does. You have to seriously ask yourself if you actually have that problem before just jumping on the bandwagon. I suppose that is sort of complicated by the fact that every framework out there tries to sell itself as the best thing since sliced bread, except advertising what is for. Browsers have come a long way in 10 years, if you haven't been paying attention. It is absolutely amazing what has been achieved.

CosmicShadow 9y ago

ASP.NET MVC for the back end is beautiful, clean, simple, and then you can use a bit of jQuery on the front or use Knockout JS if you want to do data-binding with MVVM and not have to learn with or deal with all the other crap of those frameworks mentioned as that is what MVC already does for you. Don't reinvent a browser in the browser or waste more time on JS than you need to, you'll feel so clean separating things.

stephenr 9y ago
I think this could be simplified a little, and still remain true: > 'Boring' language OOP/MVC for the back end is beautiful, clean, simple, and then you can use a bit of jQuery on the front This bit should be considered golden advice IMO: > Don't reinvent a browser in the browser or waste more time on JS than you need to,
n0rm_ 9y ago
Please don't. I already have a really hard time communicating reason to m$ people. They get these ridiculous ideas from the likes of you, and waste countless hours beating a dead horse. There will be no servers to configure in the future. We will be spinning up containers in a swarm, and communicating with those services via de-centralized lambda function pools. Bulk of future devs will spring up in frontend. m$ lost its monopoly in backend to AWS and the likes. Do you think they started OSS because they are nice? They are desperate and throwing money at the problem. > jQuery on the front or use Knockout JS if you want to do data-binding with MVVM I'll say the same thing to someone who tried to make a case for PHP; you are doing a disservice to the clueless reader (likely a new grad). Kids, listen to me; don't ever say that in a job interview. You'll be politely rejected, and never hear from them again. If you started to use jQuery after 2016, just keep that to yourself. It shouldn't matter that much, but it does. It signals you are comfortable with being mediocre. > waste more time on JS than you need to Again; just don't. Just because your past 10 years of acting "1337 programmer" through drag-n-drop some VC (nuget?) modules vanished doesn't mean future programmers need to go through that soul crushing m$ travesty. What is the UNIX philosophy? What is m$ (still) trying to do? Do you think those guys don't know how to pick successful ventures? Think. You are up against a company here, not a friendly group of developers. Not that you can really resist the change, mind you. I'm not asking you to stop peddling your inferior wares because I'm afraid you might stop progress. I'm suggesting it because you will be left holding the bag when m$ finally starts chopping bits off the MSDN network, and Oracle silently discontinues Java after v9. Try to advance, not defend your crumbling castle. p.s. Had to create a new account just to reply to this. Hadn't logged in in a couple years.

unherd 9y ago

vue.js ... absolutely amazing.

dz0ny 9y ago

Vue.js is saner because it does not have that JSX nonsense and you can still write most of the code however you like, and later upgrade to babel,typescript etc. Particularly I like component structure https://vuejs.org/v2/guide/single-file-components.html https://vuejs.org/v2/guide/single-file-components.html which kinda does the same in more traditional approach.

Traubenfuchs 9y ago
It also works well in non npm/node.js environments.
heidar 9y ago
The main reason I didn't consider Vue was because I like coupling HTML and JS like React does. But this seems like a much nicer way of doing it than JSX. I'll have to give Vue another chance.
- masklinn 9y ago
  > But this seems like a much nicer way of doing it than JSX. Note that there is no requirement to use JSX, JSX is just syntactic sugar for the underlying function calls which you can use directly: https://facebook.github.io/react/docs/react-without-jsx.html https://facebook.github.io/react/docs/react-without-jsx.html That's useful when you don't want to add a local compilation file when developing/debugging.
  - jazoom 9y ago
    And Vue can use JSX.
  - dlwdlw 9y ago
    This argument doesn't make sense because doing it like that is even worse that JSX.
jonheller 9y ago
Hear hear. I used Angular for about a year and tried to use React for about six months. Then I tried Vue and I couldn't not believe just how much more sense everything made. Give it a shot.

mb720 9y ago

You can use Scala.js[1] to transpile your Scala code to JavaScript and have type safety between client and server. You don't need to use any frameworks if you use Scala's features on the client well. [1] https://www.scala-js.org/ https://www.scala-js.org/

cies 9y ago

Let me take your question apart a little... > Angular and React seem to be a mish-mash of proprietary syntax and technologies (AtScript, JSX, TypeScript etc.) that paper over some of the cracks in JavaScript and CSS. They are not "proprietary", but such they are partly an attempt to overcome "some of the cracks in JavaScript and CSS". > Are these transitory technologies that will be replaced by something better in the near future? I do not think so. > Is there a better alternative available today? As you mentioned JS (and to a lesser extend CSS) is the problem. A problem that Angular and React do not fix. People in this thread will mention Vue and Svelte as alternatives to Angular and React, but these also do not fix the underlying problem: JS. TypeScript and Flow fix some of JS's problems. But a real next level approach that is available today is given by real compile-to-JS languages: Elm, PureScript and ReasonML. It deserves to be mentioned these are all primarily "functional" languages. And not for no reason, FP is kind of the best option we have to avoid the OO/imperative-dramas we become tired of. And Reason is particularly interesting as it can also compile to native (PureScript as well but not very mature in that regard), it is backed by Facebook (25% of messenger.com is ported to ReasonML already) and thus has well supported React bindings (allowing interop with the React ecosystem).

a-saleh 9y ago
I have been playing around with PureScript (more for the fun of learning interesting FP concepts than creating anything useful) and really liked the Purescript Book [0]. Is there something similiar for Reason as well? [0] https://leanpub.com/purescript/read https://leanpub.com/purescript/read
- cies 9y ago
  Not really. This you've probably seen (the home page): https://facebook.github.io/reason/ https://facebook.github.io/reason/ This is also quite nice (see the example app section at the bottom): https://github.com/vramana/awesome-reasonml https://github.com/vramana/awesome-reasonml Also these talks are interesting (but nothing close to the format of the book you mentioned): https://www.youtube.com/watch?v=_0T5OSSzxms https://www.youtube.com/watch?v=_0T5OSSzxms https://www.youtube.com/watch?v=8LCmLQ1-YqQ https://www.youtube.com/watch?v=8LCmLQ1-YqQ (really bad audio, sorry)

loftsy 9y ago

Dart is a sane language with great tooling. It has its own version of Angular which works great. It is available today!

awjr 9y ago

I cannot fault the communities around React and Angular and the support that they give to each ecosystem. I would say that the React community seems to be 'stronger' these days. I note some people are mentioning other JavasScript frameworks (e.g. http://aurelia.io/ http://aurelia.io/ https://vuejs.org/ https://vuejs.org/ https://mithril.js.org/ https://mithril.js.org/ https://choo.io/ https://choo.io/ https://svelte.technology/ https://svelte.technology/ ) They ALL have their merits, but it all comes down to the development community around them, and for me, the jobs out there. Recently somebody asked in our local JS group what framework to learn and everyone responded with React. The jobs are there, the dev community is strong, and more importantly the learning curve is good, particularly with the hand holding create-react-app now does. Yes, down the line, you will have to learn react-router and maybe redux/mobx, but all in good time.

pcardoso 9y ago

http://intercoolerjs.org http://intercoolerjs.org I'm a big fan of Intercooler.

jonmann 9y ago

Polymer 2.0 is much closer to just writing vanilla HTML, CSS, and JS

jonmann 9y ago

Polymer 2.0 is much closer to just writing vanilla HTML, CSS, and JS

nottorp 9y ago

Speaking of sanity, I've heard that somewhere under these hundreds of layers of libraries that you're supposed to mindlessly install there is a "native" javascript API inside the browser. Is there any comprehensive documentation resource online or offline that teaches you how to use that in a modern browser?

mcintyre1994 9y ago
MDN is great: https://developer.mozilla.org/en-US/docs/Web/JavaScript https://developer.mozilla.org/en-US/docs/Web/JavaScript If you're more of a "show me 30 cool things I can do with none of that baggage" person, I found javascript30.com really fun.

obsurveyor 9y ago

Ractive[1] is pretty good imho. Development runs hot and cold but I've found it a joy to work with. Documentation could be a bit better, especially when it comes to components. [1] http://ractivejs.org http://ractivejs.org

kozak 9y ago

You can also use just the JSX without React (using https://www.npmjs.com/package/nativejsx https://www.npmjs.com/package/nativejsx or similar) to combine parts your own way.

kirankn 9y ago

Elm

levosmetalo 9y ago

Since I discovered Clojurescript using reagent, re-frame and figwheel it is hard to go back to any JS framework, or JS itself. The feedback cycle is so short that it feels like doing Smalltalk properly. Now I wish I could use similar combo for mobile and desktop development.

bschwindHN 9y ago
> Now I wish I could use similar combo for mobile and desktop development. Check out "re-natal". That at least gets you mobile, and perhaps desktop once react native has a good desktop story.

dotdotcommadot 9y ago

Being both a TypeScript and Google Dart developer for a few years now (and a former Flash/Flex developer, and still missing lots of aspects of it), I can say: - On browsers: it is what it is. Neither React nor Angular will fix this for you. You're going to have to work with all existing browsers and their issues (which are quite a lot, especially when you want to go little 'deeper down'). - On styling CSS: Either use a framework like Bootstrap or Material Design Lite, or try to use a pre-processor like SASS. LESS and Stylus, also 2 pre-processors, are losing a bit on popularity, or so it seems. SASS is a good 'safe bet'. There's lots of documentation and fairly decent frameworks were made around it. - React and Angular are both really good, have amazing documentation and tutorials. But for me personally, React translates really well my experience from Flash/Flex. Angular is also a very nice framework of course, but it feels to me like it is still more something I would use to make webSITES in, instead of webAPPS (although I'm building a huge app in it right now), since it is not as 'fast' and 'snappy' to create components and an architecture as it is with React. (I'm talking development wise, not performance) - On dependencies: I really dislike the entire dependency hell I always end up in when starting a JavaScript project. Since both JavaScript and TypeScript use NPM (at least, that's the current de-facto standard), TypeScript does not solve this for you. For instance: how do you manage your dependencies? NPM, Nuget or Yarn? What's the difference, and do you have a day to look it all up? How are you building your project and your .sass files? Gulp, Grunt, Webpack, NPM scripts, or just vanilla commandline? If you're creating a new class, how are you going import it in your consumer class? Declare all external JS files in your index.html? Or maybe you prefer CommonJS, RequireJS, UMD, SystemJS or ES2015(=ES6) native modules? And what if one dependency uses another system than you do? - On languages: TYPESCRIPT: it's a very nice and powerful language, but like I said, it hooks into the standard JavaScript ecosystem. On top of the dependency hell, you'll have to use a lot of JS interops (to be able to use existing JS libraries), which aren't always that well maintained. ES6: You could use the ES6 version of JavaScript. You'll need Babel to transpile to ES5 JavaScript, so your code will run in all browsers. No problems with JS interops here, but dependency hell and ecosystem problems will stay. GOOGLE DART: Also an amazing language, written by Google. You can discuss on what's the better language (TypeScript or Dart), but the advantage here is the ecosystem. You build with Pub, you manage your dependencies with Pub, and there's only one way of importing external classes. A lot of modern API's you'll need, like Futures (kind of like Promises), and Streams (like Observables) are built in the language itself, meaning they are maintained and tested by Google. I've been using AngularDart (a Dart-based Angular) for over 6 months now, and it's going really well. So for me, this results in: - JavaScript ES6: + Simple and fun language + Close to old-skool JavaScript - Too limited in OOP features - Inconsistent and way too fast changing JavaScript ecosystem (dependency management, build tools, importing external libraries, ..) - TypeScript: + Very nice language + Projects like Angular and React are written in it, so it's easy to find tutorials in TypeScript + Popular, and well documented - Inconsistent and way too fast changing JavaScript ecosystem (dependency management, build tools, importing external libraries, ..) - Had a lot of bullshit with JS interops (Both with finding good interops for JS libraries, as with creating interops myself) - Google Dart: + Very nice language (very close to Java and C#) + AngularDart is fun to work with + Very consistent eco-system + Really well documented + Good support from Google and community members on Gitter chat + The most common API's you'll need are either included in the SDK, or written and maintained by Google themselves. - Third-party libraries are not always that well documented - The community is not (yet?) as big as the TS or JS community, so obviously it's a little bit harder to find code examples etc Conclusion: - React is awesome, but being dependent on TypeScript (or ES6), you'll spend lots and lots of time on managing your dependencies when your project grows even the slightest bit - Google Dart is awesome, but AngularDart, although it's a lovely piece of software, is still no React. But for now I choose AngularDart. Perhaps in the future I'll choose for React+TS again. But I'll continue hoping for a real ReactDart. :)

deleted 9y ago

[deleted]

carsongross 9y ago

If you wish to stay with the thick client model, Vue.js appears to be the simplest alternative. If you are willing to consider returning to the original RESTful architecture of the web, intercooler.js will dramatically simplify your application: https://github.com/LeadDyno/intercooler-js https://github.com/LeadDyno/intercooler-js

Bubb_A 9y ago

For a more functional/reactive approach, there is CycleJS (https://cycle.js.org/ https://cycle.js.org/).

acemarke 9y ago

I'll semi-answer your question by giving you my standard set of advice and resources for learning React. The article "A Study Plan to Cure Javascript Fatigue" ( https://medium.freecodecamp.com/a-study-plan-to-cure-javascript-fatigue-8ad3a54f2eb1 https://medium.freecodecamp.com/a-study-plan-to-cure-javascr... ) is a great place to start. It gives an excellent series of steps for tackling modern Javascript concepts one piece at a time: Javascript, React, ES6, and state management. On that note, definitely don't over-complicate the learning process by trying to learn many different things at once. Some people will say you should use a "boilerplate" to learn React, and they're wrong - boilerplate projects almost always come with too many pieces configured, and are confusing for beginners. Instead, the best advice is to focus on learning React itself first. Once you have a good understanding of how React works, you will better appreciate why a state management library like Redux can be useful, and you can learn about other tools later. You should start out by reading through the official React docs and tutorial at https://facebook.github.io/react/ https://facebook.github.io/react/, and I'd encourage you to use the official Create-React-App tool ( https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app ) for setting up projects. It creates a project with a solid build setup, with no configuration needed on your part. There's an excellent post called "Simple React Development in 2017" ( https://hackernoon.com/simple-react-development-in-2017-113bd563691f https://hackernoon.com/simple-react-development-in-2017-113b... ) that gives some more specific instructions on the actual steps to follow. Past that, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, and much more. I also published an "Intro to React (and Redux)" presentation at http://blog.isquaredsoftware.com/2017/02/presentation-react-redux-intro/ http://blog.isquaredsoftware.com/2017/02/presentation-react-... , which is a good overview of the basic concepts for both React and Redux. Finally, the Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at https://www.reactiflux.com https://www.reactiflux.com .

seangrogg 9y ago

React does not require JSX; it is just a sugar over React.createElement. By way of example: <h1 className="title">Hello World</h1> React.createElement('h1', { className: 'title' }, 'Hello World'); A very contrived example but it's pretty simple to see that if you're coming from a background where you previously used a lot of "JavaScript in HTML" and aren't used to "Markup in JavaScript" it makes for a good middle ground. As well, as you can likely infer from the example, when you start dealing with various nested children the pure JavaScript solution can get somewhat unwieldy; though that comes down to taste, mostly. While I empathize with your position (I'm not a big fan of the transpilation trend) I do find React to be much more sane than Angular 1.x was and much more relevant to what I build than jQuery.

borplk 9y ago

As someone else said the platform itself is not sane. However on the scale of things that we have, React is pretty sane. I have never seen someone who spent significant time with React and thought it wasn't sane. There are some people who are stuck with some 2005 MVC jQuery PHP AJAX mindset repeating worn-out lines like "don't mix logic with views". All their alarms go off when they see JSX. I don't for a moment think any of this crap that we have is "elegant". I hate TypeScript/Javascript/React/Redux/Webpack/JSX/Yarn/NPM/Node etc... and I also love them and use them. Those things that I listed in 2017 enable a class of web applications to be created that is simply not practical to build with send-html-from-the-server-and-sprinkle-jquery-event-handlers-on-the-client technologies. At this point it's Javascript vs everything else. I used to build applications with PHP/Laravel/Django/Flask/Sinatra etc... now I don't consider them anymore for web applications (still ok for content sites, not complex applications). The smooth robust magical UI/UX that I can achieve with TypeScript/React is miles ahead of all other options, it's still full of crap, but still miles ahead of other options. Again I re-iterate my main point, which is things have now changed in such a way that the competition has become Javascript/TypeScript vs everyone else. If you are going to build HTML in a string on the server and sprinkle some javascript on top it doesn't make that much difference whether you use PHP or Python.

bwackwat 9y ago

All you need is vanilla JavaScript! Seriously. Email me at john.has.come@gmail.com I will be glad to discuss my approach to completely avoiding these frameworks.

usgroup 9y ago

Try Elm as an alternative: http://elm-lang.org/ http://elm-lang.org/

leftrightupdown 9y ago

i asked myself the same 2 years ago when my team was deciding if we need all of that javascript framework madness. In the end we built whole product based on dartlang (http://www.dartlang.org http://www.dartlang.org) which compiles down to javascript. We used only Dart language and no frameworks and best thing that came out of this is that we don't feel bound by restrictions of some framework but add stuff as we feel like. What we did is email marketing app https://www.listshine.com https://www.listshine.com, something like mailchimp but faster and with less clutter.

buchanaf 9y ago

I don't really know what you are trying to get at. Almost every front-end framework is going to have some type of "proprietary syntax" -- that's basically what a framework is. Even backend templating languages have custom syntax that must be learned. Otherwise, I guess there is jQuery or web components if you are only supporting modern browsers.

joelhooks 9y ago

React is excellent. I've been building UIs for 20 years and it is by far the best development experience I've ever had. Watch out for contrarians and purist wonks. Set aside your preconceptions and bias against new things you don't understand. Embrace reality with an open mind. Fighting it and wishing for an alternate reality is not the path to happiness. I know that much.

citrusx 9y ago

So, one might ask, "Why do we have these frameworks, anyway?" Well, they're attempts to introduce sanity to the discordant relationship between HTML/CSS as a "Read a remotely stored document" system, and the desire to make the web browser into a fat client for every type of network-distributed application. Ever since "Web 2.0" was a thing, we've been trying to fit this round peg of delivering complex apps into the square hole of the web browser. Sometimes, we do a decent job. But, as we try to handle more total stuff, all of the moving parts overwhelm us. With all that in mind, I think that we shouldn't blame "insanity" on the very tools that have been employed to control insanity. If anything, such a viewpoint tells us that maybe the attempts of today aren't the full answer, so there will be more tries tomorrow. I'll leave you with these things: 1) If the only thing you're doing is creating a web page that serves as a thin visual layer over REST- or CRUD-based services, consider going back two generations to Backbone. Seriously. It does a few simple things for you, and lets you handle the rest in any way that you see fit. Those simple things may be the only thing that your app does. I suspect that this would be true for half of Silicon Valley. But, it goes against the constant pursuit of the new and shiny. 2) If your browser does more than just send a few CRUD commands from the user to a server, then maybe it's time to look into what's good about these frameworks, instead of just considering them "insane". Everyone has their own good parts and pain points to be addressed, and all these tools were built with the best of intentions, to solve specific classes of tough problems, which may happen to be yours. Look at the success and failure stories, and see who's happy with their decisions about their tools, and which problems were solved with what framework. 3) For those people telling you "just use vanilla JS", I'll leave you this: Any sufficiently complicated vanilla JS program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Angular or React.

ergo14 9y ago

As few others mentioned here - look into Polymer. I used all three Angular, React and Polymer - and for me it feels very natural way to build applications. Companies like MCDonalds, General Electric, IBM, ING, USA Today (gannet), Electronic Arts, Coca Cola, (and obviously Google) and others adopted it too. The 2.x version is quite nice, especially since it uses ES6 by default.

RUG3Y 9y ago

I've been dabbling with Riot.js and it looks promising. It's very lightweight compared to Angular / React and I was able to get going with it in ~30 minutes.

cguedes 9y ago

For java developers http://www.totalcross.com http://www.totalcross.com is an option.