
Web Code is a solved Problem – how about fixing Web UI next? - rivy
https://weblog.west-wind.com/posts/2018/May/31/Web-Code-is-a-solved-Problem-How-about-fixing-Web-UI-next
======
acconrad
So his central thesis is that JS has been getting all of the love while HTML
and CSS have been marginalized. I want to empathize with him because he's a
seasoned vet in programming and has been at it longer than I have. But, I've
been doing web development since i was 12 on pet projects, and we totally have
been making great strides in web UI.

If you made a website in the 90s or early noughts, everything was tables. Do
you remember how to make a button with a bevel in 2005? You made a 3x3 table,
and had to splice an image into _9_ different sub images, and then stitch them
all together. Now you have background:linear-gradient and border-radius. I
mean, maybe you take this for granted now, but seriously, that was _game
changing_ for me when those things came out.

Now add on UI frameworks like Bootstrap and Zurb. Before everything was a JPG
photoshop mockup. Every design was treated in isolation. There were entire
_businesses_ revolved around taking a PSD and turning it into HTML/CSS. Now
everything is a component. It's reusable... _and useable_. Sure, we may have
watered down design to the point where largely every SaaS landing page is the
same, but the speed with which we can get developers to convey trust via
design is vastly improved over the old days.

Sure, JS frameworks are all the rage right now. But we have made _serious_
strides in web UIs as well.

~~~
ergothus
Has ui improved? Yes. But is ui a good experience? No.

Simple tasks like centering or multiple equal height columns are now possible
(yay!) but aren't actually simple.

A large majority of css techniques are trying to get around how css tries to
work.

Flexbox is great compared to what came before...but have you tried teaching it
to someone new? Zindex and stack context? Style a container based on what it
contains?

Compared to the improvements in js, and compared to the ease of use of non web
ui building, there is a lot of room for progress.

~~~
jgh
I want to say, as a guy who is not much of a web developer but is trying to
make a web site, css is f'ing frustrating.

For example I found a CSS-only stylized dropdown list, which is great. Why
should I have to use Javascript to stylize a dropdown list?

Anyway I take the component and css from codepen and put it in my site and it
doesnt work, at all. Works perfectly on codepen, doesn't work on my site. As
far as I can tell there really isn't a way of figuring out _why_ it isn't
working either. There aren't any errors or anything, no real means of
debugging it. I'm basically going through line-by-line the computed CSS for
all the different parts and trying to see what's different and why that is
impacting the look of the thing. Very frustrating.

~~~
TheAceOfHearts
Have you had more positive experiences with any native alternative? My
experience with em has generally been that they work well until you want to
customize things.

I think people tend to seriously underestimate the complexity involved in
dealing with layout and styles. CSS has some poor defaults and plenty of
quirks, but it's also incredibly powerful and not that difficult if you bother
taking the time to learn it properly. You are struggling because you have not
learned to use the tool correctly.

Try implementing a few basic layout algorithms as a weekend project. I believe
it'll change your view of CSS.

~~~
brobdingnagians
So true. I looked at implementing some layout algorithms in PDF pages for a
project I was working on; eventually realized I should just use the standard
elements in the library I was using and forget about anything custom because
otherwise I'd be making a separate product...

------
tannhaeuser
With an app-centric view of the Web like that, you can only come to the
conclusion that the Web is broken. When in reality your premise is false: the
Web is a document-centric self-publishing mechanism. That you're hell-bent to
using it at as application delivery platform doesn't make it any more
reasonable to judge the Web for something it simply isn't designed for. It's
not a question of immaturity either: the Web has been in the making for almost
25 years; yet the newest mainstream Web frameworks (eg. React) still build on
a DOM rather than a more appropriate scene graph model such as the one Flash
had 15 years ago.

The problem isn't the Web, but people wanting to sell Web apps, yet still
wanting to free-ride on the popularity and one-time-success of the Web. Why
not address this at WHATWG (as in "Web Hypertext Application Working Group")?
It would be easier for both camps because the document-oriented Web doesn't
have to look after the incidental complexity introduced with overreaching Web
standards and CSS.

Edit: see also "The Cult of the Complex" at
[https://news.ycombinator.com/item?id=17214045](https://news.ycombinator.com/item?id=17214045)

~~~
balfirevic
> The problem isn't the Web, but people wanting to sell Web apps

That is backwards, I think. People want to _use_ web to get their applications
(for mostly good reasons). Of course developers will make them.

> yet still wanting to free-ride on the popularity

"Free riding" concept sounds misused here.

> Why not address this at WHATWG (as in "Web Hypertext Application Working
> Group")

How would that work? I want to make a SaaS app to solve some problem, but
instead I write letters to WHATWG to do... what?

~~~
tannhaeuser
My comment wasn't addressed at practitioners developing web apps so much as a
response to principled criticism of the Web architecture _as application
development platform_. As the author of TFA says he's coming from a Windows
desktop app development background, praising early-90s RAD environments such
as FoxPro for their superior workflow and adequateness for the job of creating
business apps.

Then why not use those tools rather than the Web? But the author insists

> _The last thing I want to see is us going back to native development as the
> first line for development. The Web has always been the future for
> application development and I believe it will go all the way in the end. I
> believe in the Web as a platform and I want it to stay as the dominant
> platform._

Why does the Web have to be everything to everybody, gaining incredible
complexity to the point that it's useless as a standard because we're never
going to see new independent implementations from scratch?

Re WHATWG: I don't think HTML5 is bad, but it must be said that it was the
late 2000s "HTML5 rocks" propaganda making plugins (Flash and Java)
unfashionable for better or worse. Turned out the offered overlapping and
partially implemented alternatives (Canvas API, declarative CSS animations and
shapes, SVG) were lacking, and didn't address the principal use cases. Those
being describing highly interactive apps, controlled piercing of Web sandboxes
for integration with native file systems and devices, etc.

~~~
balfirevic
> Then why not use those tools rather than the Web?

I think the author of the article writes from the app developer perspective -
his users are on the web and due to it's reach he's stuck there. He does
appear to be cheering on the web as the application platform, but that might
be the most reasonable way forward just because of it's momentum. And it is
somewhat decent app development platform.

All of this comes at the cost of large amount of complexity, there I agree.

------
goofballlogic
I have to agree with @rado on this one. The article presents this as a "code"
vs "UI" debate when really it's a "web" vs "app" debate.

Although we use the web as an application platform, it was designed for
information interchange, and evolved to support "an Internet-scale distributed
hypermedia system." Those are often two quite different things. An application
platform focuses on "component semantics" whereas the concept of an "Internet-
scale" application focuses on "connector semantics".

"Not only is the set of input controls really small, but these controls have
almost no functionality associated with them." \- yes and that's a useful
attribute if you are architecting "internet-scale" applications (think
hypermedia, rest, hateoas et al.) because the intent is that each component is
dumb enough to be seamlessly switched out with another. In this mindset, a
page in a web application does one thing and does it well. It doesn't
coincidentally provide retina scanning and 3d imagery (yes, i know...)

Neither the code nor the UI of the web are "solved" problems if you are trying
to use it as a traditional application programming platform. You need
frameworks and tooling to accomplish that.

I'm not arguing here that it should be this way (although I happen to love the
web concept), but the real debate here is about "web" vs "app" \- not "code"
vs "UI". HTML is designed to facilitate web applications and that will
continue to evolve very slowly and deliberately. The alternative is to
reimagine web technologies as a traditional application platform from the
ground up.

------
joeblow9999
"Web Code is a solved Problem"

honestly whenever I see this said about _anything_ , I'm pretty sure it's not
a solved problem.

------
flohofwoe
Unpopular opinion: Please not another builtin high-level UI for the web, none
of the native platforms got their 'system UI' right either, and there will
never be a single UI solution for all problems.

Radical, overly optimistic suggestion: Reduce the browser to 2D+3D canvas,
audio (not WebAudio please, too over-engineered), input, networking (...) and
implement everything higher level on top of those thin platform abstraction
APIs in JS+wasm modules that are loaded ond demand. Put the current HTML APIs
into such modules as well for backward compatibility.

~~~
kaoD
That's a terrible suggestion. We need markup. We need _standard_ markup. We
need accesibility. We need semantic tags. We need interoperability. We need
developer tools.

We don't need N+1 "standards". We don't need N*2 developer tools. We don't
need N^2 teams working on subpar competing "platforms".

We need HTML.

~~~
flohofwoe
The HTML standard would be implemented in a module, which could even be
bundled with browsers so it doesn't need to be downloaded on first use.
Nothing would change for HTML usage except that it wouldn't be baked into the
browser executable, and alternatives to HTML could be explored without
bloating the browser even more.

The devil is in the details of course, that's why I wrote "overly optimistic"
:)

~~~
madeofpalk
I mean, Canvas is there. You're more than welcome to draw your own UIs in it,
as plenty have done/tried before. Flipboard had a render-react-to-canvas
project they used for mobile (which was completely inaccessible to _any_ sort
of assistive technologies), but I believe they abandoned it.

~~~
flohofwoe
I kind of did and it works quite well. Fair point about accessibility though.
Another problem is that there's no way to access system font data from WebGL.
Also the way I'm currently doing rendering (continuous frame rendering even if
the UI doesn't change) isn't mobile-friendly. But these are all solvable with
a few more resources thrown at it (Dear ImGui is a single-developer-project,
and the cross-platform rendering library (sokol-gfx) too.

[http://floooh.github.io/oryol-sticky-tests/imgui-highdpi-
sap...](http://floooh.github.io/oryol-sticky-tests/imgui-highdpi-sapp.html)

This is 460 KByte wasm, 260 KByte of this is embedded TTF font data.

~~~
dmitriid
Wow. Your library is simply _amazing_. Especially considering it's a single-
developer project.

~~~
flohofwoe
Ah sorry I was unclear, Dear ImGui isn't _my_ library. Credit goes to
@ocornut: [https://github.com/ocornut](https://github.com/ocornut)

The sokol_gfx graphics wrapper is my stuff, but that's much smaller :)

~~~
dmitriid
Still amazing :)

------
ernsheong
I'm still super gung-ho about web components. The progressive browsers are
committed to making it happen.

The picture is not so bleak for custom elements:
[https://caniuse.com/#feat=custom-
elementsv1](https://caniuse.com/#feat=custom-elementsv1)

Firefox also just announced that Shadow DOM arrived in a nightly:

[https://bugzilla.mozilla.org/show_bug.cgi?id=1460069](https://bugzilla.mozilla.org/show_bug.cgi?id=1460069)

[https://news.ycombinator.com/item?id=17172613](https://news.ycombinator.com/item?id=17172613)

Contrary to popular belief, you can start using web components WITH just
custom elements and WITHOUT shadow DOM!
[https://twitter.com/rob_dodson/status/961780022628331520](https://twitter.com/rob_dodson/status/961780022628331520)

I jumped onto this bandwagon early and struggled with Polymer 2 and HTML
imports (ugh!). Now they have made the same realizations and moving forward
LitElement will lead the charge toward usable and lightweight web components:

[https://www.polymer-project.org/blog/2018-05-02-roadmap-
upda...](https://www.polymer-project.org/blog/2018-05-02-roadmap-update.html)

[https://github.com/Polymer/lit-element](https://github.com/Polymer/lit-
element)

Here's how you can get started: [https://github.com/Polymer/pwa-starter-
kit/wiki](https://github.com/Polymer/pwa-starter-kit/wiki)

It's not paradise, there are kinks to work out, but ultimately one can make
production worthy apps with web components TODAY (polyfills available). You
can sleep at night not worrying that your library will become the new jQuery
someday:
[https://twitter.com/SaraSoueidan/status/999645120155746304](https://twitter.com/SaraSoueidan/status/999645120155746304)

~~~
DivisionSol
This is one of the reasons I'm such a fan of Vue.js. Using the vue-loader, you
write single-file 'components' which all their included templating, logic, and
style. While not EXACTLY what the promise of "Web Components"/"Custom
Components" offers, it is definitely a good step forward in thinking on how to
modularize all the pieces of the front-end.

[https://vuejs.org/](https://vuejs.org/)

[https://github.com/vuejs/vue-loader](https://github.com/vuejs/vue-loader)

~~~
keyle
yep that and vue-cli and you have all the framework you need including a dev
server and a test framework.

------
chrismorgan
> _CSS Grid works with all major evergreen browsers, but Internet Explorer -
> which sadly still has significant browser share - is not supported by CSS
> Grid._

Well, it _does_ support Grid, just an older, prefixed version of the spec,
with plenty of bugs. With autoprefixer (which I use via postcss-cssnext), you
have to deliberately enable IE grid support (config option `grid: true`), and
then it will block you from doing things in Grid that IE _definitely_ doesn’t
cope with, and you will still sometimes have to make adjustments to get it to
work (e.g. IE has no qualms about stacking content in the same cell, so you
may need to specify locations rather than using auto layout), but it hasn’t
been too bad for most stuff I’ve done so far.

IE’s share steadily shrinks, and what remains consolidates around IE11. These
days I’d say that the vast majority of developers should care a little about
IE11 (my rule of thumb is to ensure everything _works_ , but some ugliness or
deviation from design is acceptable), possibly a bit about IE9, and definitely
not at all about any other version of IE.

Just wait another two years and then you can forget about IE for good, or
something. ;-)

~~~
oneweekwonder
> Just wait another two years and then you can forget about IE for good

Because most developers will target chrome with a current market share of
about 60%.

I bet google will stop to innovate and compete as soon as they ate most of the
cake, hopefully without forcing "standards" on other browser.

But some of their products is already crippled on other browsers, so that ship
might have sailed already.

In another two years, or something.

------
yakubin
So the author claims that the JS ecosystem is excellent and HTML&CSS are
broken? Yet it is my never-ending experience with the web that a website’s
usability is inversely proportional to the extent it uses fancy JS frameworks.

------
cameldrv
Think back to the inspiration for modern UI. It's a flight engineer in the
back of the cockpit, or an astronaut on his way to the moon. He has some
buttons and switches, a lot of gauges and maybe a couple of digital displays.
Then think about documents. The written word. Information graphics. What the
web has been trying to do is make an astronaut's control panel the same kind
of thing as a Guttenberg bible. That is a very tall order, and it's not
surprising that it's taking some iteration.

------
icc97
> I got my start in FoxPro, worked some in VB6 and MFC/C++ and then worked in
> .NET WinForms and WPF which I still use on occasion to this day for things
> that simply work better on the desktop - mostly tools or applications that
> need to interface with hardware.

> When I think back on those days one thing that stands out to me is how easy
> and fast it was to develop functional UIs for these applications due to a
> plethora of pre-made components, easy to use visual tools that allow easy
> placement and visualization of content. And maybe more importantly a well
> defined underlying UI API that supported creation of common controls that
> addressed the most common use cases.

The sheer ugliness that is produced by .Net developers is astounding. The
simplest most ridiculous thing is the sizing of buttons. The great simple
thing of using something like bootstrap is that buttons are padded in nice
proportions. The only options are text, S/M/L and some colour styles. But if
you hand a developer a form designer tool they generate buttons 10x bigger
dumped somewhere in the middle of the form.

The other WPF form that's been around wehre I work for 8 years has a peach
coloured background... because the company logo is kind of orange.

Sticking to the rules that boostrap / material design give you produces quite
nice looking and usable interfaces. But sticking to the rules of Windows UIs
gives you at best usable but almost never nice looking.

Then of course there's the unholy curse of Java UIs...

~~~
seanmcdirmid
Niche enterprise UIs never even got the benefit of one designed, let alone a
team. The devs could be handed the most amazing and the result would still
look “undesigned”.

Bootstrap provides cookie cutter design solutions, but it is well known that
you’ll benefit from a designer if you need something more custom (and your UI
will look bad if you don’t invest much in its design).

~~~
calgoo
I think bootstrap is great for all the sysadmins etc that need to create a
tool but don't want to spend days tunning css.

------
pixelrevision
The fact that there is no standardized date picker for the web in 2018 is
impressive.

~~~
pbowyer
Yes this. That to get cracking functionality you have to include React, in
order to include AirBnB's superb one [1].

1\. [http://airbnb.io/react-dates/](http://airbnb.io/react-dates/)

------
arithma
Maybe we need the web to be a way to publish basic documents, and then use
docker-like thing where people publish apps and you can immediately access
them by downloading the upper layers. What's happening now is the reverse,
expanding the Web APIs to become an OS when we already have so many of those.
HyperKit, Hyper-V, and Linux containers (or whatever docker) use are already
there!

------
yesimahuman
Web Components solve most of the problems he describes here, yet he claims
they only work in Chrome so it'll be another two years. That's false. We've
built the next version of Ionic controls 100% as web components, specifically
targeting mobile, and we've been incredibly happy with how ready they are.

Sure, building web components really benefits from some sugar (much like
jQuery back then), but once you have that sugar they work great (we built a
helper WC tool called Stencil:
[http://stenciljs.com/](http://stenciljs.com/)).

Now that web components are ready, we just need to educate people on how they
can start using custom components through normal HTML tags. We're on to phase
two.

------
dmitriid
All of current HTML and CSS standards still assume that web pages are just
that: static paper-like pages.

Vast majority of JS code and frameworks treat web pages as parts of
applications, where static paper-like pages may happen, but only as a view
within a larger app.

I usually bring Sencha as an example. It's as impossible to build anything
remotely close to Sencha's components today as it was 15 years ago when it was
called just ExtJS[1].

[1]
[http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/...](http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/#all)

------
transfire
Here's the CSS fix not enough people are paying attention to:
[http://gss.github.io/](http://gss.github.io/)

~~~
smaddox
My understanding is that this approach was rejected because of path-dependence
of the layout, i.e. deterministic only if you include the full interaction
history. Path-dependence in a layout engine would be a debugging nightmare.

------
speedplane
A simple step forward would be to standardize SCSS and start moving to native
browser support rather than compilers. That doesn't seem hard to do.

------
rado
Code is solved because you use a JS framework. UI is unsolved, because you
don't use a UI framework. What a strange article.

------
tomatotomato37
>You step away from the Web world for a month and you come back and there are
20 new things you need to look at

Generally a problem is not solved when people keep trying to come up with new
solutions for it every month

------
jacobr
> Ask most Web developers about the biggest pain point in Web applications
> today, and they will likely tell you that Web UI is their biggest time sink.

I would say this is equally true for most native app developers.

------
Theodores
The problem is with the average UI designers, the average frontend developers,
the average backend developers and the average micro-managers as well as the
slice 'n' dice let's-pretend-it's-agile way of working. I am guilty of being
one of these average team players but after doing some frontend work the
average agency way I now know a little bit about how stupid the problem is.

Your average website looks pretty but lurking behind it is 10000 lines of CSS,
none of it maintainable and put together by some silly build tools that hide
rather than solve the problem.

This CSS is like Jenga, take one line out and it falls apart. The only thing
the average frontend developer can do is add more cruft to it. They don't have
the bravado to chuck it all out, to start over with CSS Grid and forget every
bit of margin and padding they have 'learned' over the past years. Plus they
would have to do all that in their spare time, their sliced 'n' diced 'agile'
workflow just would not allow for it.

So we still have this charade of average 'web designers' making up drawings in
some artworker program of what the thing should look like. They add their own
flair - let's put the search box on the left, shall we? None of what they do
is needed as the way to lay out content on a page is pretty much worked out.
Plus these average designers work with placeholder copy and never real
content. Plus they never ask the devs what can and cannot be done, with every
client there are special things needed bespoke just for that client and their
market niche. Dev's can do that stuff but they don't get to talk to the client
and don't understand what the client is trying to do.

The average web 'designer' then gets the designs signed off with the client
and the whole thing is then bundled off to the team who do code things. By now
it is too late for the dev team to say 'we could have done that whole thing in
CSS Grid by tea time', it is all nailed down and has to be delivered the old
fashioned way to exactly match the PDFs or whatever the designs came in on.

So the same base templates from the same package get rolled out and those
templates pull in antiquated cruft such as 'moderniser' or 'jquery'. The
carousel goes on the home page, again needing a library of more JS and CSS
that gets churned together with one of these 'build tools'.

To make the site 'faster' a CDN gets used, a bigger AWS box gets used, third
party plugins do things to mangle the images so everyone gets to see the same
cruddy images whatever platform they are on.

Even worse is what happens to content. It is arranged to work with the 'divs'
and 'floats' and 'position absolute' gubbins, often with the layout different
on mobile/desktop because the same content is repeated twice and hidden
accordingly.

Regarding the javascripts, there is no need for 99% of it. Input boxes don't
need it, image viewers don't need it but the average website delays for ten
seconds or so on mobile because none of the average experts thought outside
the box and bothered to RTFM and KISS in a DRY way.

Thank goodness for Google and Mozilla, there is innovation aplenty and the
real challenge is how average web developers work in average agencies. It
reminds me of being at university and how people did assignments by
essentially copying what everyone else did and not going first principles it,
to actually understand what is going on.

I am personally grateful of this situation as I can see possibilities to make
lots of money rescuing small businesses from the burden of average clock-
watching frontend web developers and average designers.

Of course, none of this applies to the HN reading crowd and those people doing
fantastic work, just those people still churning out Jenga CSS.

------
PretzelFisch
It seems unfair to compare a proprietary and closed system api to a standards
based one. Where there are many companies with different and conflicting goals
setting the standards.

------
jpochtar
We're trying to solve exactly this problem with Pagedraw! Check out
[https://pagedraw.io/](https://pagedraw.io/)

~~~
towndrunk
Yikes!

"Sorry, our editor is optimized for Chrome"

~~~
jholman
That is an _amazing_ characteristic in a project for building websites. What
in the what.

------
blackbrokkoli
Detail question:

Why does he talk about HTML5 being 8 years old? Wasn't the first release in
2013 (or something)? Help me out here...

~~~
mxschumacher
timeline differs if the standards work is taken into account, not the
widespread implementation by browser vendors. See here:
[https://en.wikipedia.org/wiki/HTML5#History](https://en.wikipedia.org/wiki/HTML5#History)

------
based2
\+ a standard to close session (logout)

------
dagenix
He's upset he can't send text messages or interact with Bluetooth from html?
Wtf. How is this even an article. I'm angry my toaster isn't batting 0.500 for
the Nats. Seriously, nothing to see here.

------
mankash666
Web code is clearly unsolved:

1\. The elephant in the room, Apple, is highly non compliant with web
standards (iOS Safari lacks js web workers, webgl 2, WebRTC data channel, and
many many others)

2\. The roadmap of webassembly is merely the start of glaring unsolved
problems

3\. GPU compute will play an increasingly important role in the future, given
the advent of AI, complex cryptography, video, image,... The web and browser
have outdated and insufficient support for the same

4\. Access to sensors and peripherals is abysmal. WebUsb is a step in the
right direction, but much needs to happen there

~~~
matharmin
> iOS Safari lacks js web workers, webgl 2, WebRTC data channel, and many many
> others

Are you referring to service workers? I've been using web workers on iOS for
years.

~~~
mankash666
Mozilla [1] lists webworker support on iOS to be basic, clearly lagging in
compliance.

[1]: [https://developer.mozilla.org/en-
US/docs/Web/API/Web_Workers...](https://developer.mozilla.org/en-
US/docs/Web/API/Web_Workers_API/Using_web_workers)

~~~
stareatgoats
> clearly lagging in compliance

What is missing is _shared workers_ support (and producing output from
_console.log_ in web workers). Of the two, shared workers would be a
particularly useful feature, as it would in theory enable different browser
tabs to utilize a shared, potentially resource hungry script, as per the
Mozilla description at [https://developer.mozilla.org/en-
US/docs/Web/API/SharedWorke...](https://developer.mozilla.org/en-
US/docs/Web/API/SharedWorker)

The devs at Apple claims that this use case is not relevant and/or better
served by Service Workers (which is even less supported). Not sure I
understand their reasoning.
[https://bugs.webkit.org/show_bug.cgi?id=116359](https://bugs.webkit.org/show_bug.cgi?id=116359)

------
fairpx
I work On UI/UX for B2B software businesses and the reason Isee for the
problem is that the web is built by engineers. There has been a big focus on
code quality, best practices, frameworks etc. But the majority of these
engineers didn’t spend time on UI. This is definitely changing. 95% of our
customers are great engineers that are seeing the value good UI/UX can add to
their product and help deliver a better experience to their user. We’re in the
early stages of this shift, but forward thinking engineers are already paving
the way.

[http://fairpixels.pro](http://fairpixels.pro)

~~~
PretzelFisch
winform and win32 were built by engineers. Wpf had much more thought put in
place for design aspects. The problem s we try to write applications in a
system designed for documents.

------
ebbv
Web Code is definitely not a solved problem. I am working on a project in
Angular right now and it has advantages and major trade offs over writing it
in plain JS. I’m at this point not sure it was worth it.

As far as Web UI goes, Angular has the Material Library, Bootstrap was all the
rage a few years ago and there would have been this same article in reverse.

But the reality is these things are never solved. You may just feel happy with
the current state of something but it won’t stay that way for long. These
massive JS frameworks are probably a fad.

