Towards a better UI/UX experience for developers

ui
javascript

(Robert Down, BSN, RN) #1

I’ve been looking at the state of front-end development lately, more so than in the past. Over the last years I have become frustrated by the rapidly-changing ways of javascript. It seems every few months there’s another front-end framework to end them all (React, Angular, Vue, Whatever-comes-next). And I’ve wrestled with how to take our JS into the modern world.

As it stands, we now have a relatively stable release-cycle for ECMAScript and that helps clear some of the fog. We can now safely begin writing our JS using ES2018 and allow a tool like Babel to either polyfill or compile down to ES5 for older browsers. We are even seeing ways of compiling an ES5 version of your script and only loading if it if needed, if the browsers can support ES2018 it’ll just get ES2018.

I think native web components are likely stable enough we can now begin using them instead of relying on a React-style setup. Libraries like polymer have basically said, “We just want people to use native web components and understand our product will essentially just map to that and eventually we’ll be obsolete” which is good to hear.

What does this mean for the next steps of our development? Well, I integrated the PHP templater Twig and you can use it today, it’s been there for a while now. But I think as we move forward we should rely on native-HTML and ES.Next for the bulk of our UI. I think the days of the Header class (which I wrote) are likely coming to an end. We shouldn’t be writing complex classes that render HTML in PHP, they should be written as web components and javascript.

I think in the next 3 years we start to see the codebase truly begin to split the server-side code from the client-side code. This will make maintenance easier, allow cleaner code, faster iterations, and better prepare us to handle FHIR and in-patient use-cases.

Talk is cheap though, and so I’ll likely write up a module using the ideas here. Something simple that devs can look at and better understand. I also imagine we’ll end up with our typical Apache/Nginx based PHP server as well as a node server in the coming years.

< /novel >


(Dan Ehrlich) #2

Robert:

Two years ago I was really into Javascript. I remember going on vacation for 3 weeks and coming back to feeling like I was totally lost / not in the community anymore, it was moving that fast. Thankfully that’s died down and I think you’re right, the ecosystem is much more stable.

So instead of doing PHP + Twig, you are thinking about doing PHP + ES6/Web Components/Polymer?

That sounds good. If anything the code base could use more Javscript. It’s not server side code so in a way more secure. Also it would allow more people to work on the codebase (say those who only know javascript but want to help).

Thank you for writing.


(Robert Down, BSN, RN) #3

Yes, my vision is PHP serving data and all the UI is handled in ES6+/Web Components/Polymer. I think no longer using PHP for anything render related will go a long way towards helping modernize the code. New devs are often pushed away by just how chaotic and disorganized our code is. That’s another thing I’m working to fix, but it’s tricky to say the least. Plus, the messier a codebase the easier a vulnerability can exist.


(Jerry P) #4

I think this is something everybody should be able to get on board.