What is EROS?

If you haven’t heard of EROS, it doesn’t matter. Google it to find out what EROS is:


emmm…

Unfortunately, we seem to have collided with some mysterious force, so you’ll never be able to search our files.

It’s not hard to see how open a project’s name matters.


Get to the point

A lot of developers call EROS a framework, but I don’t think it is.

EROS is based on the WEEX SDK, which expands a series of tools, exposes a lot of native capabilities, and lets developers develop apps on both ends using Vue. It’s more like another development solution for WEEX.

Main project address: EROS

Simple statistics

  • 50 + online apps, involving industries in blockchain, information, medical, investment, shopping, government, office, live broadcasting, etc.
  • 180+ issues, 170 have been closed
  • Has a thousand active developers (where most issues are stillborn)
  • Nearly 30 open source projects (including plug-ins contributed by contributors)

EROS Star just broke 1,000 last week.


Ranked 6th among new open source projects released by Mybridge in June Vue.


Vue. Js Open Source Projects of the Month (V.June 2018)

Although there is a big gap with many excellent projects, it is already a good start. Please enjoy the detours we did not miss in those years.

Prophase: Nothing but chaos, chaos.

In the beginning we did open source like this:

  • Internal Git creates a development template project and publishes it to NPM.
  • Internal scaffolding supports EROS related services, packaging functions to NPM.

At that time, we added a WEEX and had a relatively large group (WEEX boss in the group), which could basically be described as “horrible”, people were asking questions every day, asking different questions, asking a question was quickly overwhelmed.

Then we sent a small advertisement in this “horrible” group, and dozens of “head iron” developers flooded in that day, and as you can guess, our group also became a “horrible” group…

A few more “classic” questions at that time

  • Open source problemAlthough nominally open source, the code is stored in node_modules, so developers can see it and not modify it.
  • Environmental problems: MostFront-end developerTotally unmanageable, only the client developers who are familiar with the front end, experienced developers can run itdemo.
  • Document problem: The documentation is incomplete and there are too many things that are not taken into account or explained.
  • compatibility: Because the team used Macs, the scaffolding was not compatible with Windows/Linux, so many people fell on their knees at the first step, and there were many compatibility issues with the native capabilities that were exposed.
  • Update problems: For the underlying SDK, a lot of the names are not right, the design is not standard, every time the update is doneCliff renewalMany users can’t run after updating.
  • Code problem: Because there is not a lot of manpower to carry out the early test, resulting in too many bugs, there is not a completedemoLet’s do a quick post-development test.

thinking

During this period, the number of developers entering the community was about the same as the number of developers leaving the community, and it was only then that we began to realize a few things:

The open source EROS is not the same as when we do projects, teams contribute plug-ins, components, etc. There are a lot of projects that are interlinked and heavily coupled, and even a slight change may cause developers to lose.

This is directly related to our lack of early developer research and open source experience, when we are not there
Team oriented, but
For developersIn between
Incremental problemWe were almost at a loss what to do.

We don’t have a clear definition of EROS, and we don’t have a good plan for developer growth.

This was a killer, and without a clear definition, we were like chickens with our heads cut off, stuck in a never-ending problem solving, and there was a big chunk of time when our team was working on it, even after 12 o ‘clock at night.

Our exposed native capabilities are not enough to support more business.

For example, if you don’t have a component in your business that needs to upload images, most developers will leave. We have to develop a lot of native capabilities to retain developers, and in fact, we have accumulated and exposed a lot of native capabilities during this time.

action

Yards cloud screenshots
  • We first moved all the project source code to the domesticYards cloudOn, in the process of moving, incidentally solved the above problem
  • The scaffold is compatible with all platform document completion and open at the same timeQ&a sectionTo record frequently asked questions
  • The client is fully invested in the Fix compatibility group to collect developer requirements, and the client is prioritized to implement them
  • Every update comes with a migration guide that informs the developer community (because we know that few people outside the community use it)
  • Write a simpler onedemoConvenient test
  • Regularly discuss within the group, summarize the deficiencies in the process, record them and optimize them regularly
  • Every time a developer crashes, use language consolation and try to answer the questions answered in the group, no matter how big or small…

The first APP

Finally, in the first month after we moved to Code Cloud, a developer finally made the first dual-terminal APP, Lianyungang Diandian. Although the function was simple, it was a great encouragement to our whole team. It was really a developer who accompanied us to update and try and make mistakes again and again.

Lianyungang Diandian Connect ios/Android

What audience did we have during that time

  • A small company
  • Outsourcing company,
  • Indie developer

Because of the problems we have mentioned above, companies of a slightly larger size would definitely not use RN, or bite the bullet and use WEEX.

Medium term: Grow with developers

We stayed in the cloud until around November, when it seemed to be stable:

  • It is known that the online APP is close to the APP under development10about
  • Client side stable expansion function existing BUG solved almost
  • The documentation has also been completed and optimized to make it easier for developers to understand
  • The developer community is also growing

Immature stability = facing no fruit

This immature stability gives us a wake-up call:

  • We need to release the code to a larger platform
  • We need to decouple the project more and we need to optimize the volume of the project
  • We need more experienced, scalable teams to work with and we need to make the development process faster and the development experience more user-friendly
  • What do developers need at this point

And then we did these things:

  • All projects are migrated toGithub
  • Individual projects such aseros-cli.eros-publish 等
  • We usedocsifyDocumentation has been refactored and more mechanics have been added to make it easier for developers to understand.
  • We optimized the development process by adding one or more simulators/real machines at the same timeHot refresh
  • We are not limited to JS bundles. The idea of only using as a page, in view of the deficiencies of MPA – like projects, developedBoarding Bundle 和Broker Bundle.Reduced package volume by 60%+.
  • A new version of the underlying SDK has been optimized for the client, a new Widget has been reconstructed for the front end, and apis have been optimized for use.
  • We sent a questionnaire to the developers in the group to collect the current needs of developers
  • Prepare the new large version of the migration document

Screenshots of the questionnaire:

I sent out the questionnaire for the first time and received very detailed feedback.

After all this

  • Development efficiency goes up a notch.
  • We’ve accumulated more primary abilities.
  • There is less coupling and more stability between projects.
  • More and more teams are joining EROS. There are also projects that have migrated from WEEX to EROS.
  • We have a plan for EROS as well.

In the follow-up communication, can obviously feel the qualitative improvement of development efficiency, here exposed the previous questionnaire development cycle, we are not difficult to see that WEEX in a certain range of business complexity development efficiency is really very high.

In the questionnaire, we also counted the development efficiency.

Near term: Give developers more power

Quadratic stability

After completing the above optimization, we once again entered a seemingly stable period, during which there would be APP launch every week and more and more developers, but a serious problem was exposed:

At present, although we have expanded many original functions, it is still far from meeting the needs of users. Meanwhile, we have our own business to develop, so it is difficult to have a lot of time and experience to help developers develop quickly.

So we decided to introduce a plug-in solution to allow more developers to become contributors.

When it comes to plugins, many people ask, shouldn’t this have been considered in the first place? Said this is beginning to question, we started to EROS a good positioning and planning, we want to do a lot at the beginning of “the tank”, but we face a lot of business, while a group responsible for nearly five or so warehouse, also in helping developers to answer questions, bug fixes, it was already very hard.

Forming small communities

Earlier this year, our client invested in the plug-in scheme. It took nearly 3 months from design to final landing. Because the WEEX plug-in market has been basically unmaintained, we did not use WEEX’s own plug-in scheme.

At the same time, in the process of plug-in, we also separated our SDK into plug-ins, further decoupling the project. Users now only need to modify the dependent version number to upgrade, which solves the problem of user update difficulty.

We did not do a plug-in market, but encouraged a large number of native developers to expand the plug-in and upload it to their Github, and guide the star and issue within the group to help improve the stability of the plug-in and the enthusiasm of developers.

When we have a very active pool of 1,000 developers, the developers within it are motivated to make better plug-ins and get feedback faster and more quickly, like github Star.

With pluggable stability, the group has thousands of pieces of information is no longer the original appearance, most developers are talking about the implementation, train of thought, at the same time experienced developers can help us to solve most of the problems in the group, let’s relaxed a lot of, have more time to think, to optimize and expand, and more and more excellent developers contribute their plug-in, solution, Articles, etc., also let us learn a lot.

EROS integrates with existing iOS apps
Weex Eros framework source code analysis – digging gold

To reflect on the present is to ask no questions

We recently went back to the drawing board and listed a few (but not all) of our current problems:

  • The operating experience needs to be optimized
  • Development templates are not flexible enough
  • Hot update service is not flexible enough
  • Performance problems in complex scenarios
  • Need to support more types of applications, etc
  • Plan and organize existing project integration scheme
  • Quality control of plug-in ecology
  • Easy to understand and internationalization of documents, etc

Fortunately, for a few of these issues, developers have already contributed their solutions so that we can better learn from them and not be alone.

Why reflect on current problems in the future?

No problems may mean that the project has no futureIf we hadn’t looked at ourselves from a higher point of view than we are now at a certain point in time, EROS would hardly have existed.

This is stolen from the Internet, regardless of the watermark

For WEEX

There are a lot of bad things said about WEEX in many places, but without any whitewashing on behalf of EROS developers here are a few things:

  • There are barriers to getting started, there are barriers to development, and it’s hard to do without native support in many scenarios.
  • No doubt a good project, the development experience of Vue + WEEX is really good and efficient.
  • However, incomplete documentation, limited information, and difficult communication with the official are obvious problems, such as a person across the word, WEEX should stand up and embrace developers, spend more time on developers, to truly understand the pain points in the development, to embrace more scenes, needs.
  • The development project link is very long, sometimes the cliff update problem is really unavoidable, but if the cliff update occurs, it is also necessary to update the official DEMO when giving developers the update guide, and release a stable version as soon as possible.
  • More detailed explanations and records of frequently asked questions by users.
  • More extreme performance issues, such as memory constraints caused by iconFONT font usage, should be addressed.
  • Expose more common native capabilities.

WEEX is rumored to be getting a major update this year, and we have reason to believe that the above issues will be somewhat improved.

EROS also wants to create a subset of the ecosystem that can be reversely exported to WEEX, depending on the audience and developer, and contribute to WEEX’s development.

Why open source?

Open source has a lot of advantages, the Internet said basically have, here to say our experience, not on behalf of others:

  • For developing companies, when faced with massive/explosive business growth, technology often needs to be constantly iterated, or even overturned. Open source is a process of presetting requirements. With the accumulation of functions, more scenarios can be covered, and the underlying stability of technology can be improved.
  • Team related, a good open source project can improve the stability and cohesion of the whole team, in the open source process, there will be more comprehensive growth for everyone (communication, coordination, self-learning, self-drive, etc.).
  • Building confidence, especially for small companies, is very difficult to get started, and few developers will be interested in an open source solution that doesn’t come from a big company at first.

We are still walking on the detour, maybe there is no straight road in front of us, but we are still walking.

EROS link

  • EROS main project address
  • EROS File Address
  • EROS Widgets
  • EROS Modules
  • Address of EROS plug-in

Screenshots of some products


Thank you

  • Starlife (Singapore) Big front end team

    , Che Guoda front end team, Qian Nanny front end team, Shawn Tang team, Liangcheng Shang, he Jie and other independent developers such as plug-in contribution, program output, problem solving.
  • Thanks to the developers who have been with us this year, though we may have to continue.
  • Thanks to the open source EROS, WEEX plugin developers.
  • Thanks also to all the developers who have contributed to EROS development.
  • Finally, thank you WEEX.