Too bad that this proposition is not being answered in any way. However there is still time today submit your expectations and help this project grow.
wt., 30 kwi 2019 o 08:24 Justin M. Hill <jus...@prominic.net> napisał(a): > Hi Alex, > > Thank you very much for providing insight into the proper way to approach > these matters in the Apache way. I will be mindful of the specific wording > in the future. > > > Hi Dany, > > It sounds to me like you know a lot about React! > > Maybe you could start the React part of the comparison document or FAQ > section, and then someone else who knows Royale better could fill in the > comparison pieces. > > If Royale hopes to have any wider adoption beyond traditional Flex > developers, I personally think it must communicate clearly WHY technically > the development community should care. This - to me at least - means a > pros/cons list compared to other market incumbents, without being marketing > nonsense. It should be based in facts about the technical architectures -- > exactly as you start to describe in your message. > > As Alex mentioned, we need these points to be factual and not opinion > based to maintain the Apache way. And actually, the facts are a lot more > useful than opinions, because otherwise technical conversations degrade > into "I think X way is better", instead of X way requires A instead of B > which is the method Y uses. Exactly like your DOM rendering discussion. > And that is precisely what it seems to me like you are starting to share > below about things like JQuery not being usable with React. A lot of > people know JQuery and like it, so that seems to me something in the "+" > column for Royale vs. React. > > > Regarding command lines and power users / script -- I'm all for that. I > love UNIX / Linux / Mac Terminal ... However, I also hate forcing new users > who have limited time to learn unrelated things to their immediate task. > Nobody using Mac for the first time starts with Terminal. They ease their > way into it. My hope is that we can achieve the easing in with Royale. > Otherwise, I think too much brain power around the world right now is being > spent re-learning this stuff over and over again, when it could be point > and click while still having the knobs to adjust behind the scenes. > > > It is a minor personal mission of mine to make it easier for people like > me who like to program, but have very little time to do so, and don't have > time to figure out all the nonsense I don't care about like NPM when I do > have time to program. I just want to be able to launch an IDE and tweak > the Hello World example to see how to build useful things that I can start > to tailor for my needs. That is one reason why I'm involved in > Moonshine-IDE.com and it is one of the reasons I care about Royale: we can > avoid the Javascript flavor of the month syndrome with Royale. If I later > need to get under the hood and script some things together, I'm glad I have > that option. But I don't want to start my learning experience with it. > > > Anyway, back to the topic at hand -- I'd encourage you to submit a bid for > spending some of your professional time on this documentation effort on > React. Anything you can do to illuminate these differences would be much > appreciated, even if someone else has to fill in the Royale side of the > document. > > > Thank you, > > Justin > > > > > [image: Inactive hide details for dev-digest-help---04/29/2019 10:55:35 > PM---dev Digest 30 Apr 2019 03:55:22 -0000 Issue 1978 Topics > (m]dev-digest-help---04/29/2019 > 10:55:35 PM---dev Digest 30 Apr 2019 03:55:22 -0000 Issue 1978 Topics > (messages 9973 through 9978) > > > ----- Message from Dany Dhondt <archeme...@mac.com.INVALID> on Tue, 30 > Apr 2019 05:54:49 +0200 ----- > *To:* > > dev@royale.apache.org > > *Subject:* > > Re: Let's bump Royale version to 1.0 -- submit your bid for assistance > to the group by Friday May 3 > > Hi Justin, > > As much as I would like to write an article on Royale vs. competitors, I > can’t do so at this moment because I don’t have enough Royale knowledge > yet. But there are things I could point at so that the Royale team can > formulate answers. > Here are some questions and ideas I have which could be addressed: > > 1. Royale blog > On our site, there is a section called ‘blog’. Shouldn’t we rename that? > To me, a blog is something of the past. ‘Examples’ or ‘Code snippets’ or > something similar would be better. > > 2. Faq > We definitely need a faq. Common answers to basic questions can go there. > Also, when our StackOverflow database gets rolling, we can put links to our > faq there. > > 3. (Re)rendering > One of the core principles of React is that it uses a virtual dom. You > never write to the dom directly. React does that for you. That’s why JQuery > doesn’t match at all with React. The main advantage of this, is that only > those DOM nodes get updated which actually change, making React really > fast. How does Royale tackle this? Can someone explain this in an easy to > understand way? > > 4. Managing (global) state > Updating a component in React is done by calling setState() and passing an > object to that method. That’s all very well and simple in small projects. > Passing state from parents to children is straightforward. You just pass > in state as props to underlying components. The other way around though is > hard, very hard. Handling global state is done by implementing 3rd party > technologies like Redux, MobX or recently by implementing React hooks. > I believe that Royale binding mechanisms could be superior to this. So the > question here: how does Royale handles global state? > > 5. Justin, at some point in your message, you talk about ‘command line > nonsense’. I believe you’re right and wrong at the same time. > Right because indeed, learning React is far more than learning one > technology. You have to dig through npm, node, JSX, typescript (if you want > strong typing), webpack/rollup, babel, … and in the end, most of us use > create-react-app just to hide all those configurations. BUT > Wrong because there is a massive open source community where you can find > almost anything you might need in your project. Building a modern web app > is all about combining existing code to create your application. > That brings me to this question: is it possible to embed existing pure > javascript components into Royale? > An example: one of the most crucial components in any admin application is > a calendar. In my Flex days, I had to spend hundreds of dollars to get a > decent calendar component. In React, I use fullcalendar which is a great > calendar/sheduling javascript component. Creating a calendar component from > scratch takes years as anyone who has tried will confirm. > > 6. Components, components, components, … > As I stated before, embracing a new application technology involves the > immediate availability of standard components. PAYG architecture, beads and > strands is all very powerful, but as a developer new to Royale, I’d want > ready-to-use, powerful, beautiful components which interoperate seamlessly. > > Just some random thoughts… > > > Dany > > > ----- Message from Alex Harui <aha...@adobe.com.INVALID> on Tue, 30 Apr > 2019 02:16:30 +0000 ----- > > *To:* > > "dev@royale.apache.org" <dev@royale.apache.org> > > *Subject:* > > Re: Get paid to help bring Apache Royale to version to 1.0 -- submit > your bid for assistance to the group by Friday May 3 > > Hi Royale folks, > > First, we should thank Justin Hill for his generous offer. Justin posted > this offer on dev@flex as well. This is a copy of my reply on dev@flex > so apologies if you get this twice and no need to read it again. > > This offer turns out to be a good opportunity to educate and/or remind > folks how Apache projects are different from corporate-driven projects. > Here's my take on some of important principles at Apache. Other Apache > folks may have different opinions. > > 1) The Apache Software Foundation (the ASF) itself does not pay people to > contribute to its projects. So the subject of this email is a bit > concerning since it could imply that. But in this case, a company > (Prominic) or a person (Justin Hill) is proposing to pay for contributions > just like anyone hiring a contractor or employee. Which is totally fine > and in fact, encouraged. It would be great if all of you who are planning > to use Royale would pay for contributions as long as you make it clear that > the ASF is not the entity paying. This includes, of course, contributing > patches or features to Royale that you write yourself (where you are paying > yourself or your employer is paying you). Royale is free software, but > Royale will be better if every user finds a way to contribute. There is no > big corporation like Adobe putting in money up front to try to guarantee > success. This is more like a potluck than a restaurant. > > IMO, it is fine for now for folks to post job offers on the mailing > lists. If we get too many job offers, we can ask for a separate mailing > list or some other place to share job information, but for now, I am > personally ok with having offers of work-for-pay posted on the list with a > [JOB] prefix. Others are welcome to object or propose other ideas. But > basically, we want to encourage the growth of the Royale job ecosystem > without implying that Apache pays for contributions. So in the future, > please use [JOB] or whatever we converge on to distinguish that someone > else is paying. > > And that leads to point 2... > > 2) Work paid for by someone else is not guaranteed to be accepted into the > codebase. Whatever code or other IP is paid for and generated > (documentation, graphics, videos, etc) might be rejected just like any > other code contribution from a committer. Rejections should be very rare > in Royale as we have designed Royale to be loosely-coupled so the impact of > some code on other code should be minimized. But the fact remains that if > a contribution does not have technical merit or has licensing issues it may > not be accepted and certainly not because someone paid someone for it. > > One reason something could be rejected is because of point 3... > > 3) Apache does not want to appear to be influenced by corporations and > business. What this really means is that no business entity should appear > to be running the project, dictating schedules, roadmaps, etc. Apache is > all about individuals. The person with a few hours on the weekend should > be able to contribute. Of course, businesses with more money can pay more > folks to write more code and overwhelm the weekend person. That's just > life. But that business cannot reject the weekend person's contribution > just because it doesn’t fit into that business's goals/schedule. And, no > business can claim to be "the provider", "the sponsor", "the home of", or > use similar phrases to imply that they are the sole entity in charge of the > project. So if a paid contribution implies something like that, that would > be grounds for rejection. > > Similarly, because Apache is about individuals, we get to point 4... > > 4) No individual has more influence than any other individual. No matter > who pays you or how many hours you have to contribute or whether you > contribute documentation or code or help answer questions, you have an > equal voice. Sure, there will be technical experts on subsections of the > code that have a vision of what that subsection should do, but that's why > Royale is loosely coupled: so you can fork that subsection and create your > own variant. Royale itself probably won't designate one component set as > "the one to use". There are many to choose from with pros and cons for > your needs. And thus, it isn't up to Carlos or me or any other person to > dictate what is or isn't going to happen. > > Instead, projects get work done in a different way... > > 5) Apache projects use consensus. Without a boss to make the call, Apache > projects rely on consensus (actually, general consensus) to make > decisions. That can take more time when everyone has an equal say, but > there really aren't other options. So if you have an idea to help Royale, > post it and neither Carlos nor I will make a decision on it. We may voice > our opinions, but it will be up to everyone else reading this email list > and maybe responding to twitter posts to make it clear which ideas are most > popular. And then, since Prominic or Justin Hill is paying, ultimately it > is his call which ones to actually pay. We want whatever he pays for to > have a return on investment for him so he has money to pay for more work. > And the same goes for anyone else who can make a generous offer similar to > Justin Hill's. > > And similarly, without bosses and only individuals... > > 6) Apache projects generally don't have schedules/deadlines/roadmaps. > There is no one in the project who can fire you for not making your > deadline. We want to encourage folks to contribute even in their spare > time. So Apache projects generally don't manage detailed schedules like > you've probably experienced in other jobs. We have general goals, like > there is general consensus to get to a 1.0 as soon as possible, but we > can't set a date and manage towards it since there is no manager. We can > shoot for a date, but if we don't make it, we don't make it. Now if some > business or individual REALLY needs to hit a date, they can pay folks to > try to get more work done by that date. But Apache and the project itself > can't dictate to others what to do by what day. Or even what features are > in or out. If someone wants to contribute something that is important to > them but not to anybody else, it will go in based on its technical merit, > not some strategy document. And that is to everyone's benefit. If you've > ever posted a bug report or feature request to some provider hoping it will > be in their next release, then you can see the benefit of the Apache > model. At Apache, you can fix the bug or implement the feature yourself > and if you've earned committer rights, it is in the next release. Or pay > someone to fix the bug or implement the feature. Nobody can tell you > otherwise (unless it creates a conflict for someone else). > > Oh, and one more thing... > > 7) Apache is a non-profit so it cannot do certain kinds of marketing. > However, individuals and business can, just not on the project's web > presence. So factual comparison tables are probably ok on the Royale site, > but once you get into opinions, that is best left for individuals and > business to explain on their blogs and web presence why they chose Royale > over some other technology. > > So, in the end, Justin's email and future emails from others like this > should read more like below. > > Thanks, > -Alex > > ------------- > > Subject: [JOB] Prominic hiring contractors to bring Apache Royale to > version 1.0 > > Royale helps modernize Flex applications AND provides a great > alternative > to revitalize the next generation Flex ecosystem as a viable > alternative to > Javascript solutions such as React, Angular, and Vue. > > Get paid to help bring Apache Royale to version 1.0! > > Prominic is the company developing the Moonshine IDE for Flex and > Royale. > Prominic is willing to pay developers to help bring Royale to market as > 1.0. To apply: > > 1) join the dev@royale.apache.org mailing list > > 2) review the recent discussions on what needs to be fixed on Nabble: > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=gC1rfZiIcxvWM9NePG0GdsjNl6iFMkmKfbdrcn7vQK8%3D&reserved=0 > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-royale-development.20373.n8.nabble.com&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=gC1rfZiIcxvWM9NePG0GdsjNl6iFMkmKfbdrcn7vQK8%3D&reserved=0> > > 3) Submit to the dev@royale.apache.org mailing list your bid for > assistance > to the group by Friday May 3 > > The Moonshine-IDE.com team is willing to donate $2,500 USD in total over > the next 30 days to anyone who can accomplish agreed upon tasks > to help Royale release a 1.0 version. > > IF you who are willing to step up to the plate immediately (with a > deliverable no later than May 26, 2019) to help with: > > * documentation (ASDoc style) > > * examples (code snippets that do things like Tour de Royale) > > * tutorials (well written, friendly, understandable, educational > material) > > * a mini reproduction of the aforementioned Flex In a Week Series (great > idea!) > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.adobe.com%2Fdevnet%2Fflex%2Fvideotraining.html&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=ehetZFgS6Tn9fR0PbFGjKh2yILbeKnKKhfV8ChhM9SA%3D&reserved=0 > <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.adobe.com%2Fdevnet%2Fflex%2Fvideotraining.html&data=02%7C01%7Caharui%40adobe.com%7Cfc2244e2b6984cf86aa608d6ccc9c75a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636921564340786626&sdata=ehetZFgS6Tn9fR0PbFGjKh2yILbeKnKKhfV8ChhM9SA%3D&reserved=0> > > * build automation > > * automated test cases > > * creation of a summary comparison table showing Royale relative to > React, > Vue, Angular > > * a longer write up of competitive articles detailed why Royale is > important. BTW, one reason it can be important is because it is NOT > controlled by giant companies. > > * a directory of consultants for hire: > > * OR anything else you would want to see in a 1.0 version of Royale > > THEN > > Please submit to this public group your commitment and cost. > > We will then do this democratically: > deadline for bid submissions is 7 days from now -- Friday May 3. Folks > on this mailing list should offer their thoughts and opinions on the bids. > Carlos (or someone who knows Twitter enough to create another poll) will > then do another Twitter vote poll for 3 days to see what folks think of > the various proposals. Prominic alone will decide which bids it will pay > for taking into consideration the discussion threads. > > > > Ideally multiple people will commit to doing something "small" for $500 > each and Prominic can award 5 people the projects. > > The $2,500 USD total will be paid via PayPal. No exceptions. > > Please note that the work you do may not be accepted into the project > repos. If your work is not accepted, Prominic will work with you and the > project on next steps. Your work may end up on the Moonshine-IDE site or > other places. Prominic cannot dictate production deadlines for an Apache > project so If the 30 day and 60 day deadlines are not met, Prominic > reserves the right to change the offer or its deadlines. Prominic is not > the only business entity involved with Royale and encourages other business > entities to make similar offers to help Royale mature to be your solution > for building applications for web/mobile/desktop. > > IF within 30 days Apache Royale 1.0 is released to the public then the > Moonshine-IDE.com team will again donate $2,500 for the month of June > in an > identical voting scenario (assuming this one works well) to bring home a > 1.1 release. > > > By 60 days from now, a new user who has never seen Royale before or > programmed in ActionScript should be able to: > 1) Arrive at the Apache Royale web page > > 2) Understand from the home page why they should care about the project > if > they come from React, Vue, Angular, Flex, or ActionScript worlds > > 3) Be able to within 5 mouse clicks (download button, install button, > launch button, build button, run button) go from having nothing on their > machine to having an IDE (we of course volunteer Moonshine but Visual > Studio Code should be a goal for this, too) on their machine with a > successful build of their first "hello world". No command line > nonsense. > No learning NPM, Git, downloading 20 required packages. See Royale > website. Want to try it. 5 clicks later build your Hello World. > > If the above 3 goals are met, then the Moonshine-IDE.com team will run a > 3rd donation round of $2,500 for the month of July in a manner to the > description above to bring home a 1.2 release, to be published no later > than the end of July 2019 for the awards to be paid. > > > Hopefully this helps motivate the team. > > Thank you, > > Justin Hill > > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
