It seems to me that a lot of these projects aim to deliver really "good" apps: native UI, table output, etc… Results are great, but the UI building complexity also becomes quite high.
I think that's the wrong goal. The goal should be really simple definitions and ok quality apps. Simple JSON (or XML, don't care).
What you're saying is reasonable - for apps that don't need much UI. I wonder, though, how many real-world examples there are of apps that people have tried and failed to write in Javascript for this reason.
For those of us working on things where the UI requirements are more intensive, little progress has been made. Perhaps the pure JS stuff is getting more effort because it's more glamorous?
I disagree, I think UI programming is inherently quite simple. Especially with a paradigm like immediate-mode GUIs in my opinion. I believe the complexity comes from the fact that the DOM is a poor API for creating user interfaces, which ultimately inspired developers to create frameworks that work in a more “immediate-mode” style way.
Seriously, UI components are hard. Even a lowly button is difficult to get right, where ”right” means ”whatever smart people have converged on after 30 years of GUIs”. Anything more complex than a button is much much harder. There are a lot of things wrong with the whole ”web app” concept but to me maybe the most important is everybody trying to implement their UI widgets from scratch. And I say this as someone whose job used to be writing and maintaining a webapp UI framework.
Simple is subjective. I find the React way of making web UIs, where you just write a `render` function, way simpler than manually mutating existing UI widgets to match the data every time it changes. Or some weird manual data binding via model wrappers.
Maybe it's a tiny bit more code in the very beginning, but it becomes worth it very soon (as soon as you get past hello world pretty much).
That being said, we could always have better tooling, even for this paradigm.
I agree. There's a lack of quality, comprehensive UI libraries with ready-to-go, composable components. And the ones that do exist are tied to specific languages/frameworks like React.
This site screams at me don’t reinvent the wheel. The premise is that frameworks aren’t enough and developers are wasting time working too hard on things they already know.
When I hear things like this it begs the question: Exactly how easy do you need it to be? Should UI developers not be required any greater effort than copy/paste?
The reality is that most of the components the site proposes are already copy paste if you aren’t locked into a giant framework like React. Like some other comments have said there already is a common platform for building reusable UI components: web standards. The world surely doesn’t need a framework for riding on top of your framework.
You're spinning this as a positive thing, but the fact that a UI library needs its own build tool does not speak well to the state of front-end development.
Specifically the fact that we still don't have modules or widely-deployed http2 is what makes the build tool complexity necessary.
IMO because of the poor building blocks of web dev (we are trying to build applications with document markup) things that should be simple are too complicated. As an example say I give you an url that will respond with a json of an array of persons and you want to view this json in a table( just view some raw data, I do not want fancy themes or features).
So if we ask web developers how to solve the above problem we get at least 25 different ways to sovle with with JS , and some other 25 ways if we use some backend PHP,Python, Java. If you ask some Qt/Flex developers you will get the same response, Drag and drop the DataGrid and set the data
source to your data (and you get a ton of fancy features like adjustable columns, sorting,,,) and you don't have to install 300 dependencies.
I like this trend of moving back toward component based architecture. This has many similarities to Flutter, which for me has been a major breath of fresh air.
What still gets me: HTML/CSS/JS honestly just sucks for building complex apps. We have shoehorned tools that were meant for simple document display into doing our bidding, but at what cost? Hours and hours of developer agony. It doesn't need to be this hard. I like looking at one file written in one language to see both the look and behavior of an app. There has just been too much mental overhead. I like the way things are going and this framework is step forward.
A lot of devs tend to feel that UI is something trivial and “solved”. The unfortunate reality is that UI related code gravitates towards being extremely messy, convoluted and harder to change over time. It changes more than other types of code, is really hard to test properly and has to handle coordinating events firing from all over the place. Add to this JavaScript’s lack of types and past testing culture and you can see how creating a framework that fits your needs can become an appealing option.
People who set out to invent "better GUI tools" always eventually realize it's no the specifics of the programming language used to build them that's hard. It's high level things like state management.
iOS doesn't even have a stable answer to React, yet. The problem isn't JS/CSS.
comment not related to this article but more of a comment on data-driven user interfaces in general.
Building simplistic data driven UIs is (relatively) simple.
However, the issues arise as these get more complex.
Instead of just needing to understand a thing, you now need to understand the engine which builds that thing.
Looking at the react community where the new hotness is also data driven everything. UI definition (incl. CSS) all now detailed in JSON(which each original author custom builds), a lot of time without constraints(..'cos flexibility)
Building a data driven anything without having a very strong focus on debug-ability right from the get go is doomed to fail.
Agreed that a richer component library is badly needed. However, native apps can and do frequently invent new UI paradigms outside native (games in particular like to invent their own UIs, to varying degrees of success). Rather than poor imitations of native, I think web apps UIs would do well to draw their own cross-platform custom UI elements.
I don't believe that interoperable and usable web apps are a mere pipe dream, on desktop or mobile; can you imagine a world in which the open web never took root, and we were all stuck on AOL, Compuserve, and Prodigy? That's the current app ecosystem in a nutshell, and it's deeply suboptimal for both users and developers.
> 90% of what happens in a UI is ubiquitous across software. Buttons are clicked, images are positioned.
Thing is, there are countless fun ways to reimagine basics like "buttons are clicked, images are positioned". But that's not an app. And the long tail of everything you need in order to get from clicking buttons to a useful app is what makes a "real" language like JS (and in bigger projects TS) necessary.
Unfortunately a lot of what is presented is already enabled by JS, if you don't get hung up on things like do you separate tokens with spaces or dots.
Users don't want apps that paint their own widgets on a canvas. They want an environment that feels familiar, and that means working within the DOM. That's why Javascript won out over Java in the first place.
Nor do I see developers itching to depend on a project that hasn't been updated in over a year.
This looks a little overengineered to me. I'm always suspicious when I see a lot of 'envelope' code but no examples of code that actually does anything -- it reminds me of the guy who wrote a blog post about developing a sudoku solver with TDD who got to the point where had a few tests, but he never finished the app.
In this case we're seeing a few snippets of code, but no real sense of the structure of the app other than to see the particular way that 'main' gets called. In particular we get no information about how they've solved the difficult problems, such as how to organize complex asynchronous activities. (That's the scaling problem in Javascript, Flex, Silverlight, GWT, etc that used to keep me up at night)
I'm also a little disturbed that he wanted to write a DOM abstraction layer. Today there are many libraries such as dojo and jQuery that abstract away some of the worst problems with the DOM and with XHRs. Most of us could complain about the details of said libraries, but I'm very happy that other developers are doing the hard work to ensure browser compatibility, which is a real, not a hypothetical problem.
For many developers, UIs are often the most rewarding part of code to work on, the impact of making a change is immediate and obvious, and hey, pretty stuff is fun to make!
That said, the learning curve before HTML/CSS is "pain free" to develop with is huge. Especially compared to mobile frameworks, a native UI widget is easier to style and place on the screen. Also it'll probably keep rendering properly for the foreseeable future. (Or write a Windows app and it'll keep working until the end of time! :)
I've struggled a bit when I have to switch over to writing back end code for my startup. Some of it is mentally rewarding, writing a scheduling system for example, but other parts are just tedious, especially the CRUD stuff.
Of course worst of all was writing the scripts for and documenting how to do deployments. People who enjoy DevOps are kinda weird. ;)
As an aside, awhile back I threw together a simple WinForms app to do some trivial CRUD work in my DB. I have full Auth + Data Binding + UI working in ~2 hours. I hadn't used C# or Winforms in a few years. Porting that same UI over to the web took way too long. Getting the tooling up and running was a day! I hit a bug involving a release version of some NPM package that took hours to debug and then the framework I installed was using the globally installed version of Typescript instead of its own local version which took while to figure out and, well, a few more things like that. :/
I think what this person is talking about is simplicity in the actual UI pattern, and thinking about them. The problems you mention are JavaScript problems, not UI problems.
Have you ever tried to build a UI with Qt or JUCE?
I think that's the wrong goal. The goal should be really simple definitions and ok quality apps. Simple JSON (or XML, don't care).
reply