• 0

Reference: Starting a new list on React.js Web Programming, any help appreciated


Question

I am starting a new list on Web Programming using React.js at:

 

https://github.com/10UWP/The-React-List

 

It will cover React.js OSS tools with a Windows/Neowinian perspective. There will also be an emphasis on Live Page Editing and REPL etc to try and claw back some developer advantage when stuck using web based technologies for some projects. Another focus is to follow core React philosophy to eliminate the evil that is CSS and HTML as much as possible.

 

However, whatever opinions I bring to the table, I do view these lists as "inclusive" and the value of the list is a quick one-stop place to grab whatever anyone needs from a lot of alternatives so if someone suggests a great tool that completely is the opposite, it will get added for sure.

 

Right now, it is very incomplete and I'm looking for suggestions to add to it until it ends up like my UWP List:

 

https://github.com/10UWP/The-UWP-Tools-List

 

Basically, I want it to be an easy starter reference of tool sets  for the experienced C#/XAML developer to do some clean focused work and avoid the huge Hipster noise level of the Whack-A-Mole Web Design world. On GitHub, finding a good selection of UWP tools is not easy due to the horrible organization of GitHub so my list can really save people some time. For React.js, I think we have the opposite situation of a fire hose of JS-lib-of-the-week and the list will be good for non-web developers who don't live and breath the crazy web Hipster Culture on a daily basis.

 

I'm also starting a Machine Learning list which is currently empty:

 

https://github.com/10UWP/The-Cognitive-and-ML-List

 

 

Edited by DevTech
added Reference to the title to suggest old thread not get locke

7 answers to this question

Recommended Posts

  • 0

I find that the following work quite well together on the front-end:

  • React
  • Redux
  • redux-updeep - enforce immutability, update state with little boilerplate
  • redux-observable - easily compose anything async with RxJS
  • Flow - forget about prop types, we want real types
  • 0
4 hours ago, vhane said:

I find that the following work quite well together on the front-end:

  • React
  • Redux
  • redux-updeep - enforce immutability, update state with little boilerplate
  • redux-observable - easily compose anything async with RxJS
  • Flow - forget about prop types, we want real types

I will add your suggestions to the list.

 

https://github.com/10UWP/The-React-List

 

I'll create a new section for individual projects...

 

  • 0
4 hours ago, vhane said:

I find that the following work quite well together on the front-end:

  • React
  • Redux
  • redux-updeep - enforce immutability, update state with little boilerplate
  • redux-observable - easily compose anything async with RxJS
  • Flow - forget about prop types, we want real types

OK, I added your projects, but I also added the following note for Flow:

 

" **Warning** Flow has a serious defect or faulty design that appears to prevent installation on a Windows computer. Very unprofessional in 2016 to not test a project on the O/S used by 95% of the human population. This project was added based on user-feedback to this list but until this defect is repaired, it's simply not usable."

 

Microsoft owns a percentage of Facebook and normally they interop quite well, but the Mysterious is still alive and well in 2016. Perhaps, Typescript would be the Microsoft suggested way of adding types to JS, although Typescript appears to be far more sophisticated and broad in scope whereas Flow might have a place as a low ceremony tool, if it actually worked!

 

Thanks for your suggestions.

 

  • 0
7 hours ago, DevTech said:

OK, I added your projects, but I also added the following note for Flow:

 

" **Warning** Flow has a serious defect or faulty design that appears to prevent installation on a Windows computer. Very unprofessional in 2016 to not test a project on the O/S used by 95% of the human population. This project was added based on user-feedback to this list but until this defect is repaired, it's simply not usable."

 

Microsoft owns a percentage of Facebook and normally they interop quite well, but the Mysterious is still alive and well in 2016. Perhaps, Typescript would be the Microsoft suggested way of adding types to JS, although Typescript appears to be far more sophisticated and broad in scope whereas Flow might have a place as a low ceremony tool, if it actually worked!

 

Thanks for your suggestions.

 

I think that your warning would be more useful if it had a summary of the problem with a link to the GitHub issue.

 

Both Typescript and Flow are good tools. Some of the features that Typescript add to JS morphs the language to be more like C# or Java. Flow simply adds types to JS and doesn't try to do that. In the long run it could be that Flow is better suited to React and Typescript to Angular since React and Flow are both Facebook projects whereas Google have adopted Typescript for Angular.

 

Another thing to consider is that Typescript currently enjoys better tooling support, IDE integrations.

 

At the end of the day, JS is better off with type-checking than without :)

  • 0
2 hours ago, vhane said:

I think that your warning would be more useful if it had a summary of the problem with a link to the GitHub issue.

 

Both Typescript and Flow are good tools. Some of the features that Typescript add to JS morphs the language to be more like C# or Java. Flow simply adds types to JS and doesn't try to do that. In the long run it could be that Flow is better suited to React and Typescript to Angular since React and Flow are both Facebook projects whereas Google have adopted Typescript for Angular.

 

Another thing to consider is that Typescript currently enjoys better tooling support, IDE integrations.

 

At the end of the day, JS is better off with type-checking than without :)

Thank you for your thoughts and suggestions.

 

If you examine the UWP Tools List which is a work-in-progress that is further along than the React List, you might get some idea of the time involved and that I have a choice to:

 

  • add more material or
  • make the existing material more detailed and accurate or
  • divide my allocation of time for that hobby across a couple of lists

 

In the case of Flow, I was trying to be low key by using the word "defect" instead of "designed by country bumpkins who took a dependency on a Linux-only library" - Facebook also has a live debugging environment with the same issue. I can rant I all want on internal Facebook Fanboyism that might have been to root cause of a poor decision, but at the end of the day they are open sourcing internal projects that they use, for the benefit of all mankind and my take on it as a Windows Developer with a skeptical eye on the usefulness of web technology and its Hipster Culture is simply to point out to other developers, possible paths through the maze that can possibly approach the beauty and elegance of C# and XAML. Rx.js is one gateway that I consider to be a good approach and can lead one to the door of Facebook and the React/Flux architecture.

 

There are many other approaches of course but that's a list for someone else to present. I wish I could present a plan to make Flow more universal since it seems like a great idea but for now hacking on the internals of Flow is way beyond the scope of what I am trying to accomplish.

 

 

  • 0
22 hours ago, DevTech said:

Thank you for your thoughts and suggestions.

 

If you examine the UWP Tools List which is a work-in-progress that is further along than the React List, you might get some idea of the time involved and that I have a choice to:

 

  • add more material or
  • make the existing material more detailed and accurate or
  • divide my allocation of time for that hobby across a couple of lists

 

In the case of Flow, I was trying to be low key by using the word "defect" instead of "designed by country bumpkins who took a dependency on a Linux-only library" - Facebook also has a live debugging environment with the same issue. I can rant I all want on internal Facebook Fanboyism that might have been to root cause of a poor decision, but at the end of the day they are open sourcing internal projects that they use, for the benefit of all mankind and my take on it as a Windows Developer with a skeptical eye on the usefulness of web technology and its Hipster Culture is simply to point out to other developers, possible paths through the maze that can possibly approach the beauty and elegance of C# and XAML. Rx.js is one gateway that I consider to be a good approach and can lead one to the door of Facebook and the React/Flux architecture.

 

There are many other approaches of course but that's a list for someone else to present. I wish I could present a plan to make Flow more universal since it seems like a great idea but for now hacking on the internals of Flow is way beyond the scope of what I am trying to accomplish.

 

 

Do you have a GitHub link to the issue with Flow? I'm not being argumentative - I really want more information on this (and track progress). The project ostensibly ships a Windows binary. It's possible that Flow via bash on Windows might work too.

  • 0
1 hour ago, vhane said:

Do you have a GitHub link to the issue with Flow? I'm not being argumentative - I really want more information on this (and track progress). The project ostensibly ships a Windows binary. It's possible that Flow via bash on Windows might work too.

Thanks for directing my attention to this. I only have so much time and normally go with whatever text is on the GitHub page which in the case of Flow reads out (still) as :


 

Quote

 

https://github.com/facebook/flow

Requirements

 

Flow works with:

 

Mac OS X

Linux (64-bit)

 

There are binary distributions for Mac OS X and many variants of Linux; you can also build it from source on almost any 64-bit Linux variant.

 

Obviously somebody on the Facebook dev team is a *#$* presumably high enough on their management chain to have influence but reason appears to have prevailed finally although there is no indication if the root cause was addressed.

 

https://github.com/facebook/flow/issues/6

 

Issue #6 - opened Nov 14, 2014 and closed Aug 1, 2016 - which produced this blog entry:

 

https://flowtype.org/blog/2016/08/01/Windows-Support.html

 

windows.gif

 

 

Download at:

 

https://github.com/facebook/flow/releases

 

Edited by DevTech
Added download link for Facebook Flow
This topic is now closed to further replies.
  • Posts

    • The proportion (or number of iterations) has nothing to with this aspect of Copyright I am describing. In short, it doesn't matter how many times the manager tells you to change something or how. Your work product is always YOURS until and unless you then assign that to the person representing the client/company, usually for financial compensation -- either in salary or as a subcontract work for hire payment. if iterations determined copyright, then businesses would have learned to just keep making changes until they could claim they owned the copyright, without having to compensate the artist for their work. And that would be BAD. The only place where the amount of changes does have a role is in how much does a human modify a previous public domain work (from any source) before it is considered fair use or their own work, etc. For example, if a human makes substantial changes to a public domain (re: AI, by definition) work, then they can then claim that derivative work as their own...but NEVER the original version, of course. That's why anyone can make a movie about Dracula, for example, as long as it is based on the public domain novel, but not if they take new ideas from copyrighted movies made afterwards. As one of the people who personally advised the US Copyright Office on their recent ruling on these very issues, be assured that I specifically used the terminology precisely -- though I made it simple enough for laymen to understand it. If I made this confusing by doing so, I apologize. But, to be clear regarding your assumption that I would agree to your second statement that I quoted above -- the answer is NO. If AI does the work, no matter how much "direction" you give it, it cannot be copyrighted. All AI generated content is in the Public Domain and therefore the copyright cannot be assigned to ANYONE, even you -- until and unless substantial modifications are made to it BY A HUMAN BEING (yourself or a contracted artist/writer/etc.) and then that copyright on the derivative work is legally (in writing) transferred to you. This is a critical distinction. And it is important that people, especially AI sloppers, understand this. For example, YouTube is not paying AI slop generators for the copyright, etc. of their AI slop. What YouTube is doing is sharing AD REVENUE for permission to publish your AI slop. Copyright/ownership/rights never come into it. Importantly, that means that anyone can copy any AI slopware on YouTube, etc. and rehost it anywhere they want, even back on YouTube, and there is nothing legal that YouTube can do about it with regards to copyright protections, ownership, DMCA, etc. Anyone is legally free to use any AI slopware in any way they want. When this ruling was pending, I warned Disney legal of all of this before they did their OpenAI deal -- that it would literally dilute their entire IP portfolio forever. They ignored that warning for the PR and stock bump. But that is why, when the ruling came down last year, Disney quickly extricated themselves from that OpenAI deal, even eating the initial upfront fees -- followed closely by OpenAI ending their entire AI video generating business model. They adjusted their PR release dates to make this less obvious to shareholders, of course. Phew. I hope that this clears up the key distinctions for you and anyone reading. If you have any additional questions or even hypotheticals about AI and Copyright, please feel free to ask.
    • Each of the devices displayed on this page now has a little volume meter next to it to show if there is audio actively playing. About time.
    • Owing to the nature of Windows feature enablement updates, it was distributed over Windows Update services as a complete system upgrade rather than as an ordinary cumulative update
    • Microsoft confirms Windows 11 26H2, urges IT admins to prepare for release by Usama Jawad Windows 11 typically follows an annual update cycle, but Microsoft recently broke that tradition a bit by releasing a "26H1" version in the first half of this year as a "scoped" build for select new silicon PCs only. This version was not available for customers using 24H2 and 25H2 builds, as Microsoft is busy preparing version 26H2 for them, confirmed officially for the first time. In a Windows IT Pro blog, Microsoft has urged IT admins to prepare for the upcoming release of Windows 11 version 26H2. The company has confirmed that this will be a small enablement package (eKB) that will simply light up certain disabled features that are already present in the operating system's code base. This means that the "refined" Windows update and deployment experience will be simpler and quicker, with minimal disruptions, as the feature update will simply toggle a few flags rather than performing a complete replacement. Microsoft has explained that this is all possible because the standard Windows 11 releases share the same servicing branch and hence, the same source code. However, this also means that Windows 11 26H1 users won't be able to upgrade to 26H2 as that is a different branch, but this is something we have known for a while now. Similar to previous annual feature updates, Windows 11 26H2 will offer the following support cycles: 24 months of support for Home, Pro, Pro EDU, and Pro for Workstations editions 36 months of support for Enterprise, Education, IoT Enterprise, and Enterprise Multi-session editions Microsoft has not confirmed a concrete release date for Windows 11 26H2, but noted that it is "coming soon". If we go by the ongoing release cadence, we can expect it to begin rolling out in early October 2026. As such, IT admins have been encouraged to begin validating Windows Insider releases in the Experimental Channel, plan rollout rings, and strategize the utilization of their existing deployment tools.
  • Recent Achievements

    • Collaborator
      ryansurfer98 went up a rank
      Collaborator
    • Week One Done
      Eurosoft10 earned a badge
      Week One Done
    • One Month Later
      Eurosoft10 earned a badge
      One Month Later
    • One Year In
      Skeet Campbell earned a badge
      One Year In
    • One Month Later
      Sharbel earned a badge
      One Month Later
  • Popular Contributors

    1. 1
      +primortal
      576
    2. 2
      +Edouard
      188
    3. 3
      Michael Scrip
      79
    4. 4
      PsYcHoKiLLa
      77
    5. 5
      neufuse
      72
  • Tell a friend

    Love Neowin? Tell a friend!