> I would kill to be able to do React in F# or OCaml.
Websharper (http://websharper.com/) for F# is now Apache-licensed and comes with the UI.Next framework that provides a really nice reactive paradigm for creating web UIs. Unfortunately it doesn't help with mobile apps as React Native does but is still pretty good.
I talked about native mobile applications as well.
> Also, your glorious React didn't exist three years ago. Why should I expect it to be still developed three years from now? It doesn't sound like a very transferrable skill.
Facebook is dogfooding React in a way not seen in other libraries in use on the web. Sure, Google uses Angular here and there, but nowhere near to the extent that Facebook uses React -- both on the web and native mobile.
> Why not learn functional programming language for functional programming?
That's not really the point I was trying to make. JavaScript is already widely adopted on millions of devices. I can deploy functional JavaScript anywhere.
> And one has to go way, way out of his way to use this paradigm for real in JavaScript.
I mentioned libraries that encourage this paradigm. Including lodash-fp which makes a point of making everything in lodash auto-curried, iteratee-first, and data-last.
> Has anyone ever seen a real React application which does not use JSX?
I've built one without using JSX and I think it's superior. The problem is the tooling and type support just isn't there so going against the grain here is pretty much asking to be burnt.
> react does not play well with non-react javascript
I'm work on a somewhat older project (circa 2015) that started without react, and have also found that to be the case.
End-all-be-all web frameworks seem to be the rage now, but I'd prefer to see a solid library of micro-frameworks that can be stitched together (like jquery plugins, but better).
Also, the idea of a web server transferring over a huge javascript library and app just to load a single page seems wrong. There has to be a better way, a better amalgamation between server and client.
> Asking sincerely because this take is surprising to me: which specs are you referring to?
I'd like to see the Web Components spec revisited: it has a) no API for passing non-string attributes to other web components, b) no API for declaratively updating your DOM subtree - you either do manual surgical DOM changes, or blow away your (potentially stateful) children and recreate them.
Without these, the raw web components API isn't suitable as an alternative to React et al. You've got to build a whole framework around them (like Lit), and at that point you're just using another framework.
> But I do note that your examples are from quite a narrow sector. TypeScript, Go and React are all languages. TypeScript is a nice facade over JavaScript, and React is ... well, a very powerful DSL.[ß]
> ß: Our frontend team will probably want to roast me for that one, but there isn't much visible JS left in modern React code. Not for my eyes, at least.
Can you clarify what you're talking about here with regards to React? I can see calling JSX a DSL, but React is a language now? And there's no JS / TypeScript in your React code base?
I very much doubt. Actually reactive frameworks such as react and languages that transpile in other languages such as trypescript are the reason they couldn't. These overcomplicated, seemingly well architected, tools are in fact just a fractal of poor design.
React is good for certain classes of UI, granted. I use another FRP-style library (not React) to render UI in my current game, and it works well -- except that it doesn't mesh well with me trying to control it from an OO game, but I've created an interface that works.
But imagine creating Adobe Photoshop, Maya, or Microsoft Word entirely in React, and tell me again that FP would be the ideal choice.
For any particular dialog that pops up? Absolutely.
For the entire app? You'd end up with a "god object" that would make the app unmaintainable. OO gives you compartmentalization that you don't get with FP.
FP is great for problems up to a certain complexity. After that it falls apart. Thing is, 98% of apps don't come close to that level of complexity, so there are lots of people who never even work on an app that won't work well with FP.
In the RectIterable example you gave, I'm afraid I don't know enough Haskell to comment on it intelligently.
Is "instance" adding an interface to TileMap/HexMap so that either can be passed in as a parameter that requires a RectIterable? Can other interfaces be added that way to TileMap/HexMap?
In my editor, can I say something like myTileMap.iterateRect after doing this, or do I need to know that iterateRect exists and remember exactly what it's called?
The last point is salient: Discoverability is a huge part of the UI of a programming language, and memorizing all of the exact function names that are appropriate for a data structure is not fun.
> So while you do need to learn a few React specific APIs, most of your code is just JavaScript. That's transferrable knowledge!
Well that gets a big LOL from me. React goes out of its way to eliminate any awareness or interaction with real DOM APIs, and tends to abstract away all kinds of things that are actually straightforward using native JS APIs. Heck, we're only _just now_ perhaps-maybe-hopefully getting true support for web components and they've been around for years.
If you want to use a reactive view library that actually helps you learn about vanilla APIs, try Lit. Or drop down a level and check out Stimulus.
> The approach of using a compiler instead of a framework makes a lot of sense
I agree, I wish it wasn't an entire framework though and more of a front-end library like react. I've learnt long ago not to invest too much into a single tool.
> And why the hell you have to write code in JS that will be ultimately represented as HTML?
I only use React for React-Native, so my JSX gets turned into native objects.
Have you ever written a non-web program though? The default mode for almost all native GUI kits is for developers to define the UI in code.
I've never, ever seen a UI designer or a high level DSL (like HTML) that works better than code for non-trivial programs. With JSX, HTML has finally caught up to the rest of the GUI programming world.
> What would you recommend to someone averse to js
I guess it depends on what your concerns are:
• If you're worried about too many libraries to pick from, I'd just go with the most popular ones. React is a pretty solid choice.
• If you're worried about config being a pain, I'd recommend going with one of the starter tools like Create React App. Build tools are indeed a bit complex, but hopefully that's getting better over time.
• If you're scared by lack of type safety or worried about language quirks, I'd recommend TypeScript. (Flow is also quite good.)
In particular, TypeScript (and Flow) provides much more flexible static typing than I've used in any other mainstream language. You get the nice navigation, autocomplete, and static checking that you'd expect from a typed language, and I've found that I spend much less time needing to think about how to write my code in a way that appeases the type system.
> Till this day, no one has given me a straight answer on why they choose react beyond the dubious claims of performance++. Or even why build a web app to begin with. Nor have the users been asked if they want native-like apps on the browser.
The main reason is cross platform compatibility for things that don't need to make system calls. Ultimately I would prefer to distribute statically linked Go binaries that are command line applications, but if I was asked all "UI" would be a REST API with a manual. The market finds web applications are successful and lower the barrier of entry, and so they're made.
> I complain but I use react everyday on a web app Im sure no one cares if it loads 400ms faster than a server rendered jinja template.
With NextJS and server side rendering + static optimization I find that time to first (contentful) paint is the same or faster than Jinja without me having to configure a thing.
> Now we have massive overhead, npm libraries for everything and only god knows whats going on in the node modules folder
npm/yarn provides a pretty good developer experience but the way it accomplishes that is a touch horrifying, I agree. Babel and Webpack I find bring it most of the bloat, which is probably a good thing as you're not shipping those dependencies in production bundles. It definitely chews up storage space on the local machine though.
> keeping up with the joneses by using Typescript - why use typescript when Java or C# do static typing so well? I can't ask silly plebian questions like that.
Just to get out in front of it - I do not like Typescript. I find Typescript to be a waste of time. JS's type system is broken as hell, but in just the right way for web development. It makes it flexible and easy to write. With Typescript I feel like I spend most of my time making the compiler happy instead of generating any value for the business or myself.
> Is the point of Web Components to service frameworks? I really don't see who the intended audience is, because any half decent framework is infinitely simpler to work with.
Originally Web Components were a response to web developers waiting for years to HTML elements like date pickers and such to be added to the standard. With web components, it will be possible to create such elements once and integrate them with every front-end project just like you'd use e.g. a <select>.
Using them as a framework for building web applications has mostly been propagated by e.g. Polymer, but as I and many others who have tried it can attest: that doesn't work too well.
Still, for components I think Web Components will be a great addition, and should combine nicely with React.
Websharper (http://websharper.com/) for F# is now Apache-licensed and comes with the UI.Next framework that provides a really nice reactive paradigm for creating web UIs. Unfortunately it doesn't help with mobile apps as React Native does but is still pretty good.
reply