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?
84 comments
[ 4.4 ms ] story [ 143 ms ] threadIs 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
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.
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
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), 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 - 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 - it's the same sample todo app built in a buttload of frameworks so you can compare which one you like.
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).
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.
It is very sane.
It's a committee driven over-engineered spec that's not going to be any more succesful than XHTML...
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.
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?
Edit: Angry is a better word.
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.
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.
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.
Username checks out. Thanks, ZenPsycho!
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.
> '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,
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.
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
That's useful when you don't want to add a local compilation file when developing/debugging.
It's just simple and enforces "good" practices by making sense of them.
[1] https://www.scala-js.org/
> 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).
[0] https://leanpub.com/purescript/read
This you've probably seen (the home page):
https://facebook.github.io/reason/
This is also quite nice (see the example app section at the bottom):
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=8LCmLQ1-YqQ (really bad audio, sorry)
I note some people are mentioning other JavasScript frameworks (e.g. http://aurelia.io/ https://vuejs.org/ https://mithril.js.org/ https://choo.io/ 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.
I'm a big fan of Intercooler.