Basically "maybe you're overthinking front-end" is just another way of saying that front-end isn't "serious programming".
In no other part of software development do people start sneering that a few dozen k of library code and a compiler is overengineering.
It’s a ridiculous double standard.
Front end devs also operate in arguably the most hostile runtime environment possible with such a plethora of browsers and operating systems, each with special snowflake support for APIs etc.
Exactly. This is exactly what I mean. No one holds every other compiler/lib toolchains to build size, perf, or speed as heavily as Web either.
Think if C++ developers couldn't ship more then 200kb of binary.
It boils down to consequences. Back then, with hard limits, your code just didn't execute. On the web, the users bear the overhead of a final product that's too big and engineers don't even realise it.
"the users bear the overhead of a final product that's too big and engineers don't even realise it"
These must be junior engineers.
Mentor & educate. I promise _plenty_ of web engineers realize & plan for this. We iterate on how to balance machine & engineer efficiency.
Are you talking about engineers moving into web from other disciplines?
I'm just confused as to why either of you think experienced engineers don't understand that users bear the consequences of poor machine efficiency on the web. It's something we constantly talk about?
1. “Dynamically loading DLLs” is redundant
2. Loading DLLs is easy, it’s the ref counting and freeing of resources that bit you.
3. Anything, dear god ANYTHING except COM/IQueryInterface
Yes, and we had to write these interfaces generate the plugins by hand, people touching those had to be an expert in everything in the system, keeping track of what DLLs where supported per release, different DLL versions made tracking a bit of an exponential issue
And then someone lost the source files to ONE of those DLLs, which was mandatory, company that made it went bankrupt, millions of lines of code use it, so you can kiss moving from VC++6 forward goodbye 👋
Yes, let's insist that people write real-time, 60fps, instant-loading-on-2g, distributed software without a compiler or significant runtime.
Then, when people try to make those things, tell them they're overthinking it. 🤔🤨
Glimmer's architecture is an amazing fit for wasm.
I had a great chat with Luke Wagner (wasm team) about how to structure our memory management and our current structure is almost a perfect fit for today's wasm.
Follow this branch! I'm so excited!
I don't know what you are talking about, but this is not the way I apprehend frontend web dev. Adding any amount of libraries to a website is a huge deal and cannot be as trivial as including dependancies to a C++ project...
The problem that I see is that we tend to push everything into production runtime. Because its easier to debug, fix and think of web applications as a kind of vm that manages everything. While most code could have been natively done by the browser.
Agreed. My opinion is it is considered too complicated because there’s not “one true way”. Imagine Android without a proper SDK, testing support, etc. If it all relied on 3rd parties, it’d feel the same as the web
We'll, for example, jest for testing from Facebook. Would you consider it that? And when comparing to Android, not one company owns, or came up with, manages the web, it's distributed. Should someone take charge?
I’m excited about the future ReasonML community. It seems like there is Stockholm syndrome in some Front End communities that their work is as impacting and doesn’t require deep thinking. Probably trickling down the chain.
In back-end work I only need to run on my precise infrastructure environment, and I can even modify it to my needs. The front-end must work on whatever garbage the end user has in their pocket. So I respect the front end even if it seems simple.
I think the tweet kind of should be more about how the “community” has overly obfuscated front-end programming and raised the wall as a barrier to entry w/ complication, obfuscation, and lack of explainations.
That is quite literally one of the biggest gripes I have with all of the various front-end tools. No one says the obvious, which is not really obvious in a world of new serverless/stateless programming.
Its not the tools/libraries fault for being what they are, but it is somewhat the fault in the marketing/evangelism/vague terminology IMHO. PLENTY telling people HOW to do something, no one explaining WHY
There are good reasons for tech to exist. But that doesn’t mean everyone is using the tech for good reasons.
In the React world there was a perception that you *had* to use Webpack and Redux and React Router that still lingers.
But I also believe you are also 100% on the hook, obligated to ship a fast website, no excuses, 100% of the time.
The spectrum products build for the web is huge. From static pamphlet pages to encyclopaedias to full blown apps. If frontend engineers are guilty of anything it's not acknowledging that the diversity of approaches is unavoidable (and OK).
I'd like to be a light of optimism and pro-activity but we're not going to get there patting ourselves on the back for measurable decline. We need to be honest about this stuff. (At risk of my radical candor having me branded like @slightlylate ;)
I feel you, most sites should probably be static with a few cloud fns to deal w/ data, but also when I think about web "apps" in 2008 vs. today, some of today's apps are awesome and nearly inconceivable back then.
To me the crux of the issue is really selecting the right set of tools to solve a given problem. Don’t select the ‘new hot tools’ because it’s new, select it because it solves some problem your actually facing.