I came across Matthew Griffith’s Style Elements library1 years back, it made me rethink how to build and style user interface: thinking in terms of rows and columns was very intuitive to me compared to the CSS box/flex models. Style-Elements and then elm-ui offer a really small set of properties, and they are good enough for us to replace CSS for most part, this makes me think CSS is a bit over designed, or may be not designed at all, a hack gone too long.
But CSS is not the only thing I struggle with, there is also the complexity of three completely different language you have to learn to build any simple user interface today, HTML, CSS and JavaScript. You can do a lot with just HTML / CSS, especially if you are not building web-apps but web pages, but with just HTML / CSS its not possible to create re-usable components.
And Javascript is just too much (so much so that a lot of backend developers declare themselves incapable of building basic web interfaces).
Another problem that bugs me is the data representation / exchange languages: JSON/YML/CSV are too popular, and yet they leave a lot to desire, there is no way to define schema in any of them, writing them by hand is too cumbersome without programming editors, and then its just one more thing to learn on top of the three named above.
It always bugged me that this can not be the best we can do.
FTD is an attempt to take Griffith’s ideas, create a (hopefully) simple syntax, and create a unified language that replaces HTML/CSS/Javascript for user interface creation (think web pages, not web apps). A language that has first class data modelling capabilities2.
I would love to hear your thoughts about it.
PS: apologies for the back button bug, I have created a full stack web framework: Realm3, and it’s under a lot of flux right now.
This is an interesting idea, at least in theory. However, your asking the impossible: your proposing a completely new language for the web that negates the need for HTML/CSS/JS. The fundamental flaw with this proposal is propagating it. People aren't going to want to switch. People aren't going to want to completely rebuild every bit of existing web infrastructure that they run in FTD. And we haven't even gotten to everything that spits out and parses HTML/CSS/JS either -- you'd need to add support for all of that too in all of those products. You could build a transition layer -- a sort of transpiler -- but that'd be incredibly complicated and would most likely take you 5 years at minimum to develop. But maybe I'm misunderstanding your idea.
Also, how are JSON/YAML difficult to read or write without an IDE? They were designed to be readable. JSON is justa Python dictionary. You can't specify schemas in it but your not supposed to. If you want a schema-based data format, check out Apache Avro. Or XML (yuck).
Umm, not really. Consider this page for example that we have built using ftd: records, lists and loop. If you have to make that page in HTML/CSS/JS, its way more complex (you have to use all three first of all, and then you have to pick the JS framework, the CSS precompiler etc). You can learn entire FTD in an afternoon, less time you need to learn any of the JS frameworks out there. Non designers can learn FTD in a week (I have trained my designer, he did not HTML/CSS, and now he can replicate any website you give him, with basic event handling in an afternoon).
FTD is giving you power to do things. Its not to replace your "web apps", you won't built GMail using FTD. But your blog, homepage of most websites, basic data visualisation pages etc etc, can all be built with FTD with less work than the alternative.
And while its expressive: you can quickly create what you have in mind using FTD, it's also fast. We have very limited JS dependency (and that too only if you use event handling feature). The creates produces HTML with inlined CSS (we are working in cleaning up the HTML), and can be fully server rendered.
Even if you have JSON-Schema, authoring that JSON file by hand is painful compared to FTD. And in the same FTD you have defined the type and used it (FTD also supports -- import: foo, so you can organise things how you want to).
Which one would you want to author by hand?
And not just data and schema, you can define UI:
-- ftd.text: ref product.description
$loop$: products as product
size: 30
color: red
If I share one FTD file with you you get the schema, data and the UI.
Further consider a shopkeeper trying to create a static product catalog and show it on the website. Today that person is told, oh of course just learn HTML/CSS/JS/JSON/JSON-Schema etc etc. With FTD all they have to learn if FTD, which based on my experience teaching it a programmer can learn in an afternoon to a day, and a completely never even used HTML before person in a week or so.
If the aim is to generate HTML/CSS with FTD, and render it in a browser, the problem is that the generated HTML lacks semantics. In your example, it's only <div>, with no ARIA or other HTML5 features, useful for assistive technologies, responsiveness and robots.
Regarding clean HTML: this is very early release, we just got it working with event handling etc. Will be improving the generated HTML soon. Thanks for the feedback.
Also aim is to generate HTML among other backends: want to render FTD in terminal user TUI crate for example, or to PDF, native iOS/Android etc etc. Basically become a universal specification language.
I'm still very confused about the point of this. Requiring people to learn HTML and CSS and JS is the path to web dev. If you want to make a static catalog, all you have to do is use HTML and CSS -- you just won't have all the advanced things users will expect in modern websites. Not to mention the fact that most of the time, people don't write the entire site by hand -- they use web frameworks like Django, Flask, FastAPI, Rocket, etc. that greatly simplifies the development processes. How exactly are you going to make something that can even compare to HTML/CSS/JS/Web assembly within a practical amount of time that still allows you to then figure out some way to magically convince everybody to use your platform?
If this is for educational development then I'd see the appeal of making your own format, but what this sounds like is you trying to effectively replace an entire development stack with another, and that's practically impossible. Especially since if you want to do that, your going to have to implement every JS/web API. And that will be a very, very long and painful road.
From your post, to the website, to the project itself, my thoughts are the following:
a) It sounds like you're trying to get on board people who are frustrated with HTML / CSS / JS first and foremost. If that's the case, this particular forum might not represent your target audience very well (not at all, if you ask me). If you want feedback for your language from people who are into web-dev, hit the reddit or any other place where people who are in the trenches of typical web-development frustration and see what their feedback is. That will tell much more than thoughts of people prefer to dive deeper into much lower level work with their machines - which is what Rust was built to do.
b) Your pitch needs some work. You're assuming people are familiar with Matthew Griffith’s Style Elements or are willing to spend 20 minutes watching a talk they've never seen before and which they might not have any time or willingness to watch (which circles back into your assumptions about people's interest in Web Dev here), you're assuming they care about CSS, that they know Elm and that they share your preferences when it comes to some of their features. All before presenting them with a solution to a problem they might not care about at all.
Define the problems that your project solves. Identify people who are most likely frustrated with their problem. Get in front of those people. Clearly state the problem that they're having (expecting that they might not be aware of it, as people are creatures of habit and will gladly keep doing what they've done before if it worked for them) and present your solution, preferably in a sensually-arousing manner. There's nothing emotionally engaging about scrolling a website that doesn't work, talking about GitHub Pulls that you don't mention it here in your past, and referring to a documentation for a thing, the benefits of which aren't obvious to say the least.
c) At times, you sound just a little bit lost. First, you say:
All right, that sounds reasonable - many languages to learn, many limitations to know just the two of them, there's a better way. Then you transition into something else entirely:
My mind here goes: "wait, weren't we talking about web development right now? - why are we talking about data representation then?". But you go back to H/C/J and say:
You've stated yourself that you can do a lot with plain HTML and CSS - and then you tell people about the way to do that same job in something they have to learn from scratch? And you can't create even a small web app with your tool? Why would I learn something new to do the same kind of work that I can do with technologies I know already and that are as wide-spread as they can be? And what's the deal with the data exchange? What does that have to do with this?
Finding a link to its GitHub only to discover a post like this doesn't add to your creditibility here: why would you mention a web framework that you have created, that turns to have been created by your team for internal usage only without any definite plans to turn into a proper open source project?
At this point I got too confused and just closed the thread. That was the journey of me, as the potential adopter of your technology, the first time I saw your post. Might be something to think about.
d) Lastly, any attempt to "overthrow" any combination of existing technologies will always be an attempt to overthrow the entire ecosystem built around them. As verbose and frustrating as HTML/CSS/JS are currently, there's a ton of things that make working with them infinitely easier - from Emmet for HTML, to TailwindCSS for CSS, which essentially allows to get rid of the "usual" CSS grunt altogether, to a bunch of JS frameworks, built on top of it - each of which gives its fellow zealots a chance to get together and troll all the others, who don't happen to share their opinion about the "greatest framework of all time", which turns out to be fairly important in our current loneliness epidemic.
Are you absolutely sure you want to get into this? - because that will require a ton of work and effort, all of which might turn out to be a total waste of time without any critical adoption. And if you're not looking for this to spread, why bother at all? - that about sums up my thoughts on the matter.
Thank you, you just summed up what I was trying to say far better than I could've. This entire idea seems extremely confusing to me and like its trying to overthrow a major set of technologies that's been in use for at least 30 years, which means that the OP is going to have to re-implement all the support in their own language -- in other words, they're going to have to make it a lot better than HTML/CSS/JS are right now, which is something that's going to be incredibly hard and incredibly painful (especially the JS APIs).
Correct - because an easier alternative which does pretty much the same isn't going to blow up, people need to see a benefit in what they're about to learn. Throwing the essential bits, upon which the current web is built, out of the window needs much more valid reason than "hey, here's a thing you can use - and it happens to be a bit easier, IMO - so adopt it, maybe?". Another thing I forgot to mention:
There are a lot of strong assumptions here:
JS is too much (by which I have to assume you mean: it's bloated, messy, inconsistent, insecure, easy to break and unreliable) and that's bad. Many (including me) will agree with you, yet the very fact that it's this much makes it extremely easy to pick up and prototype with. In the start-up world, where one of the main criteria for success is TTM (Time To Market), the cons of JS don't matter - the pros, on the other hand, are critically important to build what you want as fast as possible.
Back-end developers say that can't build UI interfaces - and that's bad, because they should be able to. Very hard to objectively reason about, because
back-end developers, in general, dislike building user interfaces, otherwise they'd go for full-stack right away or they'd get into web design instead. Back-end part of any web project is the engineering part of the project. Front-end part is responsible for user interactivity and thus is more sociology- / psychology- / aesthetically-driven part of the creation. Most back-end engineers don't want to become front-end hipsters, and the majority of front-end designers don't want to become sleepless, code-addicted nerds. Which leads us to
the skills, needed to conceive a great engineering project are radically different from the skills needed to create a polished UI/UX design. There's a reason why they are taught in different courses and pretty much any kind of an institution teaches them separately. Giving people a new toy to play with, hoping that it will make them become fluent at a task they've never done before, is a bit short-sighted, to say the least. There's also the fact that
most companies, for which most programmers (especially beginners, who've read about the kind of income that can be made working for FAANG and who'd rather waste a ton of money jumping from one course to the next in hope of finding "the one" that will help them "land that job", rather than coding anything useful - who seem to be the core of the audience for which you are going for) are going to work for companies that have implemented a separation-of-concerns policy in their human resource allocation design long ago.
Back-end developers work on the code, that makes things tick. Front-end developers make sure that the UX/UI part keeps people clicking where they need to click for the company to keep making money. Trying to break this system by introducing "the one language" to "rule them all" means trying to persuade these corporations to throw of the window this policy out of the window because "JS is just too much". Which was always (and remains) an arduous task to succeed in - consider the amount of years it took Rust to become noticed by Amazon and the like. Which transitions into the last point:
although the HTML/CSS/JS is one hell of a mix, it does allow for (rather imperfect, to say the least) separation of concerns. HTML is responsible for structuring the document (and it's the HTML that gets analyzed by Google and other SEO engines out there - something you'll have to think about it if you actually want people to use it to build at least some web pages). CSS is responsible for styling, and JS - for everything interactive. Lumping it all together "one language" to "rule them all" means that you'll force the vast majority of developers to re-learn what they've learnt extensively by know, just to use your own markup language.
The last point is also the first thing that anyone that will want to troll / argue with / criticize / ridicule you and the project will bring up, and which you've mentioned yourself in both your first video and here:
The basics of HTML can be learnt in an hour, writing CSS is about knowing what to search for on Google before you've memorized all the basics by head and JS is far easier than a well-thought, type-safe language like Rust is. Most beginners pick them up in several weeks, and most people who are already using them have been using them for years - which is something you'll have to contend with.
Once again, do you wholeheartedly believe you can succeed here? If yes - go for it. If not, perhaps allocate your time a bit differently and do make something meaningful out of that web framework. Combining Rust with Elm does create quite a catchy "Realm", and given all the LAMP, MEAN and other catchy acronyms behind technologies that became popular, hey - perhaps yours will blow up too.
Ouch! I have to come to the rescue of poor Javascript here. A truly wonderful language that is more sophisticated than many suggest.
"bloated" - I don't see how sending Javascript down the line to run is any bigger or uses more resources than any most other languages would be. Would BASIC, Python or Lua or whatever be any better? Or do you mean bloated in terms of syntax and semantics? Surely not, it's pretty lean. Rust and C++ have it beat by a wide margin in that respect.
"messy, inconsistent," - I know people love to point a jeer at Javascript's, shall we say, "surprises". But really they don't cause problems unless one is doing something weird. Languages like C are full of surprises as well. If you don't learn the language you are using you will get surprises.
"insecure" - No, Javascript is just a language like any other. I'm sure pretty much any language shoved into a browser given the API's it has there, downloaded from God knows where, given access to all and sundry on the net would result in similar insecurities. It's not the language that is insecure but the environment it runs in. I swear web standards were designed to be insecure from the ground up. One has to be aware of and take care of all ind of potential vulnerabilities opened up by web API's.
"easy to break" - Not sure what you mean there. Certainly refactoring huge piles of JS can be troublesome. But the same can be said of C and many other languages. Type checking can be a huge help there. Also JS was never intended for writing such huge applications. JS does not break when it's written it always does the same thing, like any other language.
"unreliable" - See above.
Anyway, I love JS for all the opposite reasons I love Rust. They are kind of extremes of their design principles.
As a developer of mostly GUIless systems for years it's only recently I found myself having to do something in the browser. One big problem with it all is that being the visible thing it attracts can enormous amount of bike shedding. People will spend an age discussing colours, styles, layout, integration etc, etc, etc, and waste a lot of your time tweaking it around all the time.
I don’t blame anyone for struggling with HTML, CSS, and JavaScript. There’s nothing inherently perfect about them and they all have their share of inconsistencies, inexplicable choices, and flaws. Still, the web gains so much of its versatility and flexibility from those three languages. I don’t think adding a layer on top of them with its own idiosyncratic choices and syntax to ultimately produce pages that discard all the standard affordances in favour of fighting the web at every turn is a solution.
I’m dismayed to see yet another brand-new framework that produces HTML like I see on the site, and that relies entirely upon JavaScript even for primarily static content, considering that everyone has JavaScript disabled to begin with and can remain indefinitely in that state for any number of reasons, network-related or otherwise. I know you said you’re working on ‘cleaning up the HTML’ and it ‘can be fully server rendered’, but I can only comment on what you’ve shared, and it makes both of those critical concerns seem like afterthoughts.
I would much rather take inspiration from the model of Svelte, which works with the web and takes a thoughtful approach towards expressiveness and brevity without undue complexity and without abandoning what makes the web so successful in the first place, because it makes it easy to do things the right way. If you want to help people create high quality websites without requiring familiarity with the underlying technologies, you too need to make it easier to do things the right way—it should require more effort to not do it that way. We should be learning from the past two decades, not repeating our mistakes.
"If the vision is for every human to own their data" you don't design a text data format that is of interest to the geeky 1% of humans who do care about encoding, and who believe they have any data worth owning (let's face it, most people's lives are immensely banal). Encoding is a fun hobby though, just know your crowd.
