Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:11

    niranjan94 on gh-pages

    Deploy fossasia/open-event-fron… (compare)

  • 08:04
    dependabot-preview[bot] synchronize #3877
  • 08:04

    dependabot-preview[bot] on npm_and_yarn

    chore(deps-dev): bump ember-inf… (compare)

  • 08:04
    dependabot-preview[bot] edited #3877
  • 08:04
    dependabot-preview[bot] synchronize #3879
  • 08:04

    dependabot-preview[bot] on npm_and_yarn

    chore(deps-dev): bump ember-dat… (compare)

  • 08:04
    dependabot-preview[bot] edited #3879
  • 08:04
    dependabot-preview[bot] synchronize #3873
  • 08:04

    dependabot-preview[bot] on npm_and_yarn

    chore(deps-dev): bump ember-mat… (compare)

  • 08:04
    dependabot-preview[bot] edited #3873
  • 08:04
    dependabot-preview[bot] synchronize #3875
  • 08:04

    dependabot-preview[bot] on npm_and_yarn

    chore(deps-dev): bump eslint-pl… (compare)

  • 08:04
    dependabot-preview[bot] synchronize #3872
  • 08:03

    dependabot-preview[bot] on npm_and_yarn

    chore(deps-dev): bump semantic-… (compare)

  • 08:03
    dependabot-preview[bot] edited #3875
  • 08:03
    dependabot-preview[bot] edited #3872
  • 08:03
    dependabot-preview[bot] edited #3878
  • 08:02
    niranjan94 commented #3855
  • 08:02
    niranjan94 commented #3855
  • 08:01
    kushthedude synchronize #3878
Mario Behling
@mariobehling
@iamareebjamal It was great to discuss the next steps with the open event frontend with you. In order to keep everyone aligned, could you list the key points of the challenges with emberJS here, please?
Sai Charan
@mrsaicharan1
@mariobehling It would be great if you could update the ideas page for Open Event
Areeb Jamal
@iamareebjamal
Sure, I'll do it by EOD
Areeb Jamal
@iamareebjamal

Challenges with ember

There are several challenges with ember moving forward. However, we are just evaluating alternatives and whether it will be worth continuing with it after upgradng to latest and patching fixes or change it with other, more modular and lightweight UI library/framework.

Before mentioning the problems, I'd like to inform that currently there are no good alternatives to ember data which is state of the art state management and data fetching solution for JSONAPI. Even though we don't have many problems with JSONAPI that we won't have with other solutions like GraphQL, we have to evaluate its limitations, unpopularity, lack of maintainence and libraries along with it. Lack of tooling for JSONAPI for other frameworks should also be seen as a potential problem in future as compared to other popular API patterns. Hence, if we switch to a different API format, ember data does not remain the best way to load and manage state, and we have more framework agnostic solutions like apollo client with us, which also work on mobile clients like Android and iOS.
However, that is a separate discussion, and for this one, we'll assume that JSONAPI is the way we are moving forward, since anyway GraphQL solutions in python are not great, even though they are better than flask-rest-jsonapi which we are curently using. Making ember data best in class solution to deal. Alas, I think that's the only thing ember has going for itself.

Note: At any point, we should not move forward with replacing ember unless we have every use case's alternative as good as it is in ember or better under current scenario.

Not as good alternatives:

Challenges

Not being one of the top 3 frameworks

Today resume driven development is a thing. Angular, React or Vue are top frameworks with most developers and hence,

  • also have most tooling and support.
  • Issues get fixed faster as they have more sponsors and comapnies backing them.
    Even if issues get fixed in core ember, they pile up in 3rd party packages where they haven't been solved in years
  • Packages get deprecated or rarely updated as even the people who worked on them move to other popular frameworks
  • Plugins are not so straightforward that we can run our own versions of them or implement them in custom way

It is also difficult to learn. It has much steeper learning curve than even react. And most people who come across open event frontend have to learn it for the first time

Way of doing things

Ember reinvents everything

And hence, curbs transferrable knowledge, and also has become very large.

Browser APIs

From events (which it now deprecated), to runtime and tick system and other components which browser already has. Which makes it feel like a VM running on top of browser from which we can run our code. We don't run ember, ember runs us.

Web as a platform is not going anywhere. React, Vue, Angular, Ember will die, web will remain. There's a tradeoff in learning component systems like React and Vue since Platform alternatives like Custom Elements are not there yet and you still need routing, SSR and state management. So, I can understand using libraries for stuff that browser does not provide and learn a new thing. But why learn an entirely new ecosystem to replace APIs already there in browser? setTimeout will remain forever, ember tick may not.

Bundling

Everyone either uses webpack or rollup, they have thousands of plugins, and reporting capabilities. Ember reinvents bundling and uses broccoli. A dev using react, vue, angular, svelte, aurelia, moon, literally any other framework knows webpack. It has transferrable knowledge. When someone encounters a webpack bug, they may require expertise in it to fix it (which is not easy to come), but now they can fix any webpack build independent of framework being used. In comparison, I am yet to find a bundle analyzer and async lazy loader plugin for broccoli. I want to see the distribution of vendor JS compoenents and split them by routes or lazy load them? How do I do that? In webpack and rollup, I just change that to dynamic import. In react and vue both, routers support async components and route based chunking so that JS is only loaded when I go to that endpoint. It might not even be present or possible in ember. Or maybe it is, and some ember guru points me out to it. The point is that is is far easier to find webpack guru than ember broccoli guru. It is even easier to write your own plugin for rollup and anyone can use it, be they from react or vue. If someone tries to write a broccoli plugin, they will only benefit ember, and hence don't do it.

Small hookable surface area

As mentioned previously, you don't call ember, ember calls you. You write code in small hooks which ember provides. So you beg for it to get a little more control. For example. ember simple auth redirect after login is still not working because it provides you callbacks in a manner where it is not sufficient to load data required before transitioning to new route. A feature which is as simple as appending ?next=/events/wqe4334e/cfs in login URL and routing after login is complete. I recently had to write an entire partial JS parser to replace the environment dynamically in docker container using environment variables just because how ember env works. It is hardcoded in the JS and you can't change it's behaviour until that feature is added in ember core.

Given that none of these features are present in other libraries, you either have to write your own solutions or use another library, but at least you have flexibility to do what you want. And it is closer to the metal.

However these problems are somewhat still there in frameworks like Next and Nuxt, but they still don't force you to use one solution, they just mostly provide routing, SSR and auto configuration of state management, which are the problems I mentioned do not have solution on native web platform. How you want to deal with environments and auth redirection is on you.

Components
Changes

Let's play a game. Open ember docs and switch the version and see how the way of writing components changes drastically every 3-4 minor versions. Imagine trying to teach someone on how to write ember components. Is it arrow syntax? curly bracket syntax? It's a mix of both? All stars and versions must align for you to find what is good and what isn't. Ember changes its syntax drastically across versions. Even though it is good that they are making it better and using ES classes and decorator and getters, it still causes massive incomplete and buggy refactoring everytime it has to be updated. It is not a good experience. Try to find last time Vue or React changed its syntax. React only added hooks and Vue is doing same with composition API. Syntax remains same. The last time AngularJS became Angular, they lost most of their customers.

Code Locality

I make a change in template, and I want to add a computed property. Now, I need to search through the entire thing to find which JS file to edit? And then there are disjoint routes and controllers and components. Everyone agreed on the pattern of local logic and UI since advent of AngularJS and React. Vue follows the same pattern. Template/Rendering logic sits together with state, props and data logic:

component('speaker-info', {
  props: {
    firstName: String,
    lastName: String,
    featured: Boolean,
    avatar: String,
    github: String
  },
  data: _ => ({
    followers: null,
    following: null,
    loading: true
  }),
  computed: {
    fullName() {
      return this.firstName + ' ' + this.lastName
    }
  },
  async mounted() {
    const {followers, following} = await fetch(this.github);
    this.followers = followers;
    this.following = following;
    this.loading = false;
  },
  template: `
  <div :class="{ featured_speaker: featured }">
    {{ fullName }}
    <img src="{{avatar}}" />
    <Loader v-if="loading" />
    <div v-else>
      Followers: {{followers}}
      Following: {{following}}
    </div>
  </div>
  `
})
SSR

Since we use SSR in production, many of the bugs reported are not reproduced locally since they are SSR specific. However, this is preventable if we ask developers to also use fastboot locally, but it is not just a simple config switch like in other frameworks (or maybe I'm wrong. I did not find any)

Esoteric Syntax

Which is better?

<div v-if="(isAdmin || isCoorganizer) && hasSpeakers"></div>
{#if _and(hasSpeakers _or(isAdmin isCoorganizers))}
<div></div>
{#endif }

I don't even know if the last one is correct to be honest with you.

Conclusion

Due to aforementioned reasons, it becomes difficult for us to move at a fast pace because we keep fighting the framework, refactoring while upgrading to latest and fixing issues in core rather our own.
We'll see in next few months whether upgrading to latest and fixing some long standing issues improves our pace of adding new features or it is limiting us in the process

Areeb Jamal
@iamareebjamal
A lot of pros and cons in this thread. Maybe I'll pick points I agree with later on - https://www.reddit.com/r/javascript/comments/9cp8j2/serious_what_are_peoples_thoughts_on_ember_how_do/
Areeb Jamal
@iamareebjamal
Just 2 people created this event management system - https://yaherd.co/
arteevraina
@arteevraina
Hello everyone, I am Arteev and looking forward to contribute to this project
Prateek Jain
@prateekj117
@iamareebjamal :thumbsup:
Bro
@BroTheDude_gitlab
@iamareebjamal So if the decision is to not use ember, will the frontend be redesigned from scratch again?
I would love to contribute if it is in vue!
Can you share when will the decision be made
Areeb Jamal
@iamareebjamal
After 2-3 months hopefully. Understand the rewrite will be last resort and we want to ideally fix the ember workflow rather than rewrite. Rewrite will only happen if it is not working in any way and only if we find replacement for ember data
arteevraina
@arteevraina
on running ember serve command a new window opens but i cannot navigate to local host is there anybody who can help me out with this?
Sai Charan
@mrsaicharan1
@arteevraina Run the server first
Frontend needs to consume the API
Kush Trivedi
@kushthedude

@arteevraina Run the server first

Or change the API URL in .env file

Niranjan Rajendran
@niranjan94

Some very good points there @iamareebjamal . I'm finding myself agreeing with a lot of them. 😅But we do develop and run a fairly large ember app in multiple production envs at work, so from that perspective, my thoughts:

  • JSONAPI, though good in concept is painful to work with due to its state of tooling. But ember-data isn't only for JSON-API. It can work with any API that returns a json response out of the box (supporting ember-data's relationships would need some additional serializers/adapters written though). At work, we do not use JSON-API exactly for the reasons mentioned by areeb. It's easier building the api for us and our clients than just for ember-data.

  • Critical issues get fixed in core ember quite fast generally from what I have seen. But like you pointed out, third party libraries are a whole different story. What we do at work is, tend to keep third party apps to a minimum, and try to only use packages that are in active development with a lot of issues being raised and closed frequently (meaning the package is being used by a lot and the maintainers are also interested in maintaining it)

  • Ember addons are structured weirdly and and aren't the most easiest to learn, but I'd say it's not too hard to take a third party plugin and modify it either.

  • Broccoli 🥦- have spent many nights trying to fix build issues when I try to modify the build flow even a little bit. Many people who find web pack hard have never worked with Broccoli before. Broccoli is even crazier a lot of times. 😛. As for bundle analysis, I use https://github.com/kaliber5/ember-cli-bundle-analyzer

  • Dynamic imports - you still can't do for routes/components but you can do for 3rd party libraries import via ember-auto-import plugin.
  • Code splitting/chunking - not supported now. But best hope for a better ember build system is https://github.com/embroider-build/embroider which is currently being actively worked upon by ember core devs. So should see the light of day very soon. I have tried it out locally on small projects. Works nicely. Gets rid of Broccoli completely and uses webpack.

  • Ember simple auth redirect after login, I have done what you're looking for. Maybe let's discuss more on that see why it may not be working. Any PR/file I could look at?

  • What did you want to replace dynamically in the environment?

  • Components syntax. Yes the whole ember octane thing with the angle bracket syntax has been a bit messy to say the least. But I think they're going in the right direction. Also, through the syntax changes may look drastic, there is backward compatibility between minor versions. Old syntaxes still work giving time to gradually migrate over. Vue and react have not changed syntaxes drastically because ember has been there for longer and it has a lot of legacy syntaxes and ideologies to shed compared to react or vue. But ember is trying to stay in the new. But will that be enough to keep ember alive, only time will tell.

  • Code locality - agree with you. No comments.

  • SSR - fastboot is not as easy as other SSR implementations in vue/react. Needs more configuration. But it's possible to get it to work properly with time. And all devs should always test code locally with SSR enabled. Which should be fairly easy as the ember Dev tolling comes with support for it. Just an env variable to control it.

  • Syntax - no arguments. It's a pain to work with. I look at react and vue template conditional Syntax and ability to use normal JavaScript in templates longingly every time I need to write a condition in a template in ember.

In my opinion, I think doing a full rewrite may end up doing more bad than good. Instead we could give ember octane a go.
  • Go through our list of addons, see if we really need something. if not remove it.
  • Upgrade to 3.15
  • Use ember-auto-import. Use dynamic imports for third parts imports where ever possible to reduce asset size.
  • Switch to glimmer components and angle-bracket syntax. That brings us more in line with the latest js-style components and less of ember specific esoteric style of writing components. (We're still stuck with weird template syntaxes such as ifs and unless though)
  • Embroider seems to be right around the corner. currently in beta stage. That would solve our build system woes bringing in webpack which most devs would be familiar with.
  • Checkout if moving away from JSON API would make things easier on the API (and better usability within android apps) front. We will need to also write an adapter for ember-data to resolve relationships correctly if we're moving away from JSON API.
Areeb Jamal
@iamareebjamal
I think doing a full rewrite may end up doing more bad than good. Instead we could give ember octane a go
I completely agree
Ember simple auth redirect after login
This was fixed recently after a long time in a PR. Let's see if it is working correclty, and if it doesn't, we'll discuss
What did you want to replace dynamically in the environment?
Let's say I have built a docker image for frontend, now I need to define API_HOST, GOOGLE_API_KEY in environment variables and it should run using those options. There is no option for that currently. A docker image built for api.eventyay.com will only work for that. It diminishes the use of docker images of frontend as everyone has to build their own image again. I solved it recently but the solution was to implement a partial JS parser and it is very crude - fossasia/open-event-frontend#3736 fossasia/open-event-frontend#3542
Areeb Jamal
@iamareebjamal
For SSR in local environment, Just an env variable to control it.
It did not work previously I tried it. Have to run it using node scripts/fastboot-server.js. Maybe if you can take a look at it, it'd be great
Niranjan Rajendran
@niranjan94

Let's say I have built a docker image for frontend, now I need to define API_HOST, GOOGLE_API_KEY in environment variables and it should run using those options. There is no option for that currently. A docker image built for api.eventyay.com will only work for that. It diminishes the use of docker images of frontend as everyone has to build their own image again. I solved it recently but the solution was to implement a partial JS parser and it is very crude - fossasia/open-event-frontend#3736 fossasia/open-event-frontend#3542

@iamareebjamal checkout fossasia/open-event-frontend#3825 for this

Areeb Jamal
@iamareebjamal
Thanks a lot. Will do
Mario Behling
@mariobehling
:thumbsup:
Kush Trivedi
@kushthedude

I think doing a full rewrite may end up doing more bad than good. Instead we could give ember octane a go

Completely agreed with this, Rewriting a production-deployed app may cause more bad than good.

CHAITANYA
@Chaitanyassr
@iamareebjamal yes.
Kush Trivedi
@kushthedude
@mariobehling @hpdang V1.9 for eventyay will be live soon :tada: :tada: . Some of the major changes :
  • Admin can choose Promoted Events from the Admin Event Dashboard.
  • Bugs related to Session/Speaker Addition/Editing have been fixed.
  • Addition of AgeGroup for Attendee Form.
  • User are now redirected to CFS page after login, Also many of the fastboot crashes have been handled.
  • Access Code link has been fixed.
    And many more bug fixes!
Mario Behling
@mariobehling
OK, cool. Please let us know when it is live.
Areeb Jamal
@iamareebjamal
v1.9 live on frontend
Mario Behling
@mariobehling

@iamareebjamal Great. Most things I tested so far work much better. Thank you!

One thing is currently showing an error: Exporting sessions "CSV Export has failed."

Areeb Jamal
@iamareebjamal
Will check what's the issue.
Mario Behling
@mariobehling
:thumbsup:
Mohit Maroliya
@mohitm15
@kushthedude I found no validation on the password in reset -password.js ? Is that need correction or intentional;
Let me know so that I can take appropriate action
Kush Trivedi
@kushthedude
correction needed
Mohit Maroliya
@mohitm15
okay n thnks!
Do the icon for hide and unhide password is also needed to be get added there
@kushthedude
Kush Trivedi
@kushthedude
Add the toggle icon as well as the field for confirming password
Mohit Maroliya
@mohitm15
sure @kushthedude
Mohit Maroliya
@mohitm15
mohitm15/open-event-frontend@9f3d3d5 Can anyone confirm this? because I did not get any changes on that window?