Designing very large (JavaScript) applications – Malte Ubl – Medium


83 bookmarks. First posted by llkats april 2018.



You want to get to a state where whatever the engineers on your team do, the most straightforward way is also the right way–so that they don’t get off the path, so that they naturally do the right thing.


add tests to your application that ensure the major invariants of your infrastructure.


Try to avoid human judgement whenever possible outside of the application domain. When working on an application we have to understand the business, but not every engineer in your organization can and will understand how code splitting works. And they don’t need to do that. Try to introduce these thing into your application in a way that is fine when not everybody understands them and keeps the complexity in their heads.
javascript  reference  malteubl  programming  design 
10 weeks ago by WimLeers
This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube. Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. via Pocket
IFTTT  javascript  webdev 
10 weeks ago by themagicteeth
Thoughtful useful article
js  Webapplication  webapp 
11 weeks ago by scottnelsonsmith
So, I build this JavaScript framework at Google. It is used by Photos, Sites, Plus, Drive, Play, the search engine, all these sites. Some of them are pretty large, you might have used a few of them.
javascript  architecture 
12 weeks ago by nicolashery
Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. Yesterday I was…
JavaScript 
12 weeks ago by pks
Designing very large (JavaScript) applications
from twitter
12 weeks ago by RBaumier
Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. Yesterday I was…
12 weeks ago by jorgemir
Designing very () – Malte Ubl – Medium
large  applications  JavaScript  from twitter
12 weeks ago by alvar
This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube. Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned.
pocket 
april 2018 by stasm
Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. Yesterday I was…
js  eng  build  code  toread 
april 2018 by cjitlal
Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. Yesterday I was…
javascript 
april 2018 by ruxkor
Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. Yesterday I was…
april 2018 by danielglh
Sr. Eng: “I know how I would solve the problem”
Beyond Sr. Eng: “I know how others would solve the problem”

route based code splitting -> lazy load at component level -> (React components statically depend on their children) -> Split logic and rendering -> (Server side render a page and then triggers downloading the associated application bundles, aka hydration).

Avoid central configuration at all cost
- central CSS
- routes.js
- webpack.config.js
- package.json (???)

enhance, or reverse dependency: good fit for generated code, enhancing the central registry without even knowing the generated file names.

"Base bundle pile of trash" -> "forbidden dependency tests": your base bundle does not depend on any UI (e.g. React.Component)

> ... feel empowered to add tests to your application that ensure the major invariants of your infrastructure.
> Try to avoid human judgement whenever possible outside of the application domain.
> ...make it easy to delete code.
> ... empathy and experience is what enables you to choose the right abstractions for your application
software-engineering 
april 2018 by mazin_z1
This article by is a must-read for any web application engineer. 👏👏👏
from twitter_favs
april 2018 by oliver.turner
“Designing very large (JavaScript) applications” by
from twitter_favs
april 2018 by trek
Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. Yesterday I was…
javascript 
april 2018 by phutwo
This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube . Slide text: Hello, I used to build very large JavaScript…
from instapaper
april 2018 by kohlmannj
This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube . Slide text: Hello, I used to build very large JavaScript…
from instapaper
april 2018 by scubaninja
Using tests to maintain architectural invariants
javascript  architecture  programming  software-engineering 
april 2018 by jpereira
Designing very large (JavaScript) applications
This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube.
architecture  programming  Javascript 
april 2018 by euler
Designing very large JavaScript applications
from twitter_favs
april 2018 by demon386
As I was saying at the start of the presentation: The way to get there is to use empathy and think with your engineers on your team about how they will use your APIs and how they will use your abstractions. Experience is how you flesh out that empathy over time. Put together, empathy and experience is what enables you to choose the right abstractions for your application
empathy  development  programming  apis 
april 2018 by travisbhartwell
This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube. Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. via Pocket
IFTTT  Pocket 
april 2018 by tkhwang
This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube. Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned.
frontend  javascript 
april 2018 by kogakure
Designing very large (JavaScript) applications
from twitter_favs
april 2018 by dr3wster
This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube . Slide text: Hello, I used to build very large JavaScript…
from instapaper
april 2018 by pwarnock
"Designing very large (JavaScript) applications"
's talk at as a transcript
from twitter
april 2018 by codepo8
via Pocket - Designing very large (JavaScript) applications - Added April 15, 2018 at 08:03PM
IFTTT  Pocket 
april 2018 by BastiRe
This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube. Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned.
april 2018 by davidmatas
this is really the only design doc how-to/explainer you need to read  https://t.co/dyzu4oc5iT

written by Malte Ubl who also wrote this recently popular and very good post about building large js appshttps://t.co/XXoALfOJbl

— Tibetan Gift Coder (@l4stewar) April 22, 2018
from pocket
april 2018 by lestew
Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. Yesterday I was…
javascript 
april 2018 by e2b