So I was reading about "bloated" applications and how we, especially web developers, pull in dependencies like it's nothing since a modern computer can handle it just fine. The concern is that we're sacrificing too much (?) performance for convenience that it may come back to haunt us and it's time we take performance in front of our priorities again. With some thinking, I can see the appeal of both sides — though the latter one I think is more ideal and is the topic that I'd like to ask all of you about.
Case in point: MyFaceTweetSter
The year is 2005. MyFaceTweetSter (MFTS) has risen as the king of Social Media networks. They're reeling in millions in revenue, every college kid uses it, and the CEO can already see a movie being directed about his company a few years down the line. This is all good until Tom ZukerDorsey made a crucial mistake: as he was refactoring MFTS' inbox.php script, he accidentally used in_array ($needle , $haystack). (Which is in the wrong order. Or is it? IDK even know). This apparently rips open a void in the timespace plane, freezing the whole MFTS building in time. PHP4 is pretty wild.
Fast forward to 2018, and the timespace void has been filled. Tom is back alive, and is looking to reclaim his throne. He booted up his Windows XP computer, quickly researched WTH is going on in the dev community, and decided to port MFTS in a <modern-mvc-framework />. It took him a month (2 weeks spent negotiating since MyFaceTweetSter.com is expired and held for ransom) and he's ready for launch!
"Whoa whoa whoa, hold on!", said Justin Timberlake, his main investor. "Every dev and their dogs uses JavaScript today. How about we hire the guys from dev.to and consult them so we can get up to speed with the JS ecosystem?". So here's where we come in. We'll try to modernize the UX of MFTS without pulling in every packge in npmjs.com. So currently, every action triggers a page reload as expected in a traditional web app. The core functionalities are as follows:
## The Usuals
- Registration
- Authentication
- Feedback forms
- etc.
## Friends
- Search through the users
- Send a "friend request" to a user
- "Unfriend" a user
## Posts
- A user can make a post (with photos / embedded media)
- A chronological list of posts are presented in the home page
- Paginated with 10 posts each
- A user can like/unlike a post
- A user can comment on a post
## Messaging
- A user can send a message to one of their friends
- A user can reply to a message sent to them
- The messages are displayed as "threads"
## Profile
- A user can upload a "profile picture"
- A user can put in their personal information to be display in their profile
- A user can update the said information
- A user can browse through their friends profile
<!-- Feel free to add more "core" features! -->
Which of these do you think are good candidates for using JavaScript? What's the minimum we can go whilst still providing good UX? Would MFTS, granting their huge following a decade ago, be able to compete with today's social media platforms without using JS at all?
Top comments (11)
I think there all good candidates, and I think a few more things actually. Refactoring without unit / integration tests or any sort of test really, our protagonist deserved it.
Perseved speed (RAIL) principle is far more important than fast code. I do agree that dependencies in npm are insane but npm has improved alot.
If your PO wants a seamless emersive product, how are you gonna do this with serverside and CSS animations alone.
We're going to assume that he added tests once he migrated to
<modern-mvc-framework />, so we'll give him a pass this time.That's actually the first time I heard of RAIL. Looks interesting!
Fair point. Though it's interesting to think what's the least JS we can put in a product that can still constitute to good UX. The product being a social media platform makes the line narrowly thin, I think (should've chosen a better example lmao).
No don't worry, I was on the bus and getting frustrated, saw your post and vented, my bad. Your absolutely right to question this. It is absolutely possible to go a long way with just CSS. However the CSS would all need to be loaded on the same page. A dynamic scripting language offers some very important asynchronous features giving the Perception of speed. Load things when you need them. Distract users with animations ect.
developers.google.com/web/fundamen... there we go a reference
And here is the funniest lecture on the subject it will stick with you. youtu.be/65-RbBwZQdU
CSS can handle most animations/transitions on its own, but the "minimum" JS is such an open question because it depends entirely on what your application is being built for. HTML5 form validation still isn't truly cross-browser compatible (or even consistent), especially when older browsers need to be supported. You can get away with replacing AJAX/fetch calls (or websocket connections) with regular form submissions, you just get a fresh page on every action. You can even embed Flash/Flex applications (though I highly recommend against this in 2018...) to handle highly complex UI, but that's basically cheating since you're just replacing JS with AS.
At its core, JS (in the browser) is just a way to handle events and interact with the DOM. Basic webpages don't need much, but nobody builds basic webpages anymore. A "webapp" denotes a certain expectation of a high amount of user interaction, including expectation of good UX across the entire application.
A specific example of a good candidate from the OP would be uploading a profile picture: letting the user choose a file, crop/resize it, preview, then submit.
I'm assuming that saying absolutely zero JS and using WASM is cheating?
I don't think John excluded WASM, please use C and when the browser is optimised in about 10 years you'll smash JavaScript heh. It's not a magic bullet yet.
Blazor is almost here though.
It's all here, Java, Rust Lua c# typescript via WASM and more there's a lot of languages compilation efforts. Blazer is the c# one? Sadly JS is still out performing all of them due to browser optimizations. However judging by my previous comments, it doesn't matter.
Since network is the bottleneck, there is essentially no feature on this list that couldn't be made more performant with JavaScript than by trying to create a similar UX using no-JS solutions.