cybercongress / gravity

Energy efficient interface library
https://cybercongress.github.io/gravity/
13 stars 3 forks source link

Define tech stack for gravity #22

Closed mastercyb closed 5 years ago

mastercyb commented 5 years ago

Currently, the problem is the following:

@dimakorzhovnik is working with react and as a result, we implemented cyb and gravity lib using react

@Jonybang is working with vue and that is why the virus is implemented in vue.

It's a bad idea to work like this as we must spend resources to implement and test things twice.

My proposal: switch to https://svelte.dev/ instead of both react and vue. It is cool, fast, lean and hurts nobody.

In order to convince me to use either react or vue, please show me the proof that you will be able to produce at least 3x less code than svelte does.

I am starting to block any pull requests both into cyb and cyb-virus before we settle this out.

@dimakorzhovnik @Jonybang

MicrowaveDev commented 5 years ago

I dont think that is a good idea. Because react have a huge community, vue have a little smaller community, there is many tools already built on react and vue, many questions are answered in both of them, but not for svetle. I think solution should be done based on not "less code", but on experience and community

mastercyb commented 5 years ago

I think a solution should be done based on not "less code", but on experience and community

Wrong assumption. Web3 opportunity is, in fact, lean and fast computing. Performance and bandwidth is everything that is important in the end. It is a way simpler to tradeoff some features (because, you know, we can) than trying to get all js legacy in kilobytes of code for every page.

In our gravity library, we need something like 15-20 elements in order to radically to simplify interface development.

MicrowaveDev commented 5 years ago

Size of application is matter, yes, but for NOW if we will spent a half of year to deal with new framework - it will be very sad.

mastercyb commented 5 years ago
  1. It is very sad to load megabytes of data of ugly code again and again because of our laziness
  2. I don't think we will spend so much time. Probably a couple of months.
  3. Even if that will cost us half a year, 10x reduction in speed and network usage is a good enough competitive advantage for the goal we want to achieve.

@Jonybang Always remember that we don't aim to create just another piece of software nobody will use. We need to find the shortest way to 1B users. Speed, size and simplicity are the most serious arguments the one can offer (and historically provable). And yes, good engineering could require a little bit more time and effort

mastercyb commented 5 years ago

Size of application is matter, yes, but for NOW if we will spent a half of year to deal with new framework - it will be very sad.

And it is not a framework, but the compiler, very efficient compiler

npopeka commented 5 years ago

If we want to make the Gravity component library the most popular. as a product, you need to support and react and vue and svelte and maybe more. Developers have a problem transitioning from one framework to another. The ability to get these communities exceeds, as it seems to me, the labor costs of simultaneously supporting several frameworks. I don't talk about our applications itself.

mastercyb commented 5 years ago

Guys, right now I want to solve one, but a very particular problem - creating the amazing interface for our apps. A page with 100 of bytes useful information and almost no formatting at all could not weight 100k bytes. Это называется говнокод.

mastercyb commented 5 years ago

Moving to Vue will not allow us to stay in time. First releases will be based on React including all involved applications. Thanks, everybody for discussion and involvement.