After I finished the first article I wasn't sure how long it would be before we'd have enough topics for the next round. But given the continuing a...
For further actions, you may consider blocking this person and/or reporting abuse
In Clojure I came in contact with REPL-Driven Development which coming from a C/C++/C#/Java background was absolutely foreign to me (apart perhaps from working in an SQL shell).
Similarly with JavaScript, at least on desktop browsers, through the Web Developers Tools console one can interact live, directly with the browser and the page or even just simply locally throw together an
index.htmlto play around with some ideas.Sure, you can go to the TypeScript Playground to play with some TypeScript but that doesn't have access to the browser; sure one can use services like CodePen or CodeSandbox but one typically has to figure out the idiosyncratic details of their UI and platform.
Yes, it's not that difficult to "just" download
create-react-app(if you're comfortable withnpm), though but, gee …(I typically just use Preact).
Point is, having an incredibly low barrier to experimentation is invaluable (I assume that's why framework websites often have playgrounds associated with them).
Sure, tooling is bound to aggregate around products as they move closer to production but it can be really useful to have an extremely low barrier to just getting started.
I think Ramus Lerdorf summarized it well:
People were worried about vendor lock-in with application servers, now they are worried about vendor lock-in with cloud service providers , meanwhile mindset lock-in is in full swing with frameworks. I can't even imagine how irritating it must be for authors of the "other" frameworks, to constantly have to explain themselves in terms of React — when React isn't even of the web — in fact it was created to de-emphasize the web.
Perhaps it's developers who need to be "framework-agnositic". The problem is that adopting any particular framework (of any kind) represents a significant investment of time and effort, naturally pre-disposing one to fall victim to the golden hammer rather than pick the right tool for the job. The typical "enterprise response" is to settle on one "batteries included" solution and standardize on it — however that often leads to added baggage which can typically be absorbed in the enterprise space but often not so much on the public internet.
Mmm — that is highly context dependent.
The wider and more complex the interface of a component (in the general sense) is, the less composable it is - a component is an object after all.
Joe Armstrong:
(primitives in Erlang: spawn, send, receive, make_ref, etc. — the (composable) mechansims are built with functions, tuples and lists.)
So perhaps some framework "primitives" are just poorly chosen?
From that perspective React would already be a mechanism on which other custom mechanisms are built.
Components (in the React or JSX sense) can require and support a vastly varying set of
props(andchildren) depending on their role.For example
<div>plays are very different role from<CountContext.Provider value={value}>{children}</CountContext.Provider>and require a very different understanding to be used effectively. From that perspective the composability of "Components" is purely a result of by design being constructed to collaborate within and through the component tree via an implicit interface. That's OOD 101.Design Patterns: elements of reusable object-oriented software; 1995, p.18:
And implementing framework specific types is par of the course with frameworks.
In some sense compilation is a responsible means of providing "developer experience" because it can create value without deferring the cost further downstream. Often "run time is cheaper than developer time" is the justification for deferring cost further downstream but certain forms of compilation can help to mitigate that.
I think to some degree that is only part of it; Everyone has JavaScript Right?
i.e. don't design an application that will only work under optimal conditions; deliver functionality with the minimum amount of HTML/CSS and JavaScript to engage the user as quickly as possible, then carefully and judiciously download and cache additional capabilities.
Putting a different spin on this: SPAs introduced monoliths to web applications.
The history of SPAs seems to go back to about 2003; meanwhile in 2005 microservices became a thing, largely leaning on the idea of a bounded context from Eric Evans's Domain-Driven Design in 2003.
In 2015 I vividly remember running into blog posts like Mixing MPA and SPA: worst of both worlds.
Then Micro Frontends made an appearance in 2016 - which in my judgement completely failed to take the nature and constraints of the web into account - especially when claiming the "benefit" of micro frontends being able to each use their own distinct/separate UI framework.
Perhaps MPAs will become the real "micro frontends" — each page having highly focused capability which can be downloaded relatively quickly while sharing resources with other pages from the site via Service Worker, Indexed DB, and BroadcastChannel (SharedWorker would be nice).
Awesome post! I wish i could find that article you were talking about – It sounds like an awesome read!
Guess what: I'm experimenting with building such a framework!
The closest I've seen is Prism. It isn't completely runtime-less in general but they had a cool webcomponents demo that essentially was since all stateful updates in the simple example were simply handled by getter/setters on the element.
Holy s**t bro, I read till the end of the article, your post is awesome, i would like to read more about this stuff next time!
bostonmagazine.com/news/2021/09/14...
“But there’s so much stuff to do,” he continues. “There’s so much work to do now trying to clean the Web up. For Solid, there’s a serious amount of work. There’s never very much time to sit back and go, ‘Oh, wow.’”
I would love to read your thoughts about this epic battle for the WWW as a whole.
Where's part 3? 😅
Nice article....
Hah.. It's only been a couple days.. need a few more things to gather up. MPA mode maybe. Seriously this year has been ripe for these sort of topics. So much new tech coming up in SSR, rebirth of MPAs, and Svelte's philosophy permeating the frontend hitting a critical mass.
Now: MPA is comeback! You can build website with 0% JS!
Later: Today, you can build website with 0% HTML 😅
If you like Svelte, you should take a look at RiotJS - been around a lot longer - it's on version 6 now and seems to have influenced Svelte a lot
I read your posts only for memes.
Love the mention of hyperapp! Wish I could get more traction with it at work
Love your Articles Ryan.. 👌⚡❤️