111–120 of 190 posts
I'm reminded of the Hacker News post that introduced me to React from David Nolen back in 2013, where he first introduced ClojureScript's take on React, Om: http://swannodette.github.io/2013/12/17/the-future-of-javasc... Interested to take this for a spin.
Throwaway since embarrassed to ask this: What is the knock against Javascript? Not trolling, besides lack of types it seems like a pretty darn solid, ubiquious, elegant/straightforward language to get things done. For people with strong opinions about this, what is so horrifying about Javascript to you?
To write nice JS, you have to be disciplined and very cognizant of what you're doing. And then you have to deal with the rest of the ecosystem, which is massive and of varying quality.
I recently ran into mutable date types in momentJS, which is a frustrating gotcha - it's not flip the table lose your shit annoying, but it's simply a non-existent issue in other languages.
Earlier quoted context omitted.
Typescript, Redux, and Immutable.js work together as a pretty compelling stack, but they involve a fair bit of boilerplate compared to Elm or ReasonML. Elm provides type safety, immutable data structures, and state management in a very compact but readable way. In fact, Redux was strongly inspired by Elm's state management. All of these stacks are perfectly acceptable choices, so it comes down to a matter of personal…
> compared to Elm or ReasonML PureScript deserves a mention in this list as well. More full-featured and general purpose than Elm, cleaner design than ReasonML. Prolly the smallest community of the 3.
I'd advise starting with Elm to fall in love with the development experience and wonderful error messages, and graduating to Purescript when you need more power.
Earlier quoted context omitted.
ReasonML has more potential. Aside from its excellent type system (one of the best), it can also compile to native code. This has several benefits: - Frontend: Your tools are fast. The ReasonML-to-JS compiler is already an order of magnitude faster that TypeScript, etc. Fastpack is a native bundler in the works that aims to bundle your project in under a second (and faster for incremental builds). - Mobile & Desktop:…
This reminds me that all those points would apply to dartlang
Earlier quoted context omitted.
It's not any less convenient than React appears to be. Disclaimer: I've only used it for small Todo project, I'm not a front end guy. Disdisclaimer: I've not used React at all. However, if you need really strong JS interop, consider something like F#'s Fable. F# is gaining a lot of momentum and now that SAFE stack is apparently Microsoft-blessed, I expect it to continue growing even more.
1k upvotes. I check in on Fable and F# semi frequently but SAFE has somehow slipped under my radar. I wonder if the ionide project will get some extra support.. Suave though... Nothing against Suave, but it's not the Phoenix competitor the ecosystem is in dire need of. I was under the impression some newer frameworks like Giraffe were going to fill that void..
?
It's what the S in safe is actually meant to be, not suave. It's very similar, in heart anyways, to phoenix.
The fsharp community is fighting what is essentially an uphill battle. We have ML but we've got to jump through dotnet hoops to get shit done.
One man's cruft is another man's feature.
I doubt ionide will support SAFE, but maybe they will have a sister plugin? Idk how all that works.
Currently using Reason. Here's what they don't tell you: Pros: * Compile speed is mindblowing. As in, a big project compiles within a few seconds, and incremental compiles are instantaneous. The productivity gains of this cannot be overstated; you just don't get those moments anymore when you're waiting for webpack, your mind wanders off, lets just check HN real quick, ... no, you just stay in the flow. It's great. E…
This was my experience as well. Also, while it may theoretically be possible to compile native code with reason, the core focus of reasonml is javascript frontend development at the moment.
> On the native side, since Reason's just a syntax transform: yes, they work with Reason too. But the native workflow is currently work-in-progress and needs polish.
Honest question: why would someone use this instead of React? From my point of view, React solved a real problem. JS before React (at least old-skool, with jQuery & co.) was simply unmaintainable. It was often easier to thow old projects away and start anew than to maintain what inevitably became a tangled mess of callbacks and global variables. Not because of incompetency of developers (at least I hope so ;) but bec…
The last ReactJS project I was working on ended up with libraries such as Ramda , ImmubtableJS , recompose , etc, in order to make the codebase more functional ... We also switched to TypeScript for the type-system. While these libs improved the overall experience, it never came close to what you get from a proper functional language. I'm currently working on a frontend that uses ReasonReact and it feels much smoothe…
Earlier quoted context omitted.
You're not wrong; it's stateless components I'm talking about. I should have been clearer: it'd be okay if `true` were simply the default, but the crux of the issue is that you can't even implement your own `shouldUpdate` as the function doesn't provide the previous props (like it does in React), so you have nothing to compare against – unless you laboriously store them yourself as state.
I'm going to blame any communication breakdown on the fact that I know nothing about ReasonML or React-Reason. However, the point of having to store state so you have something to compare against strikes me as a really odd choice for the React-Reason library to introduce, since it deviates from the functionality of React itself. I was curious enough to glance at the React-Reason doc's and they say that `shouldUpdate`…
The documentation is outdated, and the {oldSelf, newSelf} doesn't exist anymore. You had to use the `withRetainedProps` component for this to work, but that now results in an error message on compilation, telling you to use a reducerComponent instead.
I think it's something they intend to figure out a better solution for, but it's been put on the back-burner and meanwhile we're stuck with a non-solution. (Unless this is all wrong and I've been lied to and there's a better way, in which case, please enlighten me!)
ReasonML has a lot that makes it attractive to people that aren't already entirely invested in the JS/Node ecosystem, but doing the whole dance to make sure Node is installed correctly, and then using npm or yarn to install bucklescript and all the dependencies and make sure paths are correct, etc is a PITA, and a lot to ask of someone that's trying to evaluate whether it's worth incorporating in a new/existing project.
Provide a precompiled download with Node, npm/yarn, etc, and all the modules you need preinstalled, (just set the correct env vars to tell it to use it, such at PATH and some lib path) and you drastically reduce the overhead to not just trying it out, but actually using it.
Earlier quoted context omitted.
Well Reason is really Ocaml, which has a much better type system than Elm (functors, open variants, a class system) , powerful meta programming (the react extension is just syntactic sugar around that) and is now backed by at least three large corporations (Facebook, Bloomberg and JaneStreet). It has a proven track record of handling large sophisticated projects and is not restricted to the web front end niche becaus…
The type system might be more powerful, my point is more that if you can bypass it and integrate directly with JS, then people will, and then much of that value is lost. Elm doesn’t have that problem.
I would also love option to have gradual type friendliness because when prototyping I know my program is wrong in some different part, but I want to test given component in runtime, while I haven't refactored everything yet. I think having option like 'compileWithoutTypecheck' is very good for prototyping.