Aria CMS [Front-end built using React]

Page 2 of 2 FirstFirst 12
Results 16 to 21 of 21
  1. #16
    Member Badbygger is offline
    MemberRank
    Aug 2007 Join Date
    60Posts

    Re: Aria CMS [Front-end built using React]


    RaGEZONE Recommends

    RaGEZONE Recommends

    I'm having some problems viewing this on a mobile device, look at the attachment.
    Let me know if you make some changes to this, maybe i'll use it.
    Spoiler:



    Sendt fra min ONEPLUS A3003 med Tapatalk

  2. #17
    Interesting... SharpAceX is offline
    SubscriberRank
    Oct 2008 Join Date
    1,926Posts

    Re: Aria CMS [Front-end built using React]

    Quote Originally Posted by Badbygger View Post
    I'm having some problems viewing this on a mobile device, look at the attachment.
    Let me know if you make some changes to this, maybe i'll use it.
    Spoiler:



    Sendt fra min ONEPLUS A3003 med Tapatalk
    I very recently added responsive CSS, it's on Github but not deployed live. @holthelper should be able to deploy the latest soon.

    Looks like this on an iPhone 6

  3. #18
    MMO Supervisor Biesmen is offline
    SupervisorRank
    Apr 2007 Join Date
    2,088Posts

    Re: Aria CMS [Front-end built using React]

    Is it a personal preference to create a whole CMS using only React JS or is it proven creating sites using React JS, Angular, Knockout, etc. Is loading way faster than a normal website?

    Personally I really do not see any benefits in creating a page which is 100% being generated by JavaScript. First of all, JavaScript will have to initialize every single element. It sounds way faster to use a normal template file (such as HTML, PHTML, PHP) and have your elements initialized in those files. Secondly, if you create a whole website using only JS, you'd have to use AJAX requests and you will have to return the data in some format (JSON, e.g) which you will re-format to readable content. All this combined looks like a longer process to me, because a request will be sent to another file in a certain order. So it'll have to establish a connection to your local files (which probably goes extremely fast) multiple times in a certain order.

    The only benefits which I see is; The page loads faster because your browser isn't waiting for the DOM to be ready. But the downside is: everything is being loaded at real-time, so theoretically there are more processes to gather the data from your database and you'll have to wait until the elements pop-up.

    I do see a benefit in using these JS Libraries for data which is changing frequently. For example, the player count could be loaded into the website using these libraries to refresh the count without refreshing the page, in this case.

    Maybe I'm wrong, I do not have an extreme amount of knowledge regarding these JS Libraries. I'm extremely interested in this, though.
    Last edited by Biesmen; 2 Weeks Ago at 11:41 AM.
    Forum Rules | Account Support | Subscribe
    RaGEZONE Facebook

    "Make sure your worst enemy doesn't live between your two ears"
    Laird Hamilton

  4. #19
    Retired maritnmine is offline
    True MemberRank
    May 2007 Join Date
    North KoreaLocation
    1,088Posts

    Re: Aria CMS [Front-end built using React]

    Quote Originally Posted by Biesmen View Post
    Is it a personal preference to create a whole CMS using only React JS or is it proven creating sites using React JS, Angular, Knockout, etc. Is loading way faster than a normal website?

    Personally I really do not see any benefits in creating a page which is 100% being generated by JavaScript. First of all, JavaScript will have to initialize every single element. It sounds way faster to use a normal template file (such as HTML, PHTML, PHP) and have your elements initialized in those files. Secondly, if you create a whole website using only JS, you'd have to use AJAX requests and you will have to return the data in some format (JSON, e.g) which you will re-format to readable content. All this combined looks like a longer process to me, because a request will be sent to another file in a certain order. So it'll have to establish a connection to your local files (which probably goes extremely fast) multiple times in a certain order.

    The only benefits which I see is; The page loads faster because your browser isn't waiting for the DOM to be ready. But the downside is: everything is being loaded at real-time, so theoretically there are more processes to gather the data from your database and you'll have to wait until the elements pop-up.

    I do see a benefit in using these JS Libraries for data which is changing frequently. For example, the player count could be loaded into the website using these libraries to refresh the count without refreshing the page, in this case.

    Maybe I'm wrong, I do not have an extreme amount of knowledge regarding these JS Libraries. I'm extremely interested in this, though.
    What specific framework you chose for you SPA (single page application) could depend on many factors. The most reasonable would be to chose what you are most familiar with and what fits best for your system requirements, but most chose to go with whatever the SPA JavaScript hype train says is the framework to use.

    Some brief history on the topic: Two years ago, AngularJS (then named Angular) was the framework to use for SPAs. Google, being the owner of Angular then decided to re-do the entire framework and they made Angular 2. This relied on TypeScript which was then transpiled (converted or compiled) to JavaScript before the user entered the page. Additionally, it broke all backwards compatibility and people had to start from scratch with their applications if they wanted to go with Angular 2. This made many people switch to React (owned by Facebook). On top of it all, they decided to name Angular 2 for Angular, and Angular 1 for AngularJS. These three frameworks are vastly different and has quite some learning curve to get productive with. If you are familiar with a traditional PhP stack with jQuery and aJax, it is going to take a lot of effort just to learn the tooling these frameworks require. Then the question is: what will be the next framework on the hype train? To be honest, I haven't really bothered looking into React after having learned AngularJS and some Angular (see how wrong that sounds?).

    There are a lot of benefits from using this architecture. Yes, it requires more from the developer and it is a bit more to learn and set up, but in the end you have more or less written an entire frontend application that relies on some sort of API (if you have done things right). Why is this a good thing? It means you can cache the entire front-end very easily through CDNs so it becomes super fast to load (you still have the front-end compilation time, which I will come back to later), the entire front-end application can be easily replaced without changing anything in the back-end API. Architecturally speaking, you get a really clear separation of concerns compared to traditional web sites, where previously everything was floating together. Now you can have a back-end guy working on the back-end, while this fancy NodeJS hipster is working on the front-end and the only information they need to exchange is how the back-end API works. Now your page is split up into a front-end and a back-end you can also implement other applications that rely on the same functionality already being exposed through the back-end API. Although this specific point doesn't make much sense for Habbo, it is one of the factors making people embrace this architecture. Today, web applications are often service-oriented. This means (for example for Habbo), there is some Habbo service that other applications can consume. For example a CMS front-end in either Angular or PhP (yes, you can have a front-end in PhP still being rendered on some server, but mostly resource constrained people like @NoBrain does this), or a smart tv app that notifies you when your online Habbo girlfriend messages you.

    To get back from architecture to one of the things you mentioned: Loading time. Conceptually speaking, the application would become easier to load over time. First time, the static assets for the SPA would get cached. Then there are the requests for the different kinds of data that has to be displayed. Although you can easily do parallel requests and multiplexing with HTTP 2, there is indeed some transportation overhead from the granular requests that is sent compared to one big HTML document. Then you have the compilation time. This entirely depends on the application and framework you are using. I very often complain Messenger for Windows (which is implemented in some Electron package) is taking more time to start than Visual Studio Enterprise because of the boostrapping with the different JavaScript crap they require to run. But if you are doing it right, e.g. through lazy loading, the page load isn't that bad. In the end, if you are doing things right, users see a far more responsive web-page as their browsers doesn't reload the entire DOM at each page load, but rather swaps the relevant elements. This makes life much easier for resource constrained devices (e.g. smartphones and slow-ass laptops).

    Off-topic:
    Can we soon fucking fix that the page doesn't fucking reload after some time you have been writing? I basically had to rewrite half of this post because of this issue and I would have had to rewrite 2/3rd of it if I didn't copy the text each minute.

  5. #20
    Infraction Baɴɴed holthelper is offline
    Alpha MaleRank
    Apr 2008 Join Date
    1,769Posts

    Re: Aria CMS [Front-end built using React]

    thanks for the history lesson

    if you have created a road map of how thing will be structured back-end to be displayed, the front-end can use that road map as a template so your not reliant on one another to get testing done.

    the benefit of having an api back-end is so that if you decide you hate the design of the front-end you can hot swap it for a new design following the same ajax calls to the back end.

    there is no point in fighting which library is better. each has their own pros/cons.

    tbh we did this site cause maplebit is old and wanted to make a superior site using react
    why did god curse us with the abilities to make search engines but not give us the knowledge on how to use them?

    [PHP][MapleStory] v142 GD Character Image Display - Link
    [PHP] Image to HTML - Link

    Sabe.io - Learn HTML, CSS, JavaScript and more! - Alans a ©uck

  6. #21
    Interesting... SharpAceX is offline
    SubscriberRank
    Oct 2008 Join Date
    1,926Posts

    Re: Aria CMS [Front-end built using React]

    Quote Originally Posted by Biesmen View Post
    Is it a personal preference to create a whole CMS using only React JS or is it proven creating sites using React JS, Angular, Knockout, etc. Is loading way faster than a normal website?

    Personally I really do not see any benefits in creating a page which is 100% being generated by JavaScript. First of all, JavaScript will have to initialize every single element. It sounds way faster to use a normal template file (such as HTML, PHTML, PHP) and have your elements initialized in those files. Secondly, if you create a whole website using only JS, you'd have to use AJAX requests and you will have to return the data in some format (JSON, e.g) which you will re-format to readable content. All this combined looks like a longer process to me, because a request will be sent to another file in a certain order. So it'll have to establish a connection to your local files (which probably goes extremely fast) multiple times in a certain order.

    The only benefits which I see is; The page loads faster because your browser isn't waiting for the DOM to be ready. But the downside is: everything is being loaded at real-time, so theoretically there are more processes to gather the data from your database and you'll have to wait until the elements pop-up.

    I do see a benefit in using these JS Libraries for data which is changing frequently. For example, the player count could be loaded into the website using these libraries to refresh the count without refreshing the page, in this case.

    Maybe I'm wrong, I do not have an extreme amount of knowledge regarding these JS Libraries. I'm extremely interested in this, though.
    With React (and Angular, Vue, -insert this week's new JS library here), you can separate the front end and back end as long as both agree to the same API contract. I did the front end, and @holthelper did the back end and after we agreed upon an API that satisfied the features we wanted the CMS to support, we went to work separately (literally separate github repos, front end is public, back end is private).

    In a traditional CMS like MapleBit, the two are extremely tied together which makes further iteration a lot harder. I could reskin Aria on the fly, and @holthelper can do optimizations or even change how he returns data entirely, and neither would even need to be informed of the other's decisions.




Page 2 of 2 FirstFirst 12

Advertisement