No. In fact we're actually realizing the way we used to ship code was egregiously slow, inaccessible, and no interoperable. Welcome to front end _Engineering_.

Thank you Sean 👍👍

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.

Also the most hostile business environment with literally everyone able and willing to critique their work, and the fastest changing fashions of technology and style in the industry.

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.

I remember times like that.

😂😂 Yeah and how was that. I bet there was no Code Splitting in those toolchains either... 😂

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.

We should make the web do this and see what happens.

FYI we have this restriction in VS right now and it's terrible. Devs will start gaming the metric to get their job done and things will just get worse.

"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.

"professionals" do it. but its not "on by default", you need extra efforts

The hell do you mean by "professionals"?

Most devs Inmer in the past just dont look at it. A lot of them just love coding and dont mind ux, dy and business value

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?

It doesnt depend on the technology. In my experience at max 10 out of 100 devs take dx, ux, perf into account (so into their feedback loop/measure it regularily,...)

Isnt always the fault of the engineers thenselfes though.. a lot of managers/project leads just invest in building features, not in perf/refactoring/maintainability/...

You've had a terrible experience. I've not worked in any environment like you describe and I've been in industry for more than a decade.

dynamically loading DLLs was hellish

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 So yeah...hellish

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. 🤔🤨

Perhaps JS binary formats could get us part of the way there? JS files are massive for how little actual text is inside.

WebAssembly. You're describing WebAssembly.

WASM doesn’t have DOM access. But maybe eventually

Glimmer does ;)

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!

It will eventually with the JS bindings proposal underway.

What will?

I think Sean means WASM will eventually have DOM access.

Yep. Late 2018 probably. I don't wanna wait that long!

I don't either. Looking forward to seeing that branch evolve 😆

Yeah they should go back to when server side was easy and you could just write assembly, 1s, 0s, and SigV, and just reload.......

Omg that thread is painful

Also the web is backwards compatible. Everyone has the choice to ‘live in the good old days’. No thanks.

Back in the good old days the C++ developers pushed bits uphill both ways. You kids with your 20k of libraries and fancy pants compilers have it so easy. Yawn.

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.

It’s shorthand for “front-end is something I, an intelligent, enlightened, ‘real’ programmer, should be able to jump back in to at a moment’s notice.”

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

But the fact that nobody goes around making people feel guilty for using libraries in Android makes a difference.

No disagreement there. It's just so weird to me that there is no "here's how you build an app, here's how you test code, etc" from the big players.

Polymer exists. No thanks.

That’s basically the Ember ecosystem, right? And it works pretty well.

😉

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?

Right, I would like to see "one true way" where there is a comprehensive end-to-end solution driven by major company. There could be many.

Ember and Angular are as close as you get presently.

And actually, the problems a frontend engineer has to solve are pretty complex. We basically want to have apps without an install step (at least for web applications)

Our over thinking is what's keeping that guy on Twitter.

I wonder how much engineering it took to roll out 280 characters

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.

Pretty please, if you have examples, and they are issues with our project (#webpack), please don't hesitate to reach out. We want 0 of this across all our projects.

Likewise for any project I work on.

Literally have no idea what projects you work on so.... we can start with that.

You can start with better describing what exactly #webpack is. Someone who does basic front-end javascript like interactions/animations, etc doesn't know what a "module loader" does or is. Does it run on the server to compile or in the browser?

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.

So much this Sean! Thank you so much for making my business possible. Making PWA development even easier.

🙌🏻🙌🏻🙌🏻

Over engineering your front end source, setup, tooling is not really the problem. The problem I see is that often the eventual front end (that will be send to the client) is then also over engineered.

Mostly due to ignorance of the developers I think. The tooling isn’t in the wrong here.

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.

Sure! As long as you can ship under 200kb of total uncompressed #JavaScript for your initial load, i don't care what you use. But I also believe you are also 100% on the hook, obligated to ship a fast website, no excuses, 100% of the time.

It might be fairer to say a project can be over-engineered. The ecosystem can’t, because the complexity is solving real problems.

Yet we seem to give special attention for this cases in FE, not nearly as much in all other areas.

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).

Also gotta love the constant nagging against "using external deps for something simple" , but copy pasting no DRY is ok ?

Agreed, I personally feel that we as developers should know when a app is being over engineered on the frontend side, but it all boils down to what you are building and making the correct decisions

It's why in 2005 Yahoo restructured web developers & designers into front end engineers (F2E) and architects with an equal say in overall product design.

I've never been more into it as I am now. Love modules, bundling and lite backend concepts.

Thanks for your hard work (I *really* mean it) : on large/middle scale projects it's a blessing. But don't forget where the web came from. As always, there is a middle ground somewhere.

destroyallsoftware.com/talks/the-birt… The end game.

idk. seems revisionist to me. the front end isn't improving in any metric I've seen… its getting worse.

page weight? worse. time to interactive. worse. etc. are we more aware of these problems now that we're measuring them? I guess so. I started warning about this in 2008 sooo…

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 ;)

congratulations, you have become @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.