After reading the entire thread I am still in the dark about what exactly the author wants to see changed.
The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion.
I've never seen an interesting point that could be made in 140 characters or less. That limit works for jokes, headlines, and almost nothing else.
Single-tweet "wisdom" always turns out to be something so broad/unqualified that it's uninteresting or untrue. VC Twitter is basically a deluge of that kind of faux-profound nonsense.
At first I found it surprising to start finding all of these Twitter threads making it to the front of HN and thought "well, it must be a really compelling message..." Now I just ignore them altogether. It is a very distracting medium for the longer posts, and that distraction shows through from the writers side as well.
I agree, if you are that virulent about what is wrong, maybe you want to give a clue as to what you think is right. Or do you just think everything is wrong?
OP here; at a tactical level, prefer HTML/CSS and MPA architecture until you have firm evidence of long sessions and many interactions per session that justify JS, and when you add JS to smooth a common interaction based on data, build from progressive enhancement unless it's impossible (e.g., a text or image editor).
More pithily, maybe PHP was good, actually?
Popping up a level, this isn't about tools, it's about culture and how we decide to choose. I work every day with teams that need to claw back to sanity from years in the JS fever swamps, and nobody's having a good time when launches are blocked on terrible perf, a11y, etc. The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls.
Some of that is captured in this post; hope it helps:
so in essence your argument is that management needs to care about performance because most end users have devices that are not powerful enough to process all that javascript, based on this technical argument i found hidden in a footnote:
JavaScript-delivered UI strips the browser of its ability to meaningfully reorder and slice up work so that it prioritises responsiveness and smooth animations. JavaScript is the "fuck it, we'll do it live" way to construct UI, and stresses the relative performance of a single core more than competing approaches. Because JavaScript is, byte for byte, the most expensive thing you can ask a browser to process
that's fine. as an independent developer i don't care much for the management problems in large teams, so maybe this topic is not for me. i need to make the tradeoffs between engineering and product performance, development cost and client budget all by myself, and hence am looking to technical solutions to find the right tradeoff.
what i am missing on the technical side of the argument is how "fuck it, we'll do it live" relates to latency.
my expectation is that while device performance increases continuously and becomes cheaper, latency on the other hand does not improve as fast.
to put it drastically: people in rural africa or india have smart phones from the 2010s but internet connectivity from the 1990s
Device performance has been growing in diversity as we approach smartphone saturation (the last couple of hundred million flipphones getting traded for < $100 low-end smartphones). I'm working on an update to this series, but here's a recap from last year:
As this relates to latency, JS-mediated UI is slower to materialize for a host of reasons, not least of all the problems with getting it across the wire (as you note). Naive SPA designs tend to serialize what should be parallel (data fetching and shell setup). Getting better at this requires more sophistication, whereas teams that stick to basic HTML + light progressive enhancement tend to end up with simpler systems that are faster for light-to-medium session depths and are easier to diagnose/fix when things go sideways.
The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls.
i agree that some (or maybe all) frameworks go needlessly complex with their dependencies. little libraries that contain one function that should really be folded into the other libraries that are using that function.
but isn't part of the problem the the inherent higher complexity of modern interfaces? the days where a site as simple as hackernews are appealing to the average person browsing the web are gone. i am afraid that in order to compete for visitors or customers, we have pushed ourselves into a corner. doesn't any new website need to function and look as modern as every other if it wants to have a chance?
a large engineering team with a sufficient budget and time may accomplish that without a framework, and so you are exactly right, the strings to accomplish it need to be pulled at the very top. but what hope do we have when the primary directive that comes from the top is to keep the cost down?
especially new projects suffer from this. i can only afford to spend engineering resources after a project has become profitable. but in order to get there, i need to cut corners where i can. that usually means using frameworks to get up and running fast. and once we make a profit we can spend money to improve things. but by then it's to late to switch to a non-framework approach unless the resources are enough to start over.
the complexity caused by frameworks is costing us money. but it's money that is now available because the project is making a profit.
wouldn't your approach require higher expenses upfront, at a time when i don't even know if it is worth the effort?
I think is because JS is one of the few languages that has practically always been used with a layer on top, before with Jquery or other libraries and now with frameworks, that is not so common in other languages, JS has an external layer for everything
> The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion.
Consider that Chrome Dev Tools are built with vanilla js (plus web components). I would call it a medium-to-large-sized project, wouldn't you?
Although Chrome Dev Tools isn't the kind of use case that Alex has in mind when he rants on Twitter. His concern is the mobile web; his reference is a weak Android device (used to be a Moto G4) on a 4g mobile network. Which kinda ignores that there are valid use cases for sites that are built as apps primarily for stationary desktop users.
I think in some ways this is also a question of specialized vs universal tools. If I plan a vacation with friends I believe I could do it 90% of the way just as well with a plain old shared word document/todo list.
As a nearly daily user of Google Stadia I have to disagree. I use Stadia in two different households, one with a 50 Mbps connection (where Stadia works perfectly) an one with a connection capped at 10 Mbps down and 1 Mbps up. The 10 Mbps connection only allows for 720p gameplay and I get frequent stuttering every 5 minutes or so but this doesn't really ruin the experience with most story driven games like Red Dead Redemption 2 or AC Odyssey.
At first I was surprised by the playability of Stadia at such a slow connection myself but even though I cannot play shooter games I wouldn't go as far to call the experience I get with the 10 Mbps connection 'unplayable'.
draw.io is a good alternative . By default it does not show icon for cloud services but if you click on "More Shapes" option at bottom left, you can add AWS,Azure and GCP and create all sorts for architecture diagrams.
Plus, it is opensource and can run your own self hosted draw.io app from github.
We are long time users of Lucidchart and were using the predecessor of Cloud Insights, AWS Import, for creating cloud diagrams of our existing AWS infrastructure. In February, a LucidChart account manager contacted us stating the AWS Import feature would be sunsetted. He offered to onboard our team onto Cloud Insights but we would have to upgrade to an Enterprise account at $199/license/year AND pay $4,000 a year for the Cloud Insights add-on that covers only up to 50 compute resources. We ended up keeping our account as-is and never heard back from the account manager.
Lucidchart is a great product but we were really turned-off & disappointed they essentially took a feature away from us.
On iPadOS 14 the bedtime feature got removed entirely since there is no Health App available for iPads. I guess i have to say goodbye to using my iPad as a high tech alarm clock for now...
Looks promising! Does deepstream work well as a standalone server or is it best used in combination with express.js if I am building a real-time web app?
If you want you could add a custom plugin that would take the HTTP server within deepstream and enhance it using express for all your non-deepstream routes, if you raise an issue for it I think it's something that can be done in the near future! But generally wouldn't recommend for non-pet projects since they serve two different purposes.
I believe one essential step in the right direction would be to create an ad platform that allows companies to create and developers to show truly passive ads. To specify what I mean: Display a jpeg with the advertisement and link it to a website using a referral ID in the URL. This referral ID would obviously only be a vague indicator of success, but I believe that even though targeted advertising might be more effective, there is a market for 'universal advertising' (for commodities most people use like toothpaste, cars or breakfast cereal).
The revenue model might be slightly different from platforms like AdSense, where instead of paying per 1M impressions you would maybe choose a newspaper like model where the advertiser pays a fixed price depending on the property that displays the ad.
And the cherry on top: All of this would be GDPR compliant right out of the box, so no hour-long fiddling with the ToS agreement.
While not a platform, my site sells and hosts our own advertisements which are only static images and are sold per month. We've been doing this for the last 5 years or so and it seems to work well for our advertisers.
Selling advertisements based on impressions incentivizes publishers to maximize impressions through various means such as click-bait titles, auto-refreshing ads while you're on the page, or implementing slideshows. All of these things degrade a website's experience in the long-term for the sake of ekeing out a few more dollars in the short term.
I am honestly surprised how Google was able to keep up YouTube for so long despite a severe lack of profits. Even though Youtube made a net loss in the hundreds of millions for years Google kept it up and running and drastically expanded its feature set into areas like live streaming etc.
As far as I know YouTube has now reached break even, but I believe Google deserves credit for having the vision and tolerance for failure to keep YouTube up for such a long time without a dollar of profit, not to speak of the enormous political and financial risk YouTube poses because of copyrighted or harmful material.
I don't think Google deserves credit for keeping a money losing YouTube alive for so long. It's anti-competitive. Innovation that might have existed and been better was likely strangled because it couldn't compete with the money losing behemoth that is (or was) YouTube.
I do think they get credit for not killing it off, as they often do to other projects. Are the YouTube losses equivalent to loose change to Google? Probably, but that won’t stop me from being thankful someone had the vision to keep it alive.
It would be interesting to hear an updated figure now. My impressions is heavily increased monetization across the whole thing. Nowadays, more than one ad shown, often unskippable, and constant nags/"reminders" about YT prime (red?) and Music.
The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion.