React, or VanillaJS+TypeScript+CustomElements?

[dschaefer]

I did have a start of this using React because that's what I was familiar with and it seemed a reasonable framework to pick. I have been hesitant to pick any framework since we really need to look 10 years ahead and make sure we're future proof.

I also started running into issues with the architecture of React versus what I'm used to with Eclipse SWT and it's event-based model. React is good at generating UI from a data model, but I'm not sure that's what the foundation of an IDE is. React may be interesting for some IDE views that are more data centric, and that can be done with the the help of Chromium's webview.

Over the last week, I've switched to using plain VanillaJS and TypeScript and am pretty happy with it. It's forced me to learn CSS which isn't as scary as I thought. I am also using custom elements from the Web Components spec to componentize the UI so I have a similar architecture to what I had with React. I will be adding custom events for higher level notifications like a request to open a file in the editor. We'll see how that works out.

Once I get back to where I was with React, I'd like to make the switch and remove the React code. I'd love to hear from others following this project on whether that's the right move or not. Thanks!

[dschaefer]

BTW, at the moment, the React code is in src and the new stuff is in src2.

[colemarkham]

Out of curiosity, why did you make src2 instead of creating a git branch?

[dschaefer]

Mainly because I wanted to run both at the same time so I could compare the results in Chrome Dev Tools so I could figure out the CSS 'src' was giving me.

And really, for such an early prototype, I was only using git to save my work on the server so I didn't lose it and to show people what I had in mind. Didn't really cross my mind to branch. Will do better next time :)

[colemarkham]

Honestly that has always been one of my issues with git, but I think the multiple worktree support is finally stable now. It lets you checkout multiple branches to different working copies so you could run them in parallel without having to clone the repo twice. I think JGit/EGit supports it now.

[ccampo]

About React vs VanilaJS and else. For me the code maintainer makes these kind of decisions (as you are doing right now) so I am trying to make a point but its up to you to decide at the end.

Reason #1 what makes React more interesting for me is that it is more likely to attract people to contribute. (vs VanillaJS which I really had to google). If you look at "what-is-the-hype" diagrams that React is usually no 1.

2 you say that an IDE is maybe not data model driven. I think E4 demonstrates how that is not true. The whole UI of the IDE is an EMF model (and seriously as much as I dislike EMF and not use it) and that means you could do the same with React. Have a UI model and render it with React components. It also seems a nice setup where people can add there own React components and add them to the UI. Thats to me is the strongest argument that a ui-model-driving approach can work. E4 is pretty sure a very large model that covers all aspect of an IDE. Also other people have created there own model and had it rendered by E4 and added custom renderers. Maybe naive but it feels like you could do exactly the same with React.

3 React has a large community and lot of moment and will likely also be around in a few years. VanillaJS who knows.

But again just the things that jumped into my mind when I heard that you wanted to remove React. Its still up to you to decide.

If you are unhappy with React (and you might be since you are taking the effort to remove it) maybe a mixed model would work where the core is React-free but you can add components (a view) that is rendered with React easily.

[dschaefer]

Thanks Christian, that's exactly the feedback I'm looking for. You reminded me why I started with React to begin with. React is very popular and will bring more eyes to the project that Vanilla.

BTW, VanillaJS is simply JavaScript using the HTML DOM APIs. It'll be around a long time but it is taking me a bit longer to do things.

I think TypeScript is important, though Flow was helping me with type-checking React. I'll give React + TypeScript a try too before making a decision there. Though from the discussion on the React page they are really pushing people more towards Flow than TypeScript.

As I mentioned in my blog, one person, or one company can't do this alone. It needs to be a community effort and decisions need to be made for the good of the community. I won't rush to decide quite yet.

[dschaefer]

BTW, the main problem I ran into was how to handle the open editor action. In React, you change the state. Is the list of open editors the state? That just seems weird. In Eclipse One, we dealt with that using a command framework. Maybe there's something similar we can do with React.

[colemarkham]

It may be best to avoid the term VanillaJS when having a serious discussion since the term was invented as a joke. Best to use something like "raw JS", "standard JS", or "plain JS". Even "vanilla JS" would indicate that it's not a library that people should go research.

I think the whole point of not using React is that you don't want to make a design decision based on what is the current top framework. If history has told us anything, that will change in a few months or years. That said, if you don't pick a framework, you'll just end up writing your own with all of the disadvantages that come along with that

[dschaefer]

Good point Cole. Yeah, even with the little I've done, I've started to see the need for common things which will likely result in a framework.

And as long as we follow a good component model, which React promotes, if we do need to switch to plain HTML5, it shouldn't be too difficult to convert those components to Web Components.

[ccampo]

oh...so when you said VanillaJS you actually meant plain JS and you dont mean http://vanilla-js.com/ :-) ok that was missleading. I agree with Doug that you need something and a good component model and then the technology can be swapped maybe later.

I am always willing to contribute to the discussion for this project. Not yet too sure if my time allows code but we will see. (our CEO discovered the project today and pinged me so your marketing is good :-) )

[colemarkham]

http://vanilla-js.com/ is the source of the joke. It is cleverly disguised though.

[dschaefer]

I've actually seen the term used in places. So while the page is a joke the term actually fits nicely. :).

And, yeah, my simple blog post and a few tweets have a lot of people talking. Didn't take much, but it's a sign that people are interested in where the idea goes. I think we can get serious about it once I get to the self hosting phase. It's still a home time project until I get some free time at work in March.

[dschaefer]

Anyway, back to the issue at hand, I just looked at the React code again and it really has a lot of issues. The Monaco integration is also problematic. Where to I set the model (text and language)? Doing it on the render() method as I do now seems wrong.

I'll start working on the open-file event and see how it works with the custom element approach (ok, I won't call it VanillaJS any more :) ).

[dschaefer]

That was pretty quick, but have the open file working. The HTML DOM APIs are pretty easy to work with. You can see what I did here: https://github.com/dschaefer/eclipse-two/commit/5e804ebc66bcf18b0e9174078c7808d52fe4940c

I'm sure this isn't the best thing we can do architecturally using custom events and elements, but I've been pretty productive with it.

[njbartlett]

The Web Components model based on real W3C specs is where my interest lies, and I think is the best future-proof solution versus any framework such as React or Angular, which go in and out of fashion with astonishing speed.

Unfortunately there are gaps in the browser implementation of these specs are the moment but I think that's more a problem for people developing cross-browser sites. For Electron or similar, you have a high degree of control over the features available.

[ccampo]

I think Web Components could be a good standard or API or integration point to agree on where different vendors could plug in their "piece" into Eclipse Two. Still I also think that Web Components could be built using React or Angular or else. But I guess thats what you meant anyway (just to be sure).

[dschaefer]

Thanks Neil, yeah, going Electron with Chromium being the only browser to worry about allowed me to even consider custom elements and other Chromium features. Webview is another one. It allows you to run a component in it's own rendering process is another one that will allow different plug-ins to use the frameworks of their choice and render into different parts of the IDE. I think we could get to the best of all worlds.

[dschaefer]

OK, closing this. Going to do the switch to src2 and friends and remove React. I'll also update the architecture guide to describe what I'm doing.