Hacker News Reader

Comment by JMTQp8lwXL | Hacker News Reader

> Do you introduce a domain-specific language? You're now responsible for part of the build chain, and for editor integration.

> Now, if there's a major organization backing the framework, maybe the calculus works out. Google can back Angular...

In my experience, even large orgs don't necessarily have the capacity for building out full-featured editor integration and build tools. Google has a great team managing Angular and it still has no tool for performing codeshifts. The editor integration to date still leaves much to be desired.

With the number of years and man-hours dedicated to this point, I'd imagine these thing would've happened by now, or they may not happen at all. Lately, Angular's push has to been to 'make it faster', which helps with developer productivity, but not much movement on the developer experience (better editor integration) part.

Agree with the thesis, but it's still understated how expensive creating your own DSL is.

View on HN

One option is using XML with complicated enough XML Schema. Good editors like Intellij Idea support editing such an XML and provide good autocompletion, on-the-fly validation. XML libraries would parse that XML into tree and validate it against schema without any additional effort.

While XML certainly deserves some blame, the amount of tooling around it is unmatched.

XML's main limitation derives from its base primitives: Strings and hierarchies of ordered strings labelled with strings. Starting from that premise adds a great degree of schematic overhead to convey semantics, which tends to overflow into syntactical boilerplate.

Traditional parsers start from one string and evaluate that a character at a time. JSON starts from a few JavaScript primitives. SQL has primitives that vary with the engine you're using. These are other points on the spectrum that are appealing in the details - a plaintext string is accessible to all text editors and simple string processing tools. JSON covers a selection of common data primitives. And SQL has a grip on automatic constraint enforcement, which helps in defining user types with high data integrity.

If I had to pick one that's really going underused, SQL would be it. A string source file could be dissected into a number of tables and edited like any other CRUD system, then re-serialized as a string. That we don't do it this way is more an accident of our current beliefs about which means of implementation are appropriate for various tasks - queries on relational data are "slow" compared to bodging buffers and recursing through DAGs. But if we want nice developer tools we should probably start acting like data integrity is more important. Slopping dependencies around the file system and relying on a separate bespoken tool chain to reconstruct their relationships as part of a built artifact is a thing we ought to outgrow at some point, but it's also so intrinsically accepted that the paradigm is hard to escape.

It's somewhat unfortunate that XML arrived at this perception of being complex, when SGML (= superset of XML, HTML, and everything angle-bracket markup) very much is a technique to give structure to ordinary plain text. For example, SGML could parse .INI file syntax such as the following (and present it as a fully-tagged, canonical markup ie. XML):

    [config-item-X]
       config-param-Y=bla
       config-param-Z=123

If you look at how popular markdown and other wiki syntax is, and at the same seeing folks hit markdown's limitations fairly quickly (for example, markdown has no way to pull-in content from other files or doing any document composition whatsoever), then I hope you can see that SGML is a technique designed for a broad application in this area, being able to handle standard markdown and custom markdown extensions (not to mention that SGML is the only ISO markup meta-language able to handle HTML with all it's tag omission rules).

In XML-land, this has been re-discovered as "invisible markup" a couple years ago, going full-circle in the "dumbing down" of SGML into XML (which was seen as progress and win for simplicity at the time when XML was subset from SGML).

I would also disagree that the defining characteristic of SGML/XML is nesting of tags so much as it is regular content models. A content model such as

    configitem: configparam+
    configparam: configparam-name, configparam-value

is what drives SGML's tag inference in the above example.

But yeah, SGML/XML is made for markup, not necessarily config files and service payloads. And I agree SQL could be improved by treating it like an ordinary programming language, with the same focus on SQL artifacts wrt syntax highlighting, static checking, and testing (though probably not in the way you suggested, by reading-in SQL script files as a primary means to serialize DBs :).

While XML certainly deserves some blame, the amount of tooling around it is unmatched

That tooling was created as a result of XML being difficult to use otherwise, not the other way around; in much the same way that some languages like Java seem to depend on an IDE to be even usable, far more than others.

I disagree. The amount of tooling come from the combination of well-written specification and enterprise jumping on it. Also, basic XML is quite easy to grasp even for people with really limited or no technical skills, which is also a big bonus for adoption. Granted, some XML later developments indulged in the factory factory pattern, but XML got lot of underserved blame, especially when the purpose it’s to advocate another less readable format that doesn’t handle comments.

666f 6f0a 6261 720a - newline separated ASCII is not inherently usable, f09f 988a 0a - utf8 is almost magic

And this conversation happening on web platform... Is it usable? Browser complexity is enormous.

I'd argue XML tooling is a joke. Can it make a closure?

Yeah, the outcomes vary for sure. For a counter-example you can look to JSX which has excellent support in most major editors, but it's definitely the exception to the norm.

Agreed, the size and scope of the DSL will impact the amount of man-hours necessary for developer experience related work. Resourcing that effort is a separate concern, but one that should be considered for the DSL's viability.

JSX, being a sugared syntax for the React.createElement API, likely doesn't need a team of 20 for editor integration, whereas Angular templating language has more to it: pipes, directives (shorthand and non-shorthand syntax), property bindings, expressions, etc -- and templates need to be evaluated in context of their corresponding TypeScript Component.

React is an immensely popular library. You can't really expect that some random DSL would receive similar amount of attention.

I think all the major frontend frameworks are overly complex beasts, they're too big and can't be used as libraries - for example, you can't replace some functionality out of the box without making a fork. I also didn't find any other reactive frontend framework that could fill this requirement, so I decided to write my own. [0]

It is the simplest thing I could conceive (to build, not to use - I plan to provide more convenience, but the selling point is the ability to customize everything.) It's template based and without a virtual dom - during render, each variable used will be listened and when it changes, the element that uses it is updated directly, without recomparing the whole tree. It's still in progress.

[0] https://github.com/arijs/ari

You can use React like a library. You can even go without JSX, though nobody really does. React is also kind of odd because it includes a bunch of other stuff like hooks, even though most people bring their own state management to it. But it's definitely the least-framework-y of all the major frameworks.

I understand where you're coming from - it is advertised as the 'view layer'. But I think that templates are more similar to the native browser language - html, so it is easier to grasp. It is also simpler and easier to implement than a js+jsx parser.

Nobody does react without jsx because it is the worst of both worlds, but if React had template strings (not necessarily built-in but at least as a first-party plugin) it would be a more viable option.

React by itself is just a templating language, yeah I got it.

But i think for most devs out there, like 99% (yeah I made this up) of them, React is actually React + React-dom, the latter per the account of the official team is like a runtime thing, which perfectly fits into the description of a framework.

For years I used react without jsx - with a few minor conventions to make it shorter to write elements via JS (`_div(...)` being equivalent to the jsx `<div>{...}</div>`, and some minor variant for elems with attrs) it's quite easy to build trees using plain old JS syntax.

The advantages of doing that were better tooling support, since everything under the sun supported JS, but not necessarily JSX very well, and jsx isn't really all that important anyhow. Obviously that's not a factor anymore today ;-).

Yep! Really the non-JSX syntax is very close to that of most virtual DOM-based rendering libraries, including the fairly popular Mithril.js

Have you tried React? It feels fairly library-esque to me. You can be useful in as little as two lines of code:

const elem = React.createElement('div', null, 'Hello World');

ReactDOM.render(elem, document.querySelector('body'));

It's 35.9kB gzipped, although "too big" is subjective. I may be unimaginative, but over my last 5 years or so with it, there isn't much I've wanted to change. As a library consumer, I don't personally mind if a VDOM is used or not, so long as performance is good enough not to ship a noticeably lagging UI to my users. Having experienced both React and Angular --one uses VDOM, the other not-- I haven't found this implementation detail to meaningfully impact performance, but I spent my time building straightforward CRUD apps.

I would consider sharing an example to Ari of something that's hard to do in React/Vue/Angular, and how it's made simple with AriJS. That might help elucidate where it shines, and the key problem being solved.

Thank you! Yes, i've tried it. You can think of me like someone that prefers an old model of the Porsche 911 than the latest model - too much technology that you can't fix yourself, and that's my primary concern with the major frameworks - they're not simple to reimplement!

> Have you tried React? It feels fairly library-esque to me.

Because it is, in fact, just a library.

React implements the component lifecycle, calling into the component to do it, stores all the component state, and reconciles DOM changes on behalf of the component. It's the very definition of a framework - it's calls the component, the component doesn't call it.

It has been said it is a library, but imo it is not for the reason how it forces you to write code according to their rules. For instance functional components. Most of the code you write is to fit React, so for this reason I would say it is a framework.

Off the cuff, that sounds a lot like Knockout.

https://knockoutjs.com/

Knockout was the last time I felt I really understood the js ecosystem. Since then it’s a mess of npm, webpack, and long complicated front end builds to do simple things.

What interesting is of all the js code I’ve written the code that lasted the longest was pure business logic Written in vanilla js, separated from any library or framework. It’s gone through knockout, angular, and react versions of the site, and people always try to rewrite it the new way, but it just doesn’t work as well and they end up writing a thin simple shim to bridge the old and new code.

Reply on news.ycombinator.com