Hey billconan, great question! Right now we are using Text renderer provided by Pixi.js, which uses browser api to render font to canvas and then stores the outcome as texture.
We are working towards integrating C / Rust libraries for font rendering in a nearby future to increase performance and decrease memory usage.
If you are looking for libraries you might want to check harfbuzz / freefont, cosmic-text, swash or fontations project.
That’s not what I understood from the post. The discussion about OOP was the main part and the frustrating library was just an example.
The main point, I think, was that it’s easier to understand programs written in a functional way - data and function operating on that data, rather than understanding OOP code - classes holding data and methods, with interactions between different classes. Most python code is OOP based thus authors dislike for Python.
So that anyone could create a nice UI by drag’n’drop, without writting a single line of CSS. It also works as a design system, so companies can create their own component library quickly.
After 3 years of trial and error, finally getting really close to beta version.
If you don't have to support IE11, there has been a very interesting trend of JS Proxy based state managers (immer, react-easy-state, overmind, etc.). It reduces the boilerplate compared to redux while giving basically the same architecture. I have been using my own implementation, because react-easy-state did not work well with styled components (https://github.com/UgnisSoftware/lape), while I was building https://github.com/UgnisSoftware/Ugnis if you want to see this approach in use.
You are definitely not out of luck, IE6 is not that bad, older React versions even supported it. You just need more shims and more babel plugins, so get someone who knows babel/ES3 well. Add the console shim and start working error by error.
Also, you should ask this in a JS community, because in HN you will get way too generic answers.
I think Bubble is great and we need more people experimenting with visual programming!
We have been working on a visual tool[0] for ourselves and the development speed gains are incredible. Hopefully, there will be more non-text based programming environments.
> I mean, really, come on -- that's not realistic in any reality.
Huh? Most projects use a single framework in a project, sometimes two if they are migrating. If I had multiple frameworks in my project, sharing components between them would be the least of my problems.
> standardizing "custom DOM" will eventually get us to a standard slightly above raw HTML
I understand this sentiment, but DOM is irrelevant to front-end work right now. DOM is just a render target for frameworks, making DOM smarter changes nothing.
> Yes! I often have to work with multiple frameworks.
There is an easier solution to this than Web Components - using a single framework. Unless you are a consultant same as me, than we can only blame ourselves for having to deal with this.
> My point is: The fact that anyone can write them means that there'll be a sort of evolutionary competition
That's not what happened with React component libs (material-ui, react-toolbox, etc.) - none of them has "won", all of them are pretty similar in quality. I would say that quality of a component is less important than how easy it is to adapt them to your business needs is.
My point is that having more ways to create a component is irrelevant - Framework churn existed not because we couldn't share components, but because writing components and managing state was awful. Web Components are still terrible at both of these things.
The good thing is that there hasn't been any new JS innovations in three years since React, Cycle, Elm, ClojureScript boom. And I would claim that there is not going to be because we are limited by the textual representation of our programming language. So the Framework churn ended not because everything is perfect, but because we couldn't make UI development better.
Not really, it was used as a library to make JS work consistently across browsers and add missing features like querySelector and ajax fetch. But it had no opinion on how you should structure your app.
Angular, Backbone and Ember is from the same post-jQuery era when talks about Web components started.
> Being standardized, i.e. any old framework that can work with the DOM can with them
But does a developer really care that it's possible to use the same component in different frameworks, when you need it to work with just one (yours)?
I think the biggest fallacy is that people expect a technology to appear where you could just drop the component and it would work perfectly. From my experience, that will never happen - external component libraries are 90% what you need and 10% of hacking around missing features. The easier it is to safely and predictable hack the last 10% the better the framework/component library is.
Web Components provide nothing that help in UI development:
Helps manage multiple components state? Nope.
Provide a declarative API for components? Nope, imperative - the one we are trying to get away from.
Prevent CSS from affecting components? Cool, or I could just not write global styles, use BEM or CSS modules.
Easy to share components? NPM still works just fine for that.
> It's a massive waste of resources that M > 1
Agreed, that's something I thought a lot about. So I have created a cross-framework visual component editor - one component exports to many frameworks:
https://github.com/UgnisSoftware/ugnis
We were discussing Web Components at the time the Angular was getting popular and before React was even released.
> for non-browser developers to ... have those components work just like native elements
Honest question, how do Web Components help native developers in any way? Because from UI devs perspective, Web Components are useful only in a single edge case - when you must make sure than it's impossible for Cascading Style Sheets to cascade to your component.
For a developer, Web components are solving problems that almost no one has or that were solved better by React and Vue.
I had the same reaction because it's ridiculous to claim that Web Components can stop the Framework Churn when they predate most of the frameworks and didn't stop the churn from happening.
There are fundamental shifts happening in UI development, but Web Components are definitely not it.
Maybe test it locally with a split screen mode? Or lower your coding standards? It takes a day max to start a node server with websockets (he did that in the end anyway).
The biggest mistake I think was that the author "personally prefer strategies (such as Civilization) over action/arcade type of games", but decided to build a multiplayer game. With no experience. Now that is a recipe for a disaster.
I don't think that years of experience has anything to do with liking vue or react. I know how you feel, because my colleague had similar thoughts on React, he even created something very similar to vue a few years before vue(jade+css+js in one file). While I just use pure virtual-dom (no jsx) and almost nothing else.
The way you put it, some people look for patterns and elegance, while some look for simplicity (no special v-bind or v-if), modularity and deletability. There is nothing more senior about one way or the other, just different personal preferences.
Vello has been a big inspiration and source of knowledge for my own webgpu text renderer, thank you for that!