Consider a Javascript Framework for Account/Server Panels

[george-e-shaw-iv]

Severity level (1-10):

1

Files/Directories Involved:

account/ server/document_root/

Description:

The HTML files for these interfaces are huge and use a lot of simple bootstrap modals along with Javascript XMLHttpRequests, so its just really basic stuff right now and probably really resource heavy/hard to edit. I would think it would make sense to migrate toward using either react or angular to make them into proper single page web applications.

Personal Comments:

[ghost]

Hi @george-e-shaw-iv

I saw your project on the Moz Sprint repo, and checked it out. Right now I'm trying to help out with getting a v2 custom elements lib worked out. ATM the only issue that's huge I've found is that it won't run on any(ANY!!!) browser on an ipad for some reason, here is a link to the issue => https://github.com/x-tag/core/issues/197

There were previous issues with it but they got worked out. It maybe the way to go if your building for Linux, also V1 is still a good solution esp for single page web apps.

Check out x-tag => http://x-tag.github.io/

[george-e-shaw-iv]

@KipOmaha I'm definitely open to any sort of progressive framework as long as I can make sure that it will stay up to date. Does x-tag have a bright future in the sense that it won't be abandoned as an open source project?

[ghost]

I'm not sure, it started out in the hands of Mozilla and is a Microsoft project currently. It relies on Google's web components javascript library, so as far as big names throwing time or effort into it, they are their.

The v2 version has support for more ES6 standards so their is a push to update it, so that's a good sign. Projects like yours running it and helping out with support is good too as always, to aid in keeping a project going.

[ShawnMilo]

Frameworks are intrusive. If React is used, it's now a React application. Same for Angular. Making a change later will be painful if the framework is no longer desired or a better one is found.

Framework upgrades will bring backwards-incompatible issues that will either will take significant time and effort to fix or (more likely) will be put off for a bit too long and eventually leave security or compatibility issues.

A few members of my team at work recently evaluated several options. Despite having more experience with Angular and React, they chose to go with Vue.js because it's not intrusive. It can be used as-needed without rewriting an entire application to meet the framework's requirements. I'm not saying Vue is the answer here (I'm a back-end guy, not front-end), but please take these ideas into consideration. If you're interested in hearing more about my opinions on this matter (which I don't expect), you can listen to a recent podcast we did on this very topic.

Happy Wednesday!

[ghost]

@ShawnMilo thanks for piping in. Personally I have projects that can use vue.js after taking a look at it for a moment.

Vue.js sounds promising but still think that x-tag's or any component based system work well especially with the help of frameworks and libraries like vue.js. That's why I personally like x-tag's.

[george-e-shaw-iv]

@ShawnMilo I've actually considered Vue.js because of some talks that I've attended talking about it. I'm pretty sure its actually more performant that react/angular, on top of those other reasons you've given. I'm also not a front-end guy, but I might end up trying to learn some front-end, using this as a learning experience.

[ShawnMilo]

Cool, glad to help! I don't do any front-end myself, but I went through the basics in the vue.js documentation and I liked the simplicity. In the end (in my opinion) the single most important thing in software development is maintainability. Everything else -- clean code, tests, DRY, YAGNI, etc. -- is all in service to maintainability (the ability to make changes to add features, refactor, and fix bugs with the minimum of stress and fear). Frameworks are the antithesis of maintainability, so I speak out against them at every opportunity. :sunglasses:

[george-e-shaw-iv]

Yeah you're completely right @ShawnMilo , and that's one of the reasons I tried my best to refrain from using any unnecessary open source packages as dependencies. Thank you for your input and help on the issue!

[ghost]

@george-e-shaw-iv, @all Probably a bit late but was just looking at TypeScript, their seems to be a lot of mixed feelings about this language. Mostly devs on the negative side are saying that the project itself is an experiment and belongs in a dev lab still.

My personal opinion is that Typescript has the right idea especially if your clients/company/ect are using MS workstations or your users are using anything from android to safari. Javascript itself is a fairly weak language its portability and support it enjoys is what keeps it alive, so Typescript accepting this fact and trying to build on it and improve its support for the future is a good direction.

That being said do you feel Typescript has a future?

Here is a link to Anders VLOG => https://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript

I suggest reading and listening, I am.

[ShawnMilo]

I'm admittedly less qualified to weigh in on TypeScript than the topic of frameworks (maybe it's off-topic for this thread?), but my opinion on TypeScript is cautiously enthusiastic. I've learned it a bit and a trusted colleague of mine worked with it for about a year and is very complimentary (and he's usually a back-end guy). It adds some Go-like enforcement of correctness and some Python-like class syntax, and is much less painful to work with than the venerable vanilla.js. Vue.js does support Type Script, if that matters.

I wouldn't worry about TypeScript being deprecated, considering it's from Microsoft but widely adopted by other huge standards-makers (including Google). It's not going to go the way of CoffeeScript any time soon.

[ghost]

Thanks @ShawnMilo, no I didn't know vue.js had support I wonder how well it performs? In any case you've been helpful @ShawnMilo, now I won't have to look for an alt to angular typescript. I'm definitely looking forward to hacking some Typescript definitions. If you want I could give you an invite to a repo with some testing resources when I get it setup. Same for you to @george-e-shaw-iv

[ghost]

Hello all,

interesting discussion. I really like gPanel for its simplicity in both code base size and technology stack (plane Go, HTML, CSS and JS, no complicated frameworks or additional languages). This way it is very transparent and easy to understand and modify for anybody with just a basic knowledge of programming which is really cool!

I saw a number of projects that wanted to make their UI more "modern" by implementing it in a JS framework like Angular or React. Unfortunately the results was as @ShawnMilo pointed out, that they basically created another application out of it that was neither simple nor easy to modify/maintain for anybody who is not expert in it...

Having whole UI in just 2 HTML files seem pretty simple to me + using only Bootstrap is a thing which we can build upon... But if you really want to change it, what abut using a Golang native JS framework like GopherJS (https://github.com/gopherjs/gopherjs)? It will allow us keeping the application simple and homogeneous while getting most of the "Bells and whistles" of a JS frameworks...