Files
davideisinger.com/static/archive/dev-to-ptnb0b.txt
David Eisinger 923865782b Status quo
2023-07-03 21:53:13 -04:00

2596 lines
90 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
#[1]DEV Community
[2]Skip to content
(BUTTON) [3]DEV Community
____________________ (BUTTON)
[4]Log in [5]Create account
DEV Community
(BUTTON)
(BUTTON)
[heart-plus-active-9ea3b22f2bc311281db911d416166c5f430636e76b15cd5df6b3
b841d830eefa.svg] Add reaction
(BUTTON)
[sparkle-heart-5f9bee3767e18deb1bb725290cb151c25234768a0e9a2bd39370c382
d02920cf.svg] Like (BUTTON)
[multi-unicorn-b44d6f8c23cdd00964192bedc38af3e82463978aa611b4365bd33a0f
1f4f3e97.svg] Unicorn (BUTTON)
[exploding-head-daceb38d627e6ae9b730f36a1e390fca556a4289d5a41abb2c35068
ad3e2c4b5.svg] Exploding Head (BUTTON)
[raised-hands-74b2099fd66a39f2d7eed9305ee0f4553df0eb7b4f11b01b6b1b49997
3048fe5.svg] Raised Hands (BUTTON)
[fire-f60e7a582391810302117f987b22a8ef04a2fe0df7e3258a5f49332df1cec71e.
svg] Fire
(BUTTON) Jump to Comments (BUTTON) Save
(BUTTON)
(BUTTON) Copy link
Copied to Clipboard
[6]Share to Twitter [7]Share to LinkedIn [8]Share to Reddit [9]Share to
Hacker News [10]Share to Facebook [11]Share to Mastodon
[12]Share Post via... [13]Report Abuse
[14]Rich Harris
[15]Rich Harris
Posted on May 15, 2020
[sparkle-heart-5f9bee3767e18deb1bb725290cb151c25234768a0e9a2bd39370c382
d02920cf.svg]
[multi-unicorn-b44d6f8c23cdd00964192bedc38af3e82463978aa611b4365bd33a0f
1f4f3e97.svg]
[exploding-head-daceb38d627e6ae9b730f36a1e390fca556a4289d5a41abb2c35068
ad3e2c4b5.svg]
[raised-hands-74b2099fd66a39f2d7eed9305ee0f4553df0eb7b4f11b01b6b1b49997
3048fe5.svg]
[fire-f60e7a582391810302117f987b22a8ef04a2fe0df7e3258a5f49332df1cec71e.
svg]
In defense of the modern web
[16]#javascript [17]#react [18]#svelte [19]#webdev
I expect I'll annoy everyone with this post: the anti-JavaScript
crusaders, justly aghast at how much of the stuff we slather onto
modern websites; the people arguing the web is a broken platform for
interactive applications anyway and we should start over; React users;
the old guard with their artisanal JS and hand authored HTML; and
[20]Tom MacWright, someone I've admired from afar since I first became
aware of his work on Mapbox many years ago. But I guess that's the
price of having opinions.
Tom recently posted [21]Second-guessing the modern web, and it took the
front end world by storm. You should read it, or at the very least the
[22]CliffsNotes. There's a lot of stuff I agree with to varying
degrees:
There is a sweet spot of React: in moderately interactive interfaces
... But theres a lot on either side of that sweet spot.
It's absolutely the case that running React in the client for a largely
static site is overkill. It's also true that you have to avoid React if
your app is very heavily interactive — it's widely understood that if
you want 60fps animation, you will likely have to bypass the React
update cycle and do things in a more imperative fashion (indeed, this
is what libraries like [23]react-spring do). But while all this is true
of React, it's much less true of component frameworks in general.
User sessions are surprisingly long: someone might have your website
open in a tab for weeks at a time. Ive seen it happen. So if they
open the about page, keep the tab open for a week, and then
request the home page, then the home page that they request is
dictated by the index bundle that they downloaded last week. This is
a deeply weird and under-discussed situation.
It's an excellent point that isn't really being addressed, though (as
Tom acknowledges) it's really just exacerbating a problem that was
always there. I think there are solutions to it — we can iterate on the
'index bundle' approach, we could include the site version in a cookie
and use that to show actionable feedback if there's a mismatch — but we
do need to spend time on it.
Its your startups homepage, and it has a “Sign up” button, but
until the JavaScript loads, that button doesnt do anything. So you
need to compensate.
This is indeed very annoying, though it's easy enough to do this sort
of thing — we just need to care enough:
<button class="sign-up" disabled={!is_browser}>
{is_browser ? 'Sign up' : 'Loading'}
</button>
But I'm not sure what this has to do with React-style frameworks — this
issue exists whatever form your front end takes, unless you make it
work without JS (which you should!).
Your formerly-lightweight application server is now doing quite a
bit of labor, running React & making API requests in order to do
this pre-rendering.
Again, this is true but more React-specific than anything. React's
approach to server-side rendering — constructing a component tree, then
serialising it — involves overhead that isn't shared by frameworks
that, for example, compile your components ([24]hi!) to functions that
just concatenate strings for SSR, which is faster by a dramatic amount.
And those API requests were going to have to get made anyway, so it
makes sense to do them as early as possible, especially if your app
server and API server are close to each other (or even the same thing).
The dream of APIs is that you have generic, flexible endpoints upon
which you can build any web application. That idea breaks down
pretty fast.
Amen. [25]Just go and read the whole 'APIs' section several times.
__________________________________________________________________
Minor quibbles aside, Tom identifies some real problems with the state
of the art in web development. But I think the article reaches a
dangerous conclusion.
Let's start by dissecting this statement:
I can, for example, guarantee that this blog is faster than any
Gatsby blog (and much love to the Gatsby team) because there is
nothing that a React static site can do that will make it faster
than a non-React static site.
With all due respect to those involved, I don't think Gatsby is a
particularly relevant benchmark. The gatsby new my-site starter app
executes 266kB of minified JavaScript for a completely static page in
production mode; for [26]gatsbyjs.org it's 808kB. Honestly, these are
not impressive numbers.
[27]The Lighthouse performance score for gatsbyjs.org
The [28]Lighthouse score for Gatsby's homepage, obtained via
[29]webpagetest.org/easy.
Leaving that aside, I disagree with the premise. When I tap on a link
on Tom's JS-free website, the browser first waits to confirm that it
was a tap and not a brush/swipe, then makes a request, and then we have
to wait for the response. With a framework-authored site with
client-side routing, we can start to do more interesting things. We can
make informed guesses based on analytics about which things the user is
likely to interact with and preload the logic and data for them. We can
kick off requests as soon as the user first touches (or hovers) the
link instead of waiting for confirmation of a tap — worst case
scenario, we've loaded some stuff that will be useful later if they do
tap on it. We can provide better visual feedback that loading is taking
place and a transition is about to occur. And we don't need to load the
entire contents of the page — often, we can make do with a small bit of
JSON because we already have the JavaScript for the page. This stuff
gets fiendishly difficult to do by hand.
Beyond that, vanilla static sites are not an ambitious enough goal.
Take transitions for example. Web developers are currently trapped in a
mindset of discrete pages with jarring transitions — click a link, see
the entire page get replaced whether through client-side routing or a
page reload — while native app developers are thinking on another
level:
unknown tweet media content Play butt
Ryan Florence profile image
Ryan Florence
[30]@ryanflorence
twitter logo
This is what I've had in mind for the web with React Router. We say
these kinds of animations are "good for phones but not desktop".
My iPad pro is as big as my laptop and these apps are shopping/content
(most of the web).
These transitions are such a great UX.
16:06 PM - 22 Oct 2019
[31]Twitter reply action [32]Twitter retweet action 20 [33]Twitter like
action 197
It will take more than technological advancement to get the web there;
it will take a cultural shift as well. But we certainly can't get there
if we abandon our current trajectory. Which is exactly what Tom seems
to be suggesting.
__________________________________________________________________
I'm not aware of any other platform where you're expected to write the
logic for your initial render using a different set of technologies
than the logic for subsequent interactions. The very idea sounds daft.
But on the web, with its unique history, that was the norm for many
years — we'd generate some HTML with PHP or Rails or whatever, and then
'sprinkle some jQuery' on it.
With the advent of Node, that changed. The fact that we can do
server-side rendering and communicate with databases and what-have-you
using a language native to the web is a wonderful development.
There are problems with this model. Tom identifies some of them.
Another major issue he doesn't discuss is that the server-rendered SPA
model typically 'hydrates' the entire initial page in a way that
requires you to duplicate a ton of data — once in the HTML, once in the
JSON blob that's passed to the client version of the app to produce the
exact same result — and can block the main thread during the period the
user is starting to interact with the app.
But we can fix those problems. [34]Next is doing amazing innovation
around (for example) mixing static and dynamic pages within a single
app, so you get the benefits of the purely static model without ending
up finding yourself constrained by it. [35]Marko does intelligent
component-level hydration, something I expect other frameworks to
adopt. [36]Sapper, the companion framework to [37]Svelte, has a stated
goal of eventually not sending any JS other than the (tiny) router
itself for pages that don't require it.
The future I want — the future I see — is one with tooling that's
accessible to the greatest number of people (including designers), that
can intelligently move work between server and client as appropriate,
that lets us build experiences that compete with native on UX (yes,
even for blogs!), and where upgrading part of a site to 'interactive'
or from 'static' to 'dynamic' doesn't involve communication across
disparate teams using different technologies. We can only get there by
committing to the paradigm Tom critiques — the JavaScript-ish component
framework server-rendered SPA. (Better names welcomed.)
The modern web has flaws, and we should talk about them. But let's not
give up on it.
Top comments (98)
(BUTTON) Crown
Sort discussion:
* Top
Most upvoted and relevant comments will be first
* Latest
Most recent comments will be first
* Oldest
The oldest comments will be first
Subscribe
pic
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
(BUTTON) Personal (BUTTON) Trusted User
[38]Create template
Templates let you quickly answer FAQs or store snippets for re-use.
(BUTTON) Submit (BUTTON) Preview [39]Dismiss
[40]twigman08 profile image
[41]Chad Smith
(BUTTON) Chad Smith
[42]Chad Smith
(button) Follow
Work with C# all day everyday creating web applications. Huge baseball
buff.
* Location
Texas
* Education
B.S in Computer Science
* Joined
Dec 17, 2017
• [43]May 15 '20
(BUTTON)
* [44]Copy link
*
* (BUTTON) Hide
*
*
*
Honestly my biggest issue with the current state of the web is the
current state of how complex the tools or build process is.
I miss the days of some html, add a bit of JavaScript to the page and
you were done. You didn't worry about going and making sure you had a
complete build or bundling process to get everything good. You spent
your time worrying about how to develop your app. Which in my opinion
was better for the users. There was less bugs. We actually spent more
time making sure the application worked rock solid.
Nowadays to get anything cool to be be ready for production you have
spend needless time on the configuration. Did you do this? Did you
configure it to do that? Oh you can't do that unless you eject it that
build tool and use this build tool. That's where the current state of
the web is failing.
Sure we have taken steps forward in some areas. But we have to be
honest with ourselves. We took major steps back in other areas of the
web. Sometimes I wonder if we took too many steps back.
(BUTTON) 61 likes Like Reply
[45]gotofritz profile image
[46]fritz
(BUTTON) fritz
[47]fritz
(button) Follow
* Location
Berlin
* Joined
Sep 28, 2018
• [48]May 18 '20
(BUTTON)
* [49]Copy link
*
* (BUTTON) Hide
*
*
*
I don't get it. Nobody's stopping you from firing up an HTML doc in
Notepad and FTPing the result to a web server, if that's all you need.
But other people have more complex needs (in the "good ole days" there
were no smart phones, to mention just one thing) and therefore we need
more complex tools. Why do you want to force me to party like it's
1999?
(BUTTON) 23 likes Like Reply
[50]twigman08 profile image
[51]Chad Smith
(BUTTON) Chad Smith
[52]Chad Smith
(button) Follow
Work with C# all day everyday creating web applications. Huge baseball
buff.
* Location
Texas
* Education
B.S in Computer Science
* Joined
Dec 17, 2017
• [53]May 19 '20
(BUTTON)
* [54]Copy link
*
* (BUTTON) Hide
*
*
*
My issue isn't with applications are too complex really. I develop
complex applications too at work.
My issue is with all the moving parts with a modern web application.
Fighting if I can use certain language features. Oh I can't, now I have
to bother with setting up and making sure I can use Babel or something
to do it properly, or even loading in polyfills (cool just added
another dependency the browser has to load before the application can
be used).
That still hasn't covered bundling everything. What's the correct way
bundle this? Well crap I now have to go and correctly configure
WebPack. Unless you're one of the VERY FEW experts on that ,that will
take time to figure out to get right. Ok so I think it bundles right,
well now how should I lazy load this code for the user? What should be
lazy loaded? What should i use to set it up?
That's just the beginning. I could go on and on about the other complex
moving parts with a modern web application.
I am not asking anyone to make applications like it is 1999. All I'm
asking for is a more modern and simpler process that is a STANDARD.
Maybe it is because I come from compiled language background. Where I
have to worry about that one single binary. I only have to worry if the
compiler supports the language version I'm using. Where I can just pass
in a single flag to the compiler for the optimization level I want.
Yes I will be the first to say that in some areas of modern web
application development we have taken steps forward. I just wonder if
we have taken steps back in some areas to take those steps forward.
(BUTTON) 13 likes Like Thread
[55]gotofritz profile image
[56]fritz
(BUTTON) fritz
[57]fritz
(button) Follow
* Location
Berlin
* Joined
Sep 28, 2018
• [58]May 22 '20 • Edited on May 22 • Edited
(BUTTON)
* [59]Copy link
*
* (BUTTON) Hide
*
*
*
All I'm asking for is a more modern and simpler process that is a
STANDARD ...
Maybe it is because I come from compiled language background ...
Well I am sorry, but web development is a complete different kettle of
fish. We download all the parts that make up an application
asynchronously, on a wide variety of devices, with different specs and
rendering capabilities - all things which the app, once downloaded,
need to adapt to. We have progressive rendering and respond to all sort
of sensors. All while ensuring boot up time for the app is in the
microseconds range and security for both you who download the code and
the server.
Your expectations are simply unrealistic, sorry.
Also, we always had polyfills, even "back in the day". Except that back
then everyone had to bake their own. In fact, we had browser wars and
appalling browser (IE5 for the Mac, anyone??!?) and it was a real pain
in the neck.
(BUTTON) 10 likes Like Reply
[60]adrianus profile image
[61]Adrianus
(BUTTON) Adrianus
[62]Adrianus
(button) Follow
Running a small company based in Kent.
* Location
Chatham, Kent
* Education
autodidactic
* Work
Entrepreneur at AVANDERGRINTEN Ltd.
* Joined
Jan 21, 2020
• [63]May 19 '20 • Edited on May 20 • Edited
(BUTTON)
* [64]Copy link
*
* (BUTTON) Hide
*
*
*
Bingo, the complexity today is a must, at least because of the growing
smartphone usage. The simple reason why "Native Apps didn't kill the
web even with all their superior capabilities" (Ryan) is simply UX. As
internet usage often starts with searching for something having in
mind, that all-app-thinking interrupts exactly this flow, leaving at
least 30% of all traffic untouched. For what? For 5-minutes-crafts
skyrocketing their YouTube traffic? Although not everything needs
server side complexity plus having API's and webhooks easily integrated
using browser capabilities not existing in the god old days, the
architecture underneath is not the real issue.
(BUTTON) 3 likes Like Reply
[65]techbelle profile image
[66]rachelle palmer
(BUTTON) rachelle palmer
[67]rachelle palmer
(button) Follow
I decided I would try to build an app in every programming language.
That didn't happen, but what I learned along the way was really
valuable.
* Location
Raleigh, NC
* Joined
Sep 23, 2020
• [68]Feb 25 '21
(BUTTON)
* [69]Copy link
*
* (BUTTON) Hide
*
*
*
re: sessions --> I keep tabs open for months at a time, not sure about
anyone else
(BUTTON) 1 like Like Reply
[70]ojrask profile image
[71]Otto Rask
(BUTTON) Otto Rask
[72]Otto Rask
(button) Follow
A software engineer, mainly PHP, Rust, and related things.
* Location
Finland
* Joined
Mar 12, 2019
• [73]May 28 '21
(BUTTON)
* [74]Copy link
*
* (BUTTON) Hide
*
*
*
You fight complexity with ... more complexity?
(BUTTON) 1 like Like Thread
[75]gotofritz profile image
[76]fritz
(BUTTON) fritz
[77]fritz
(button) Follow
* Location
Berlin
* Joined
Sep 28, 2018
• [78]May 28 '21
(BUTTON)
* [79]Copy link
*
* (BUTTON) Hide
*
*
*
You are getting it wrong. The aim is not "to fight complexity". The aim
is to fulfil complex needs. I am saying for that you often need more
complex tools.
(BUTTON) 1 like Like Thread
[80]ojrask profile image
[81]Otto Rask
(BUTTON) Otto Rask
[82]Otto Rask
(button) Follow
A software engineer, mainly PHP, Rust, and related things.
* Location
Finland
* Joined
Mar 12, 2019
• [83]May 28 '21
(BUTTON)
* [84]Copy link
*
* (BUTTON) Hide
*
*
*
What percentage of modern web is a "complex needs" target that requires
a complex solution such as React or Vue or perhaps something custom
written in WASM? 50% 25%? 5% 1%?
(BUTTON) 2 likes Like Thread
[85]gotofritz profile image
[86]fritz
(BUTTON) fritz
[87]fritz
(button) Follow
* Location
Berlin
* Joined
Sep 28, 2018
• [88]May 28 '21
(BUTTON)
* [89]Copy link
*
* (BUTTON) Hide
*
*
*
All of it. Unless you have actual data that proves otherwise...
(BUTTON) 2 likes Like Thread
[90]jacobmakestheweb profile image
[91]Jacob Ybarra
(BUTTON) Jacob Ybarra
[92]Jacob Ybarra
(button) Follow
dank web dev
* Education
school
* Work
nada
* Joined
Sep 21, 2021
• [93]Sep 21 '21
(BUTTON)
* [94]Copy link
*
* (BUTTON) Hide
*
*
*
uh what? the web is about content and media. not a software
environment.
(BUTTON) 1 like Like Reply
[95]mark_saward profile image
[96]Mark Saward
(BUTTON) Mark Saward
[97]Mark Saward
(button) Follow
CEO and Developer | PhD in Philosophy | Some things I like: Linux, Go,
Rust, SQL, Devops
* Location
Victoria, Australia
* Education
BA/Bsc in Philosophy and Physics. PhD in Philosophy.
* Work
CEO/Software Developer at Episub
* Joined
May 13, 2020
• [98]May 15 '20
(BUTTON)
* [99]Copy link
*
* (BUTTON) Hide
*
*
*
Some interesting thoughts, in the original article and your response.
Certainly good for generating discussion :)
It will take more than technological advancement to get the web
there; it will take a cultural shift as well. But we certainly can't
get there if we abandon our current trajectory.
The problem as I see it is that the web -- in terms of client-side
executed markup and code (HTML/CSS/JavaScript) just wasn't designed
with these kinds of interactions in mind (the interactions that Ryan
Florence highlighted). It's the wrong foundation for it.
I don't think that "getting there" should be through bending original
web technologies, but rather with something else entirely -- perhaps
WebAssembly, or a return to actual native applications much like we've
come to depend on on our tablets and phones. We already can do nice
animations like that iPad demo with native desktop applications.
There's many advantages to websites over native desktop apps, with the
standout one being that they don't require someone to install an
application on their machine. Maybe WebAssembly can give us a
compromise -- desktop apps built with technology designed for that job,
but available in a way that doesn't require any local installation.
Then we can use tools that were purpose built for those kinds of tasks,
instead of trying to wrangle the foundations of the web to fit
something they were never built for.
When I think back to how we used to build websites back in the day, and
how we build sites with technologies in tools like React now, I'm
honestly not sure that we've gained anything of great enough value
relative to the simplicity we've lost. In short, I'd be happy to
abandon our current trajectory and put our hope in alternative
solutions for those situations where what we really need is a native
application. Leave the web for what it's good at.
(BUTTON) 23 likes Like Reply
[100]ryansolid profile image
[101]Ryan Carniato
(BUTTON) Ryan Carniato
[102]Ryan Carniato
(button) Follow
Frontend performance enthusiast and Fine-Grained Reactivity super fan.
Author of the SolidJS UI library and MarkoJS Core Team Member.
* Location
San Jose, California
* Education
Computer Engineering B.A.Sc, University of British Columbia
* Work
Principal Engineer, Open Source, Netlify
* Joined
Jun 25, 2019
• [103]May 15 '20
(BUTTON)
* [104]Copy link
*
* (BUTTON) Hide
*
*
*
That's interesting. I mean I was there too, and the extent of what I
can build with a modern library so extends what I could reasonably do
before. And the reason for that is JavaScript. When I was building
sites in the late 90s so many things weren't possible and you had no
choice but to pay these costs for interactivity. Sure I view sourced a
few cool tricks.. image maps etc, but with my table based layouts and a
little JavaScript I could do very little. Part of it was the available
DOM api's. My lack of understanding of the language but I think we look
at the past with rose colored glasses.
It's more interesting to me that native platforms have borrowed
concepts from libraries like React in terms of declarative views etc.
I'm not saying React invented this stuff but that the trend would
suggest the contrary. These trends could be mistakes but popularity has
as much stake in the course of events as innate value.
I think this comes down to really this hope of a Silver Bullet. It
doesn't exist. Instead we have momentum of a ubiquitous platform that
just is constantly aiming to improve. It's not only that the other
approaches have already lost, we're getting to a point where any new
approach will have to atleast acknowledge the current web. At this
point a competitor isn't going to change the tide, but something from
within. It's more likely that the web addresses those fundamental
shortcomings than people moving to a different platform. Native Apps
didn't kill the web even with all their superior capabilities. And on a
similar note it is going to take monumental change for this to
fundamentally change. Even with React's reach, it wasn't alone in a
movement that started years before. This is bigger than any particular
library or framework.
(BUTTON) 13 likes Like Reply
[105]mark_saward profile image
[106]Mark Saward
(BUTTON) Mark Saward
[107]Mark Saward
(button) Follow
CEO and Developer | PhD in Philosophy | Some things I like: Linux, Go,
Rust, SQL, Devops
* Location
Victoria, Australia
* Education
BA/Bsc in Philosophy and Physics. PhD in Philosophy.
* Work
CEO/Software Developer at Episub
* Joined
May 13, 2020
• [108]May 16 '20 • Edited on May 16 • Edited
(BUTTON)
* [109]Copy link
*
* (BUTTON) Hide
*
*
*
There is absolutely no doubt that you can do incredible things with
modern web, and the power unlocked by having a programming language in
the browser has been amazing. However, when I think about a great deal
of the websites I interact with, and ones I build, there would not be
much lost if they significantly simplified the tech stack they work
with to be closer to the core technologies of the web (including a
splash of JavaScript).
What I'm trying to convey is that I think our move to make everything a
web app has been a mistake, for multiple reasons. You are absolutely
right to say that this tide is going to be very hard (perhaps
impossible) to turn, and I absolutely agree there is no silver bullet
(I've looked), but that doesn't mean we haven't taken a worse path and
shouldn't lament for what could have been.
The advantages of web apps are compelling for developers -- they are
easy to distribute, update, control, make cross platform, when compared
to native apps. It is not hard to understand why and how we have ended
up where we are. I just wish we were somewhere else -- but it would
take a lot of work to create that 'silver bullet'.
(BUTTON) 11 likes Like Thread
[110]adrianus profile image
[111]Adrianus
(BUTTON) Adrianus
[112]Adrianus
(button) Follow
Running a small company based in Kent.
* Location
Chatham, Kent
* Education
autodidactic
* Work
Entrepreneur at AVANDERGRINTEN Ltd.
* Joined
Jan 21, 2020
• [113]May 19 '20 • Edited on May 20 • Edited
(BUTTON)
* [114]Copy link
*
* (BUTTON) Hide
*
*
*
That whole app environment was basically triggered by one need, and one
need only: bandwidth. No idea if anyone remembers when they launched
this WAP protocol, making the internet available on smartphones, what
failed for two reasons. The providers made it easy to access on their
own portals aka AOL strategy at beginning of the web, leaving the rest
of the market untouched, secondly the site performance was ridiculous.
Apple stepped in, put a bunch of intelligence into the app,
dramatically reducing the load time, did not convert so much traffic on
their own apps and let developers do what they do best. By 2008 more
than 50% of the whole mobile internet traffic was iPhone traffic.
Bandwidth is no longer the breaking point.
Google has for years campaigned the untapped goldmine local traffic,
experience flows that often start at the search for getting something
done in time, monetising on micro moments as more than half of all
mobile searches have a local intend. I posted an example how something
to get done interferes cross-applicational from the perspective of a
user. With an app-only scheme this is getting impossible. Sure it is
understandable that nobody pays so much attention. Most search engines
run a change and heavily invested in AI to optimise traffic at the
client's frontend. But even this is not enough, when it comes to
intends other than something very individualised. I wouldn't care so
much about the user, but more about what the user wants to achieve.
(BUTTON) 1 like Like Reply
[115]oenonono profile image
[116]Junk
(BUTTON) Junk
[117]Junk
(button) Follow
* Joined
Mar 12, 2017
• [118]May 17 '20
(BUTTON)
* [119]Copy link
*
* (BUTTON) Hide
*
*
*
React definitely didn't invent HTML.
Declarative views, indeed.
(BUTTON) 1 like Like Reply
[120]v6 profile image
[121]🦄N B🛡
(BUTTON) 🦄N B🛡
[122]🦄N B🛡
(button) Follow
// , “It is not so important to be serious as it is to be serious about
the important things. The monkey wears an expression of seriousness...
but the monkey is serious because he itches."(No/No)
* Location
(No/No)
* Education
(No/No)
* Work
Security
* Joined
Mar 1, 2018
• [123]May 15 '20
(BUTTON)
* [124]Copy link
*
* (BUTTON) Hide
*
*
*
The problem as I see it is that the web -- in terms of client-side
executed markup and code (HTML/CSS/JavaScript) just wasn't designed
with these kinds of interactions in mind (the interactions that Ryan
Florence highlighted). It's the wrong foundation for it.
Yes. Please. Can we please just accept that it's all broken.
(BUTTON) 4 likes Like Reply
[125]gotofritz profile image
[126]fritz
(BUTTON) fritz
[127]fritz
(button) Follow
* Location
Berlin
* Joined
Sep 28, 2018
• [128]May 18 '20 • Edited on May 18 • Edited
(BUTTON)
* [129]Copy link
*
* (BUTTON) Hide
*
*
*
Not at all.
CSS has media queries and all sort of crazy and wonderful stuff. HTML
has tags for responsive design. JS has (in the browser) access to apis
like mutation observer and orientation and speech recognition. It's
TOTALLY built for that. Enough of the "get off my lawn" negativity
(BUTTON) 8 likes Like Thread
[130]v6 profile image
[131]🦄N B🛡
(BUTTON) 🦄N B🛡
[132]🦄N B🛡
(button) Follow
// , “It is not so important to be serious as it is to be serious about
the important things. The monkey wears an expression of seriousness...
but the monkey is serious because he itches."(No/No)
* Location
(No/No)
* Education
(No/No)
* Work
Security
* Joined
Mar 1, 2018
• [133]May 18 '20 • Edited on May 18 • Edited
(BUTTON)
* [134]Copy link
*
* (BUTTON) Hide
*
*
*
shakes his cane at you
mutters incomprehensibly
(BUTTON) 4 likes Like Reply
[135]stew_sims profile image
[136]Stewart Sims
(BUTTON) Stewart Sims
[137]Stewart Sims
(button) Follow
* Joined
May 31, 2019
• [138]May 15 '20 • Edited on May 15 • Edited
(BUTTON)
* [139]Copy link
*
* (BUTTON) Hide
*
*
*
There's a lot to agree with in both of these takes. However, one
criticism of this one (and I realise we're getting into hugely
subjective territory) is the assumption that the goal should be to
'build experiences that compete with native on UX'. It strikes me that
the web never was and never will be anything like any other platform
for building applications. Whether or not someone wants to turn it into
that is their prerogative and any success they have probably will help
others build better things. But it ultimately depends on what you want
to build and why, and emulating a native application might not always
be the best option. I think the key is to allow ourselves to question
the assumptions we all hold which seems to be exactly what both of you
are doing with different approaches, reaching different conclusions. So
I would say; keep doing that and keep doing your thing, but just don't
expect everyone to agree and do things the same way. The world is a
better place when we allow and encourage people not to homogenise in
their thinking.
(BUTTON) 34 likes Like Reply
[140]rhymes profile image
[141]rhymes
(BUTTON) rhymes
[142]rhymes
(button) Follow
Such software as dreams are made on. I mostly rant about performance,
unnecessary complexity, privacy and data collection.
* Joined
Feb 2, 2017
• [143]May 18 '20 • Edited on May 18 • Edited
(BUTTON)
* [144]Copy link
*
* (BUTTON) Hide
*
*
*
It strikes me that the web never was and never will be anything like
any other platform for building applications. Whether or not someone
wants to turn it into that is their prerogative and any success they
have probably will help others build better things. But it
ultimately depends on what you want to build and why, and emulating
a native application might not always be the best option.
this :-)
(BUTTON) 5 likes Like Reply
[145]oenonono profile image
[146]Junk
(BUTTON) Junk
[147]Junk
(button) Follow
* Joined
Mar 12, 2017
• [148]May 17 '20
(BUTTON)
* [149]Copy link
*
* (BUTTON) Hide
*
*
*
points up
(BUTTON) 1 like Like Reply
[150]holdit profile image
[151]holdit
(BUTTON) holdit
[152]holdit
(button) Follow
* Joined
May 15, 2020
• [153]May 15 '20
(BUTTON)
* [154]Copy link
*
* (BUTTON) Hide
*
*
*
Looking at the criticism made about some recent redesigns (reddit,
facebook, etc) it seems that the main complaint (from a user point of
view, at least) is how slow it feels compared to the previous version
or to a "simple" site with HTML, CSS, and a little bit of javascript.
I haven't checked it recently, but when the new reddit UI was released,
scrolling was terrible on my $2500k laptop. It felt slow. Everything
was sluggish. It also downloaded a few MB of javascript on pages that
essentially had a thumbnail, a title, and some comments (not everyone
lives in a big city or is connected to a super fast internet
connection!). When the page was loaded, I was seeing more scrolling lag
because they lazyload some content. I mean, it's hard to like this
"modern web".
As a user, I don't care about how things work behind the scenes. I
don't mind some javascript on a page, after all we don't need a page
reload just to preview a comment or "like" something. You can even use
javascript for everything, I don't mind. But it needs to be fast and it
needs to work well... and right now some "modern" sites provide a worse
experience than before.
(BUTTON) 24 likes Like Reply
[155]iamschulz profile image
[156]Daniel Schulz
(BUTTON) Daniel Schulz
[157]Daniel Schulz
(button) Follow
Hi! I'm a frontend guy.
* Location
Germany
* Education
Studied Media Art and Design
* Work
Performance Engineer at Baqend
* Joined
Sep 17, 2018
• [158]May 15 '20 • Edited on May 15 • Edited
(BUTTON)
* [159]Copy link
*
* (BUTTON) Hide
*
*
*
Tom identified the main weakness of modern web development correctly:
It's based on javascript. He points out the sluggishness and
accessibility problems that stem from that attitude, and hes absolutely
right to do so. Static pages (as a paradigm, not as Gatsby in
particular) are maybe not the cure for that, but they are definitely a
step into the right direction.
I just rewrote my website with hugo and specifically without a major JS
framework, but settled for a vanilla approach rooted in a progressive
enhancement mindset. I didn't even run into the problems that are
inherent to React, Vue and Angular.
Sure, you can serve HTML with SSR, but you still have to wait for the
bundle in order to have a functional site, plus a truckload of
ssr-related complexity. And that is utter rubbish. JS should never be a
requirement, it needs to be put in its place as the cherry on top of
the cake.
Progressive enhancement needs not only to be a major approach to
webdevelopment again, it needs to be out default mode of operation.
This is also the core of Toms article. And I agree with him.
That said, nothing stops you from adding features like nice
transitions. But please be sure not to break standard web features
while doing so.
Transitions need to add to hyperlinks, not replace them.
(BUTTON) 21 likes Like Reply
[160]richharris profile image
[161]Rich Harris
(BUTTON) Rich Harris
[162]Rich Harris
(button) Follow
I like turtles
* Location
Behind you
* Work
Graphics editor at the New York Times
* Joined
Jun 20, 2019
• [163]May 15 '20
(BUTTON)
* [164]Copy link
*
* (BUTTON) Hide
*
*
*
I feel like you didn't quite read the article closely enough ;) Of
course progressive enhancement needs to be the default — that's why
there's so much focus on SSR in all major meta-frameworks.
Sure, you can serve HTML with SSR, but you still have to wait for
the bundle in order to have a functional site
This isn't true! Take [165]sapper.svelte.dev, which is a site built
with Sapper and baked out as static pages. It works just fine without
JavaScript, you just don't get client-side routing. It's a small site,
but the same thing applies to larger ones like Gatsby's homepage — no
JS? No problem.
(BUTTON) 20 likes Like Reply
[166]iamschulz profile image
[167]Daniel Schulz
(BUTTON) Daniel Schulz
[168]Daniel Schulz
(button) Follow
Hi! I'm a frontend guy.
* Location
Germany
* Education
Studied Media Art and Design
* Work
Performance Engineer at Baqend
* Joined
Sep 17, 2018
• [169]May 15 '20
(BUTTON)
* [170]Copy link
*
* (BUTTON) Hide
*
*
*
It certainly is true for standard implementations of React-, Vue- and
Angular- based sites. There may be a focus on SSR, but it still isn't
close enough to deserve to be the default. It needs to come without
extra complexity. Only then we're ready to take the step to fully
embrace those solution.
And this is my point. You need to take one step after the other. It was
a mistake to build everything with javascript first and then try to
look if it still works without afterwards. The damage to the web has
been done.
I didn't take a look at Sapper/Svelte. Though, in comparison, those are
still a nieche product.
(BUTTON) 7 likes Like Thread
[171]martinmalinda profile image
[172]Martin Malinda
(BUTTON) Martin Malinda
[173]Martin Malinda
(button) Follow
* Joined
Apr 7, 2020
• [174]May 18 '20
(BUTTON)
* [175]Copy link
*
* (BUTTON) Hide
*
*
*
The damage to the web has been done.
JS certainly caused a lot of damage on many websites. But now - finally
- we're getting to the point of having frameworks which can, by
default, offer client-side routing with SSR and hydration without
shipping large bundles of JS. Up to this point the frontend devs should
have been more conservative and they should have thought twice whether
they should really go all-in into an SPA. But now's the time when it's
really starting to be a viable option. Next, Nuxt, Marko and Sapper are
finally technologies highly worth pursuing, even for content-based
websites.
(BUTTON) 2 likes Like Reply
[176]ben profile image
[177]Ben Halpern
(BUTTON) Ben Halpern
[178]Ben Halpern
(button) Follow
A Canadian software developer who thinks hes funny.
* Email
[179]ben@forem.com
* Location
NY
* Education
Mount Allison University
* Pronouns
He/him
* Work
Co-founder at Forem
* Joined
Dec 27, 2015
• [180]May 15 '20
(BUTTON)
* [181]Copy link
*
* (BUTTON) Hide
*
*
*
The future I want — the future I see — is one with tooling that's
accessible to the greatest number of people (including designers),
that can intelligently move work between server and client as
appropriate, that lets us build experiences that compete with native
on UX (yes, even for blogs!), and where upgrading part of a site to
'interactive' or from 'static' to 'dynamic' doesn't involve
communication across disparate teams using different technologies.
We can only get there by committing to the paradigm Tom critiques —
the JavaScript-ish component framework server-rendered SPA. (Better
names welcomed.)
I like this takeaway because it's heavy on acknowledging the process
behind the technology which is often disparate and confusing. Even the
most well-intentioned and organized dev team is going to get out of
wack if succeeding with the tooling is experts only. We need to be able
to achieve great performance, UX and accessibility even under
conditions where designers do some work, devs pop in some hotfixes here
and there, old devs leave with some of the knowledge, priorities
change, etc.
(BUTTON) 19 likes Like Reply
[182]v6 profile image
[183]🦄N B🛡
(BUTTON) 🦄N B🛡
[184]🦄N B🛡
(button) Follow
// , “It is not so important to be serious as it is to be serious about
the important things. The monkey wears an expression of seriousness...
but the monkey is serious because he itches."(No/No)
* Location
(No/No)
* Education
(No/No)
* Work
Security
* Joined
Mar 1, 2018
• [185]May 15 '20 • Edited on May 15 • Edited
(BUTTON)
* [186]Copy link
*
* (BUTTON) Hide
*
*
*
I like this aspect of Mr. Harris' article, too. It's the first
principle of the Tao of HashiCorp: [187]Workflows, not Technologies.
The HashiCorp approach is to focus on the end goal and workflow,
rather than the underlying technologies. Software and hardware will
evolve and improve, and it is our goal to make adoption of new
tooling simple, while still providing the most streamlined user
experience possible. Product design starts with an envisioned
workflow to achieve a set goal. We then identify existing tools that
simplify the workflow. If a sufficient tool does not exist, we step
in to build it. This leads to a fundamentally technology-agnostic
view — we will use the best technology available to solve the
problem. As technologies evolve and better tooling emerges, the
ideal workflow is just updated to leverage those technologies.
Technologies change, end goals stay the same.
And it's why Sacrificial Architecture appeases the dark ones.
(BUTTON) 4 likes Like Reply
[188]phlash profile image
[189]Phil Ashby
(BUTTON) Phil Ashby
[190]Phil Ashby
(button) Follow
30+ years of tech, retired from an identity intelligence company, job
done! Dev community mod - mostly light gardening & weeding out spam :)
* Location
Felixstowe, UK
* Education
M.Eng (hons) Electronics, MIET, MBCS, AMCIISec, CEH
* Pronouns
he/him
* Work
Retired!
* Joined
Apr 2, 2017
• [191]May 15 '20
(BUTTON)
* [192]Copy link
*
* (BUTTON) Hide
*
*
*
Good response, opinions are always worth having, as long as you are
prepared to discuss/defend/change them! I had a few thoughts on this
topic last year in response to your good self and web components that I
think is worth referring back to: [193]dev.to/phlash909/comment/cghl
In essence, the DOM and page model of HTML is a constraint around the
outside of applications that might be better inverted: I'd like to see
browsers that support HTML/DOM content if required, but do not
constrain devs to always go though it. Let's stop thinking of them as
HTML rendering engines, and start thinking of pre-installed runtimes
with excellent web-based application management!
We'll want to retain the benefits of dynamic software running on the
client (native UX, easy architecture changes, no user-install step,
etc.), while leveraging the effort that goes into making that a
portable & safe thing to do (common APIs, sandboxes, browsers as the
standard runtime for client-side applications). We are nearly there
with PWAs perhaps? WASM then expands the available languages for the
runtime, allowing common client/server languages and development
processes to ease developer adoption. As/when a document needs
rendering, then HTML/DOM/CSS is there to perform it's proper function,
however many apps many be better off with a UX library (eg: SDL) or
widget set (eg: wxWidgets) atop the runtime bindings.
(BUTTON) 11 likes Like Reply
[194]v6 profile image
[195]🦄N B🛡
(BUTTON) 🦄N B🛡
[196]🦄N B🛡
(button) Follow
// , “It is not so important to be serious as it is to be serious about
the important things. The monkey wears an expression of seriousness...
but the monkey is serious because he itches."(No/No)
* Location
(No/No)
* Education
(No/No)
* Work
Security
* Joined
Mar 1, 2018
• [197]May 15 '20
(BUTTON)
* [198]Copy link
*
* (BUTTON) Hide
*
*
*
start thinking of pre-installed runtimes with excellent web-based
application management!
If you were to remove the "web-based" part, it'd almost describe the
beginning of OSes back in the day.
Which is perhaps what they are: The UI part of a vast "operating
system" by which we access the "applications" of the internet.
(BUTTON) 4 likes Like Reply
[199]panesofglass profile image
[200]panesofglass
(BUTTON) panesofglass
[201]panesofglass
(button) Follow
* Joined
Jul 23, 2020
• [202]Jul 23 '20
(BUTTON)
* [203]Copy link
*
* (BUTTON) Hide
*
*
*
I believe at the point you fundamentally push to render things other
than markup, you start making a different application. And that is
perfectly reasonable. Im frankly surprised how well HTTP has held up
to so many use cases. I long ago expected to see far more protocols for
more kinds of apps, but HTTP seems to have solved so many problems well
enough that it now hosts other protocols.
There are probably more protocols that could be written and hosted on
other ports. Those would likely address many of these issues in a far
better way. I just wonder when the industry will pivot back to building
protocols and leave HTTP well enough alone.
(BUTTON) 1 like Like Reply
[204]rhymes profile image
[205]rhymes
(BUTTON) rhymes
[206]rhymes
(button) Follow
Such software as dreams are made on. I mostly rant about performance,
unnecessary complexity, privacy and data collection.
* Joined
Feb 2, 2017
• [207]Jul 23 '20
(BUTTON)
* [208]Copy link
*
* (BUTTON) Hide
*
*
*
I think we're past that as most recent innovations in the web space are
either formats or evolutions of HTTP. Why reinvent the wheel if the
wheel works well? What do you think?
(BUTTON) 1 like Like Thread
[209]panesofglass profile image
[210]panesofglass
(BUTTON) panesofglass
[211]panesofglass
(button) Follow
* Joined
Jul 23, 2020
• [212]Jul 23 '20
(BUTTON)
* [213]Copy link
*
* (BUTTON) Hide
*
*
*
HTTP/3 with QUIC seems like a great improvement, but it is changing
HTTP. I dont see why HTTP needs changing for most things. Why not
update SMTP or FTP, as well? QUIC solves specific problems, and it
might be better for those who need QUIC for it to have features better
suited to their needs.
In some ways, this also feels like the mash of several formats into
HTML5 to avoid name spacing. While we focus on and champion components
within our own apps, we continue to avoid and break components in the
infrastructure.
Therefore, I think we may see new protocols emerge as the weight of
these complexities begin to cause problems. That could still be some
way off.
(BUTTON) 1 like Like Thread
[214]rhymes profile image
[215]rhymes
(BUTTON) rhymes
[216]rhymes
(button) Follow
Such software as dreams are made on. I mostly rant about performance,
unnecessary complexity, privacy and data collection.
* Joined
Feb 2, 2017
• [217]Jul 23 '20
(BUTTON)
* [218]Copy link
*
* (BUTTON) Hide
*
*
*
I'm not sure it is changing HTTP, it's HTTP over UDP. The protocol is
basically the same as HTTP/1 and HTTP/2.
QUIC solves specific problems, and it might be better for those who
need QUIC for it to have features better suited to their needs.
QUIC solves a specific problem HTTP has because it sits on top of TCP
though, basically pipelining
In some ways, this also feels like the mash of several formats into
HTML5 to avoid name spacing. While we focus on and champion
components within our own apps, we continue to avoid and break
components in the infrastructure.
I'm not sure I follow the analogy with HTML5, sorry :( IIRC HTML5 was
created to stop having to revise HTML as a a single unit and let things
evolve at their own pace. Same with CSS 3 I guess. I don't think it's
the same thing here: HTTP/3 is the result of the entire world using
HTTP and needing to improve performance.
Could they have created a new protocol? Sure, but why break
compatibility with millions of browsers, proxies, machines, software
application and so on that understand and function through HTTP? I
think the decision to rewrite the transport layer to be a smart one.
This doesn't mean that other protocols can't emerge, but it's okay not
to throw away those that work already
(BUTTON) 1 like Like Reply
[219]gregfletcher profile image
[220]Greg Fletcher
(BUTTON) Greg Fletcher
[221]Greg Fletcher
(button) Follow
loop { refactoring() }
* Work
Full Stack at Freelance
* Joined
Mar 16, 2019
• [222]May 15 '20
(BUTTON)
* [223]Copy link
*
* (BUTTON) Hide
*
*
*
Great article!
Doesn't a lot of this disagreement stem from --> "keep the web as it
is, coz it's fine" vs "let's make it better by making mistakes along
the way coz that's how software development works"?
(BUTTON) 14 likes Like Reply
[224]v6 profile image
[225]🦄N B🛡
(BUTTON) 🦄N B🛡
[226]🦄N B🛡
(button) Follow
// , “It is not so important to be serious as it is to be serious about
the important things. The monkey wears an expression of seriousness...
but the monkey is serious because he itches."(No/No)
* Location
(No/No)
* Education
(No/No)
* Work
Security
* Joined
Mar 1, 2018
• [227]May 15 '20
(BUTTON)
* [228]Copy link
*
* (BUTTON) Hide
*
*
*
What about making it better by [229]sacrificing it?
We can [230]learn this lesson from Biology, that the best way to avoid
excessive optimization is the ultimate flexibility: Keeping the option
on the table to throw out the code, or well abstracted parts of it, and
rewrite that code or product from scratch.
It's a little known "dark" pattern of Software Design, from the shadows
of Agile, called "Sacrificial Architecture."
[231]exponential growth isnt kind to architectural decisions
(BUTTON) 5 likes Like Reply
[232]richharris profile image
[233]Rich Harris
(BUTTON) Rich Harris
[234]Rich Harris
(button) Follow
I like turtles
* Location
Behind you
* Work
Graphics editor at the New York Times
* Joined
Jun 20, 2019
• [235]May 15 '20
(BUTTON)
* [236]Copy link
*
* (BUTTON) Hide
*
*
*
Is the Web for applications?
I feel like this question sort of answers itself! Have you heard of
Amazon? Gmail? Facebook?
(BUTTON) 13 likes Like Reply
[237]ben profile image
[238]Ben Halpern
(BUTTON) Ben Halpern
[239]Ben Halpern
(button) Follow
A Canadian software developer who thinks hes funny.
* Email
[240]ben@forem.com
* Location
NY
* Education
Mount Allison University
* Pronouns
He/him
* Work
Co-founder at Forem
* Joined
Dec 27, 2015
• [241]May 15 '20
(BUTTON)
* [242]Copy link
*
* (BUTTON) Hide
*
*
*
My perpective: The web is for applications. The web is also for rich
documents where reading and simple linking can take priority.
And there is an uncanny valley when you the latter is the sensible
choice, but the former is the approach taken.
And many, the web is whatever Google tells them it is. Is AMP the web?
(BUTTON) 22 likes Like Reply
[243]gotofritz profile image
[244]fritz
(BUTTON) fritz
[245]fritz
(button) Follow
* Location
Berlin
* Joined
Sep 28, 2018
• [246]May 22 '20
(BUTTON)
* [247]Copy link
*
* (BUTTON) Hide
*
*
*
We need to have a similar approach in client side frameworks.
No we don't... if the The One True Omniscient God Framework approach
that Rails developers are constantly pining for was really the best
one, then Rails would be ruling. It isn't; it peaked in 2012 or
thereabouts, knocked off its perch by Node, among other technologies.
It's a single point of failure and it cannot adapt quickly enough to
the bewilderingly fast changing environment in which we operate.
Alternatively, you can pick one of the two frameworks that follow the
model you advocate: Ember (actually inspired by Rails) or Angular (more
of a C# flavour), both of which strive to be a nanny that remove as
much as possible the need to (god forbid!) make your own decisions or
(the horror!) having to learn new tools
If I could have the framework of my dreams ... It would allow me to
focus on HTML with a sprinkle of JavaScript.
You may want to consider [248]stimulusjs.org/, which comes from the
Rails universe (it was created by no other than David Heinemeier
Hansson, the Rails Superstar) and does exactly what you want
(BUTTON) 5 likes Like Thread
[249]loilo profile image
[250]Florian Reuschel
(BUTTON) Florian Reuschel
[251]Florian Reuschel
(button) Follow
Web developer (JS, PHP), OSS enthusiast, loves to explain things to
beginners
* Location
Karlsruhe, DE
* Joined
Jan 14, 2017
• [252]May 22 '20
(BUTTON)
* [253]Copy link
*
* (BUTTON) Hide
*
*
*
Can confirm that the Stimulus framework works great for that exact use
case. But if you're used to the more common frameworks, you might
quickly miss the declarative "give me data, I give you DOM" approach
they provide.
I haven't tried it myself yet, but [254]Alpine.js gained some steam
lately and might be a good middle ground between Stimulus and the "top
dogs".
(BUTTON) 4 likes Like Reply
[255]mattwelke profile image
[256]Matt Welke
(BUTTON) Matt Welke
[257]Matt Welke
(button) Follow
Back end software developer, open source enthusiast.
* Location
Ontario, Canada
* Education
Seneca College
* Work
Backend software engineer at DigitalOcean
* Joined
Aug 16, 2019
• [258]May 27 '20
(BUTTON)
* [259]Copy link
*
* (BUTTON) Hide
*
*
*
writing an Express API requires "old javascript" unless you want to
go through the hassle of setting Babel up
Not sure what you mean here. You can use very recent JS features in
Node. We have async/await, async iteration, ES module imports, and more
now. I've never felt the need to set up Babel in an Express project.
(BUTTON) 5 likes Like Reply
[260]mattgperry profile image
[261]Matt Perry
(BUTTON) Matt Perry
[262]Matt Perry
(button) Follow
Creator of Framer Motion, Popmotion and Pose
* Location
Amsterdam
* Joined
May 15, 2020
• [263]May 15 '20
(BUTTON)
* [264]Copy link
*
* (BUTTON) Hide
*
*
*
it's widely understood that if you want 60fps animation, you will
likely have to bypass the React update cycle and do things in a more
imperative fashion (indeed, this is what libraries like react-spring
do)
Probably aside from the article, which I largely agree with, but I
think this is an odd point to try and make. This is true of any
component library that has overhead above imperative JS. But there's
nothing stopping you from using CSS in React, which is all Svelte does
anyway.
(BUTTON) 9 likes Like Reply
[265]richharris profile image
[266]Rich Harris
(BUTTON) Rich Harris
[267]Rich Harris
(button) Follow
I like turtles
* Location
Behind you
* Work
Graphics editor at the New York Times
* Joined
Jun 20, 2019
• [268]May 15 '20
(BUTTON)
* [269]Copy link
*
* (BUTTON) Hide
*
*
*
Wrong, sorry :)
This isn't a CSS demo: [270]twitter.com/Rich_Harris/status/120...
(BUTTON) 11 likes Like Reply
[271]daniel15 profile image
[272]Daniel Lo Nigro
(BUTTON) Daniel Lo Nigro
[273]Daniel Lo Nigro
(button) Follow
Australian living in the San Francisco Bay Area. Front End Engineer at
Facebook.
* Location
Palo Alto, CA
* Education
Swinburne University, Australia
* Work
Front End Engineer at Facebook
* Joined
Jan 11, 2017
• [274]May 15 '20 • Edited on May 15 • Edited
(BUTTON)
* [275]Copy link
*
* (BUTTON) Hide
*
*
*
We can provide better visual feedback that loading is taking place
I'm not so sure about that... IMO, so many single-page apps get this
wrong. The native browser loading indicator is still a lot better than
many SPAs, and unfortunately it's something that can't be triggered
from JS (apart from ugly hacks like infinitely-loading iframes)
With the advent of Node, that changed. The fact that we can do
server-side rendering and communicate with databases and
what-have-you using a language native to the web is a wonderful
development.
Server-side JS was a thing looooong before Node. I remember using
Microsoft's version of JavaScript ("JScript") server-side via Classic
ASP in the early 2000s. The issue back then was that JavaScript just
wasn't quite that popular yet. ES5 wasn't around yet (it was all ES3),
and there was a lack of good third-party libraries. But still, it was
absolutely in use long before Node even existed.
What Node did do was cross-platform support, introduce a module system
(CommonJS) as standard, and introduced the concept of easily obtaining
third-party packages via "npm", taking ideas from similar systems like
Perl's CPAN.
(BUTTON) 4 likes Like Reply
[276]mrispoli24 profile image
[277]Mike Rispoli
(BUTTON) Mike Rispoli
[278]Mike Rispoli
(button) Follow
I'm an award-winning designer, engineer and creative technologist that
helps daring founders ship valuable software.
* Location
New York City
* Work
Co-founder & CTO at Cause of a Kind
* Joined
Mar 8, 2019
• [279]May 15 '20
(BUTTON)
* [280]Copy link
*
* (BUTTON) Hide
*
*
*
So one thing I wondered after reading Tom's article and now yours is
how you feel about modern UI being so tied to node or javascript run
times on the backend specifically. For instance if you were to be
running something in Go and Phoenix you could dynamically render HTML
on the back end and serve it up quite a bit faster that the current SSR
environments based in Next or Nuxt or Sapper? So essentially somewhat
the way Stimulus JS works where you can send over static HTML, rendered
anywhere, by any type of server and the frontend could just hydrate
that and build components from it.
(BUTTON) 3 likes Like Reply
[281]richharris profile image
[282]Rich Harris
(BUTTON) Rich Harris
[283]Rich Harris
(button) Follow
I like turtles
* Location
Behind you
* Work
Graphics editor at the New York Times
* Joined
Jun 20, 2019
• [284]May 15 '20
(BUTTON)
* [285]Copy link
*
* (BUTTON) Hide
*
*
*
This is the 'PHP with jQuery sprinkles' approach I mention in the
article, except with shinier things than PHP and jQuery. I'm not a fan,
personally.
Phoenix LiveView is an interesting take on the problem, but I suspect
you hit a limit as to how ambitious your UI can be when deltas have to
come across web sockets at a consistent 60fps.
(BUTTON) 5 likes Like Reply
[286]mrispoli24 profile image
[287]Mike Rispoli
(BUTTON) Mike Rispoli
[288]Mike Rispoli
(button) Follow
I'm an award-winning designer, engineer and creative technologist that
helps daring founders ship valuable software.
* Location
New York City
* Work
Co-founder & CTO at Cause of a Kind
* Joined
Mar 8, 2019
• [289]May 15 '20
(BUTTON)
* [290]Copy link
*
* (BUTTON) Hide
*
*
*
So do you think its impossible for a framework to effectively hydrate
static HTML not rendered by that frameworks specified renderToString
method?
I really dont know what these functions do under the hood to allow
rehydration so Im just curious if it would be possible and achieve a
good frame rate.
(BUTTON) 2 likes Like Reply
[291]lawwantsin profile image
[292]Lawrence Whiteside
(BUTTON) Lawrence Whiteside
[293]Lawrence Whiteside
(button) Follow
I'm a freelance web developer working remotely. Inquire about projects.
* Location
Austin, TX
* Work
Freelance Web Developer at Self-employeed
* Joined
Jun 19, 2019
• [294]May 15 '20
(BUTTON)
* [295]Copy link
*
* (BUTTON) Hide
*
*
*
Universal Javascript is a need for only Juniors out of Bootcamp. And
the cost is great. Just learn about parsers and you'll never look at a
framework or template library ever again. Good on you for jumping on
how terrible Gatsby is.
(BUTTON) 3 likes Like Reply
[296]View full discussion (98 comments)
[297]Code of Conduct • [298]Report abuse
Are you sure you want to hide this comment? It will become hidden in
your post, but will still be visible via the comment's [299]permalink.
[ ]
Hide child comments as well
(BUTTON) Confirm
For further actions, you may consider blocking this person and/or
[300]reporting abuse
Read next
franciscomendes10866 profile image
Next.js and GraphQL: The Perfect Combination for Full Stack Development
Francisco Mendes - Jul 1
bdbch profile image
Sharing your Tailwind Configuration between Monorepo Packages
bdbch - Jun 23
desoga profile image
How to Fetch Data using the provideHttpClient in Angular
deji adesoga - Jul 1
jeetvora331 profile image
React Hooks vs Functions made easy
jeetvora331 - Jun 19
[301]Rich Harris
(button) Follow
I like turtles
* Location
Behind you
* Work
Graphics editor at the New York Times
* Joined
Jun 20, 2019
More from [302]Rich Harris
[303]Stay alert
#javascript
[304]A new technique for making responsive, JavaScript-free charts
#dataviz #svelte #javascript
Once suspended, richharris will not be able to comment or publish posts
until their suspension is removed.
Note:
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
(BUTTON) Submit & Suspend
Once unsuspended, richharris will be able to comment and publish posts
again.
Note:
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
(BUTTON) Submit & Unsuspend
Once unpublished, all posts by richharris will become hidden and only
accessible to themselves.
If richharris is not suspended, they can still re-publish their posts
from their dashboard.
Note:
____________________________________________________________
____________________________________________________________
____________________________________________________________
____________________________________________________________
(BUTTON) Unpublish all posts
Once unpublished, this post will become invisible to the public and
only accessible to Rich Harris.
They can still re-publish the post if they are not suspended.
(BUTTON) Unpublish Post
Thanks for keeping DEV Community safe. Here is what you can do to flag
richharris:
(*) Make all posts by richharris less visible
richharris consistently posts content that violates DEV Community's
code of conduct because it is harassing, offensive or spammy.
[305]Report other inappropriate conduct
(BUTTON) Confirm Flag
Unflagging richharris will restore default visibility to their posts.
(BUTTON) Confirm Unflag
[306]DEV Community — A constructive and inclusive social network for
software developers. With you every step of your journey.
* [307]Home
* [308]Listings
* [309]Podcasts
* [310]Videos
* [311]Tags
* [312]FAQ
* [313]Forem Shop
* [314]Sponsors
* [315]About
* [316]Contact
* [317]Guides
* [318]Software comparisons
* [319]Code of Conduct
* [320]Privacy Policy
* [321]Terms of use
Built on [322]Forem — the [323]open source software that powers
[324]DEV and other inclusive communities.
Made with love and [325]Ruby on Rails. DEV Community © 2016 - 2023.
DEV Community
We're a place where coders share, stay up-to-date and grow their
careers.
[326]Log in [327]Create account
References
Visible links:
1. https://dev.to/open-search.xml
2. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#main-content
3. file:///
4. file:///enter
5. file:///enter?state=new-user
6. https://twitter.com/intent/tweet?text="In defense of the modern web" by @Rich_Harris #DEVCommunity https://dev.to/richharris/in-defense-of-the-modern-web-2nia
7. https://www.linkedin.com/shareArticle?mini=true&url=https://dev.to/richharris/in-defense-of-the-modern-web-2nia&title=In defense of the modern web&summary=I expect I'll annoy everyone with this post: the anti-JavaScript crusaders, justly aghast at how much...&source=DEV Community
8. https://www.reddit.com/submit?url=https://dev.to/richharris/in-defense-of-the-modern-web-2nia&title=In defense of the modern web
9. https://news.ycombinator.com/submitlink?u=https://dev.to/richharris/in-defense-of-the-modern-web-2nia&t=In defense of the modern web
10. https://www.facebook.com/sharer.php?u=https://dev.to/richharris/in-defense-of-the-modern-web-2nia
11. https://toot.kytta.dev/?text=https://dev.to/richharris/in-defense-of-the-modern-web-2nia
12. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html
13. file:///report-abuse
14. file:///richharris
15. file:///richharris
16. file:///t/javascript
17. file:///t/react
18. file:///t/svelte
19. file:///t/webdev
20. https://twitter.com/tmcw
21. https://macwright.org/2020/05/10/spa-fatigue.html
22. https://twitter.com/tmcw/status/1259600386094030848
23. https://www.react-spring.io/
24. https://svelte.dev/
25. https://macwright.org/2020/05/10/spa-fatigue.html
26. https://gatsbyjs.org/
27. https://res.cloudinary.com/practicaldev/image/fetch/s--L4S_VLxO--/c_limit,f_auto,fl_progressive,q_auto,w_880/https://user-images.githubusercontent.com/1162160/82001896-43e38b00-962a-11ea-9ae7-bda853a8cec1.png
28. https://webpagetest.org/lighthouse.php?test=200515_N4_a92cbdd5b87d402522f710a8d82d2228&run=1
29. https://webpagetest.org/easy
30. https://dev.to/ryanflorence
31. https://twitter.com/intent/tweet?in_reply_to=1186675229621248000
32. https://twitter.com/intent/retweet?tweet_id=1186675229621248000
33. https://twitter.com/intent/like?tweet_id=1186675229621248000
34. https://nextjs.org/
35. https://medium.com/@mlrawlings/maybe-you-dont-need-that-spa-f2c659bc7fec
36. https://sapper.svelte.dev/
37. https://svelte.dev/
38. file:///settings/response-templates
39. file:///404.html
40. https://dev.to/twigman08
41. https://dev.to/twigman08
42. file:///twigman08
43. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j6
44. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j6
45. https://dev.to/gotofritz
46. https://dev.to/gotofritz
47. file:///gotofritz
48. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gj
49. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gj
50. https://dev.to/twigman08
51. https://dev.to/twigman08
52. file:///twigman08
53. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ke
54. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ke
55. https://dev.to/gotofritz
56. https://dev.to/gotofritz
57. file:///gotofritz
58. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paob
59. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paob
60. https://dev.to/adrianus
61. https://dev.to/adrianus
62. file:///adrianus
63. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6g5
64. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6g5
65. https://dev.to/techbelle
66. https://dev.to/techbelle
67. file:///techbelle
68. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1bp6j
69. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1bp6j
70. https://dev.to/ojrask
71. https://dev.to/ojrask
72. file:///ojrask
73. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjh
74. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjh
75. https://dev.to/gotofritz
76. https://dev.to/gotofritz
77. file:///gotofritz
78. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjk
79. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epjk
80. https://dev.to/ojrask
81. https://dev.to/ojrask
82. file:///ojrask
83. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epn5
84. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1epn5
85. https://dev.to/gotofritz
86. https://dev.to/gotofritz
87. file:///gotofritz
88. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1f04h
89. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1f04h
90. https://dev.to/jacobmakestheweb
91. https://dev.to/jacobmakestheweb
92. file:///jacobmakestheweb
93. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1i7gc
94. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-1i7gc
95. https://dev.to/mark_saward
96. https://dev.to/mark_saward
97. file:///mark_saward
98. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2k0
99. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2k0
100. https://dev.to/ryansolid
101. https://dev.to/ryansolid
102. file:///ryansolid
103. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p369
104. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p369
105. https://dev.to/mark_saward
106. https://dev.to/mark_saward
107. file:///mark_saward
108. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p3b8
109. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p3b8
110. https://dev.to/adrianus
111. https://dev.to/adrianus
112. file:///adrianus
113. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ka
114. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p7ka
115. https://dev.to/oenonono
116. https://dev.to/oenonono
117. file:///oenonono
118. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hk
119. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hk
120. https://dev.to/v6
121. https://dev.to/v6
122. file:///v6
123. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34a
124. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34a
125. https://dev.to/gotofritz
126. https://dev.to/gotofritz
127. file:///gotofritz
128. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gf
129. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5gf
130. https://dev.to/v6
131. https://dev.to/v6
132. file:///v6
133. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5lf
134. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5lf
135. https://dev.to/stew_sims
136. https://dev.to/stew_sims
137. file:///stew_sims
138. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kj
139. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kj
140. https://dev.to/rhymes
141. https://dev.to/rhymes
142. file:///rhymes
143. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6cm
144. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p6cm
145. https://dev.to/oenonono
146. https://dev.to/oenonono
147. file:///oenonono
148. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hm
149. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p4hm
150. https://dev.to/holdit
151. https://dev.to/holdit
152. file:///holdit
153. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p4
154. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p4
155. https://dev.to/iamschulz
156. https://dev.to/iamschulz
157. file:///iamschulz
158. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2hk
159. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2hk
160. https://dev.to/richharris
161. https://dev.to/richharris
162. file:///richharris
163. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i2
164. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i2
165. https://sapper.svelte.dev/
166. https://dev.to/iamschulz
167. https://dev.to/iamschulz
168. file:///iamschulz
169. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2id
170. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2id
171. https://dev.to/martinmalinda
172. https://dev.to/martinmalinda
173. file:///martinmalinda
174. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5d6
175. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p5d6
176. https://dev.to/ben
177. https://dev.to/ben
178. file:///ben
179. mailto:ben@forem.com
180. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2jk
181. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2jk
182. https://dev.to/v6
183. https://dev.to/v6
184. file:///v6
185. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34f
186. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34f
187. https://www.hashicorp.com/tao-of-hashicorp#workflows,-not-technologies
188. https://dev.to/phlash
189. https://dev.to/phlash
190. file:///phlash
191. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j3
192. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j3
193. https://dev.to/phlash909/comment/cghl
194. https://dev.to/v6
195. https://dev.to/v6
196. file:///v6
197. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p348
198. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p348
199. https://dev.to/panesofglass
200. https://dev.to/panesofglass
201. file:///panesofglass
202. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d20
203. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d20
204. https://dev.to/rhymes
205. https://dev.to/rhymes
206. file:///rhymes
207. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d40
208. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12d40
209. https://dev.to/panesofglass
210. https://dev.to/panesofglass
211. file:///panesofglass
212. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12dc2
213. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12dc2
214. https://dev.to/rhymes
215. https://dev.to/rhymes
216. file:///rhymes
217. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12df6
218. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-12df6
219. https://dev.to/gregfletcher
220. https://dev.to/gregfletcher
221. file:///gregfletcher
222. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j2
223. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2j2
224. https://dev.to/v6
225. https://dev.to/v6
226. file:///v6
227. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34d
228. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p34d
229. https://martinfowler.com/bliki/SacrificialArchitecture.html
230. https://youtu.be/oKg1hTOQXoY?t=1754
231. https://res.cloudinary.com/practicaldev/image/fetch/s--KIKmJfBA--/c_limit,f_auto,fl_progressive,q_66,w_880/https://dev-to-uploads.s3.amazonaws.com/i/5ehz4jt3d7skefmuwg6d.gif
232. https://dev.to/richharris
233. https://dev.to/richharris
234. file:///richharris
235. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n0
236. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n0
237. https://dev.to/ben
238. https://dev.to/ben
239. file:///ben
240. mailto:ben@forem.com
241. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2nd
242. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2nd
243. https://dev.to/gotofritz
244. https://dev.to/gotofritz
245. file:///gotofritz
246. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paom
247. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-paom
248. https://stimulusjs.org/
249. https://dev.to/loilo
250. https://dev.to/loilo
251. file:///loilo
252. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pb3c
253. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pb3c
254. https://github.com/alpinejs/alpine
255. https://dev.to/mattwelke
256. https://dev.to/mattwelke
257. file:///mattwelke
258. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pg9g
259. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-pg9g
260. https://dev.to/mattgperry
261. https://dev.to/mattgperry
262. file:///mattgperry
263. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i0
264. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i0
265. https://dev.to/richharris
266. https://dev.to/richharris
267. file:///richharris
268. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2je
269. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2je
270. https://twitter.com/Rich_Harris/status/1200807516529147904
271. https://dev.to/daniel15
272. https://dev.to/daniel15
273. file:///daniel15
274. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n6
275. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2n6
276. https://dev.to/mrispoli24
277. https://dev.to/mrispoli24
278. file:///mrispoli24
279. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kc
280. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2kc
281. https://dev.to/richharris
282. https://dev.to/richharris
283. file:///richharris
284. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p5
285. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2p5
286. https://dev.to/mrispoli24
287. https://dev.to/mrispoli24
288. file:///mrispoli24
289. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p35p
290. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p35p
291. https://dev.to/lawwantsin
292. https://dev.to/lawwantsin
293. file:///lawwantsin
294. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i8
295. https://dev.to/richharris/in-defense-of-the-modern-web-2nia#comment-p2i8
296. file:///richharris/in-defense-of-the-modern-web-2nia/comments
297. file:///code-of-conduct
298. file:///report-abuse
299. file:///var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html
300. file:///report-abuse
301. file:///richharris
302. file:///richharris
303. file:///richharris/stay-alert-d
304. file:///richharris/a-new-technique-for-making-responsive-javascript-free-charts-gmp
305. javascript:void(0);
306. file:///
307. file:///
308. file:///listings
309. file:///pod
310. file:///videos
311. file:///tags
312. file:///faq
313. https://shop.forem.com/
314. file:///sponsorships
315. file:///about
316. file:///contact
317. file:///guides
318. file:///software-comparisons
319. file:///code-of-conduct
320. file:///privacy
321. file:///terms
322. https://www.forem.com/
323. https://dev.to/t/opensource
324. https://dev.to/
325. https://dev.to/t/rails
326. file:///enter
327. file:///enter?state=new-user
Hidden links:
329. file://localhost/search
330. file://localhost/richharris/in-defense-of-the-modern-web-2nia?comments_sort=top#toggle-comments-sort-dropdown
331. file://localhost/richharris/in-defense-of-the-modern-web-2nia?comments_sort=latest#toggle-comments-sort-dropdown
332. file://localhost/richharris/in-defense-of-the-modern-web-2nia?comments_sort=oldest#toggle-comments-sort-dropdown
333. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2j6
334. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p5gj
335. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/paob
336. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p6g5
337. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/1bp6j
338. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/1i7gc
339. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2k0
340. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p369
341. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p7ka
342. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p4hk
343. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p34a
344. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p5lf
345. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2kj
346. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p6cm
347. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p4hm
348. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2p4
349. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2hk
350. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2i2
351. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p5d6
352. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2jk
353. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p34f
354. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2j3
355. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p348
356. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/12d20
357. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/12df6
358. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2j2
359. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p34d
360. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2n0
361. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2nd
362. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/pb3c
363. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/pg9g
364. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2i0
365. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2je
366. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2n6
367. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2kc
368. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2p5
369. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p35p
370. file://localhost/var/folders/q9/qlz2w5251kzdfgn0np7z2s4c0000gn/T/L12384-4857TMP.html#/richharris/in-defense-of-the-modern-web-2nia/comments/new/p2i8
371. file://localhost/franciscomendes10866/nextjs-and-graphql-the-perfect-combination-for-full-stack-development-18l7
372. file://localhost/bdbch/sharing-your-tailwind-configuration-between-monorepo-packages-4o5k
373. file://localhost/this-is-angular/how-to-fetch-data-using-the-providehttpclient-in-angular-5h47
374. file://localhost/jeetvora331/react-hooks-vs-functions-made-easy-2g2l