Modern front-end development: skinny jeans and handlebar mustaches ITT

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »

HaB: Jan 5, 2001; What are the odds?

HaB posted:

Ugh.

In today's episode of "Super Poorly Documented Javascript Frameworks":

ag-grid

I ended up solving my problem via the time-honored technique of "going back to the last working commit and starting the gently caress over"

Guess what I'm wearing today:

my grumpy pants.

# ? Nov 6, 2017 17:35

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 10:09

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Munkeymon posted:

Well that's interesting. I'll bring this up with the other guys who touch front-end stuff.

Also, surely you mean $window Uh, right?

$window is just an angular injectable window object. I think the only reason they made it was for unit testing purposes. I don't say $window.fetch() because people will think I'm talking about some fancy Angular concept.

Munkeymon posted:

E: oh hey what about my other question about getting an element reference into a directive's controller?

Well, there is a crummy way, and a better way. If using a directive, you can grab the element that is provided to the link() function, then simply assign it somewhere in the controller

code:

{
	controller: blah,
	link: function(scope, element, attrs, ctrl) {
		ctrl.myElement = element;
	}
}

If you are using AngularJS 1.5, you should be doing this with a Component instead of a Directive. A component is basically a Directive that always is an element, always has a controller alias (if there is a controller, doesn't need to be), always has bindToController=true, and always has an isolate scope. Basically sane defaults. Anyways, you can then just inject $element into your component and then do any DOM manipulation you want in the $postLink handler in the controller.

Skandranon fucked around with this message at 18:18 on Nov 6, 2017

# ? Nov 6, 2017 18:15

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Skandranon posted:

$window is just an angular injectable window object. I think the only reason they made it was for unit testing purposes. I don't say $window.fetch() because people will think I'm talking about some fancy Angular concept.

heh, fair

quote:

Well, there is a crummy way, and a better way. If using a directive, you can grab the element that is provided to the link() function, then simply assign it somewhere in the controller
code:
{
	controller: blah,
	link: function(scope, element, attrs, ctrl) {
		ctrl.myElement = element;
	}
}

Yeah, that's what I'm doing. It feels crummy.

quote:

If you are using AngularJS 1.5, you should be doing this with a Component instead of a Directive. A component is basically a Directive that always is an element, always has a controller alias (if there is a controller, doesn't need to be), always has bindToController=true, and always has an isolate scope. Basically sane defaults. Anyways, you can then just inject $element into your component and then do any DOM manipulation you want in the $postLink handler in the controller.

Cool, I'll refactor into a Component when I get the revision notes from the PM. Turns out he had something fairly different in mind than what he bothered to write down. Weird!

Thanks!

# ? Nov 6, 2017 18:26

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I usually enjoy the talks at Chrome Dev Summit, and I think they're important because Google and Chrome are important, but I rarely have the time or patience to sit through the videos.

Luckily, I just came across this article that summarizes all the talks and the summit as a whole.

quote:

tl;dr: Google wants you to build PWAs, reduce JavaScript file size, use Web Components, and configure autofill. They announced only a handful of features around payments, authentication, Android Trusted Web Activities, Chrome Dev Tools, and the Chrome User Experience Report.

Lots of interesting stuff even though there wasn't a bunch of new stuff announced.

# ? Nov 6, 2017 21:33

MrMoo: Sep 14, 2000

Thermopyle posted:

Luckily, I just came across this article that summarizes all the talks and the summit as a whole.

Can someone translate that article as it is a bit :goatsecx:

quote:

WCs have another big problem: there�s no good server-side rendering strategy for Shadow DOM, and especially no efficient way to �rehydrate� WCs on the client side from server-rendered non-WC output.

Also no idea what this is supposed to mean:
https://twitter.com/samccone/status/914524326145208320

# ? Nov 6, 2017 23:26

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

MrMoo posted:

Can someone translate that article as it is a bit

Also no idea what this is supposed to mean:
https://twitter.com/samccone/status/914524326145208320

WCs are web components, that web standard for doing things like React's Components that no one uses.

Apparently there isn't a good way of rendering html from web component codes on servers (like you can with React et al)

Rehydration is when you take the data sent from the server that was used to render the server-rendered html, and load it in to ~~web-component~~react on the client after the page is loaded.

You render components on the server as html, send the html as a response to a request from the browser, and then on the client side when the javascript has been received, parsed, and evaluated, your framework loads up again and control of the dom/html is turned back over to the client-side framework.

Web components are kind of awkward to use and don't really do what most people want them to do, hence why everyone just uses react

piratepilates fucked around with this message at 00:12 on Nov 7, 2017

# ? Nov 6, 2017 23:53

Tivac: Feb 18, 2003; No matter how things may seem to change, never forget who you are

piratepilates posted:

Web components are kind of awkward to use and don't really do what most people want them to do, hence why everyone just uses react

I love this description of Web Components. :allears:

# ? Nov 7, 2017 01:06

MrMoo: Sep 14, 2000

piratepilates posted:

Apparently there isn't a good way of rendering html from web component codes on servers (like you can with React et al)

Rehydration is when you take the data sent from the server that was used to render the server-rendered html, and load it in to ~~web-component~~react on the client after the page is loaded.

You render components on the server as html, send the html as a response to a request from the browser, and then on the client side when the javascript has been received, parsed, and evaluated, your framework loads up again and control of the dom/html is turned back over to the client-side framework.

Why would you do any of this, it sounds as dumb as balls?

# ? Nov 7, 2017 03:00

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Speed to first render and SEO.

# ? Nov 7, 2017 03:01

piratepilates: Mar 28, 2004; So I will learn to live with it. Because I can live with it. I can live with it.

MrMoo posted:

Why would you do any of this, it sounds as dumb as balls?

With client-side rendering you have no html to render until the javascript is downloaded, parsed, and run. This is often a very small amount of time, but still enough to be noticeable.

With server-side rendering, you get to render out the final html to be displayed, send it over the wire as html, and immediately it'll be parsed and displayed while it's still streaming in.

It's not something you'll want to do until you really care about initial load performance (and a lot of applications will never need that), but for certain sites it ends up mattering a lot.

You'll see that in consumer based companies with stuff like Amazon's statistics where every extra half a second (or whatever) ends up losing them millions of dollars from customers getting bored and just going elsewhere, also stuff like cell phone users (and it turns out there are a lot of people living in developing countries that are now getting internet access for the first time, and it's through cell phones and data plans that may be slow) where you need it to be as fast as possible (and parsing javascript on a mobile device will be slower than on desktop).

https://www.youtube.com/watch?v=V8oTJ8OZ5S0
https://jakearchibald.com/2017/netflix-and-react/
https://www.fastcompany.com/1825005/how-one-second-could-cost-amazon-16-billion-sales
https://www.youtube.com/watch?v=62xd25kEZ3o&t=27605s

piratepilates fucked around with this message at 03:12 on Nov 7, 2017

# ? Nov 7, 2017 03:07

MrMoo: Sep 14, 2000

The goal is worthy but aside of absurdity of Netflix bikeshedding on this, it's their own fault to introducing such a gigantic library already, the target market of cheap Android phones on sub-par 3G connections is wholly assuming the browser can multitask efficiently. I can see something like Snackoverflow trying to implement this but they push such a gigantic piece of HTML and CSS up front that it still appears a net loss in UX. Cheap Android phones are made to only just about work, everything is slow and terrible which is why you end up with native apps. I think the developers have a gigantic misunderstanding on bandwidth here, I have tmo with 128KB international data roaming, almost every website is utterly awful and that's a lot faster than beep beep boop modem days of yore.

# ? Nov 7, 2017 15:48

Lumpy: Apr 26, 2002; La! La! La! Laaaa!; College Slice

I'm not sure which of the three threads that share React / JS / Web dev questions we were talking about this in a few weeks ago, but this is the first one I saw, so I'm posting here! A command-line tool to turn SVGs into React components: https://github.com/smooth-code/svgr

# ? Nov 7, 2017 16:14

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

MrMoo posted:

The goal is worthy but aside of absurdity of Netflix bikeshedding on this, it's their own fault to introducing such a gigantic library already, the target market of cheap Android phones on sub-par 3G connections is wholly assuming the browser can multitask efficiently. I can see something like Snackoverflow trying to implement this but they push such a gigantic piece of HTML and CSS up front that it still appears a net loss in UX. Cheap Android phones are made to only just about work, everything is slow and terrible which is why you end up with native apps. I think the developers have a gigantic misunderstanding on bandwidth here, I have tmo with 128KB international data roaming, almost every website is utterly awful and that's a lot faster than beep beep boop modem days of yore.

There is often a noticeable difference to time of first rendering (even on high end phones and desktop PCs) with server sided rendering when using any of the major JS frameworks, and it's not terribly complicated to setup.

# ? Nov 7, 2017 16:49

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

MrMoo posted:

The goal is worthy but aside of absurdity of Netflix bikeshedding on this, it's their own fault to introducing such a gigantic library already, the target market of cheap Android phones on sub-par 3G connections is wholly assuming the browser can multitask efficiently. I can see something like Snackoverflow trying to implement this but they push such a gigantic piece of HTML and CSS up front that it still appears a net loss in UX. Cheap Android phones are made to only just about work, everything is slow and terrible which is why you end up with native apps. I think the developers have a gigantic misunderstanding on bandwidth here, I have tmo with 128KB international data roaming, almost every website is utterly awful and that's a lot faster than beep beep boop modem days of yore.

It's a tradeoff. If you can load a client-side framework, then all subsequent communication can be through JSON, which will be smaller and faster than delivering rendered pages and the next time the user hits your site, the framework is probably already cached, so you save time and bandwidth every subsequent visit. Yes, you run into the problems you've identified unless you get really nuts with it and make your initial HTML part of the page with inlined CSS so the user gets to see something really quickly while the rest of the framework finishes coming in and taking over. Then they've got a cached copy when they, hopefully, come back.

# ? Nov 7, 2017 17:37

MrMoo: Sep 14, 2000

If one is targeting cheap phones I would assume there is little to no cache at all which is when the technique would be highly counterproductive. It's highly subject to what the determination of that base is. If you take China, a lot of factory workers have pretty drat powerful fancy phones and update frequently. There are definitely many bargain bucket phones hitting the news for India, for example $3.60 smartphone.

I'm coming at this from the odd angle of working on a high profile but niche Web Components project. Initial load over HTTP/2 and everything else over WebSockets, I don't care about initial load but it happens to be pretty good but the pages are simple. I have users accessing over WLAN on a wide variety of devices and even stuff for gigantic wallboards works well on Android, only awkward part is trying to pull in literally hundreds of large graphics, but that's not surprising.

My understanding of WC is that you would never render them server side as they should be treated like any other HTML tag, in fact you can now replace standard tags. It would thus be perfectly fine to wrap WC tags with React or Angular for the higher level functionality of creating complex pages and forms.

MrMoo fucked around with this message at 19:08 on Nov 7, 2017

# ? Nov 7, 2017 18:49

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

MrMoo posted:

If one is targeting cheap phones I would assume there is little to no cache at all which is when the technique would be highly counterproductive. It's highly subject to what the determination of that base is. If you take China, a lot of factory workers have pretty drat powerful fancy phones and update frequently. There are definitely many bargain bucket phones hitting the news for India, for example $3.60 smartphone.

I'm coming at this from the odd angle of working on a high profile but niche Web Components project. Initial load over HTTP/2 and everything else over WebSockets, I don't care about initial load but it happens to be pretty good but the pages are simple. I have users accessing over WLAN on a wide variety of devices and even stuff for gigantic wallboards works well on Android, only awkward part is trying to pull in literally hundreds of large graphics, but that's not surprising.

My understanding of WC is that you would never render them server side as they should be treated like any other HTML tag, in fact you can now replace standard tags. It would thus be perfectly fine to wrap WC tags with React or Angular for the higher level functionality of creating complex pages and forms.

You actually load assets over WebSockets? This sounds interesting, can you elaborate on why/how?

# ? Nov 7, 2017 19:52

MrMoo: Sep 14, 2000

Yes, all assets over WebSockets. The reasons are that assets are actually live: they can update at any time and so every asset request is actually a subscription, I have no concept of one-off snapshots, the larger reason is to simplify the entire mess that is connectivity, fault-tolerance and load sharing. WebSockets allow me to manage that connection and so if an error occurs I can fallover to another endpoint and resync the entire asset list and the consuming WC entities are none the wiser. Really simplifies things a lot. It is literally impossible to get stale data from infrastructure issues which is my big win, diagnosing those is a PITA.

Subscribing to new assets:

JavaScript code:

this._esignal_handle = subscribe({ service_name: "ESIGNAL", key: newValue });
this._esignal_handle.addEventListener("refresh", this._on_esignal_refresh_bound);
this._esignal_handle.addEventListener("update", this._on_esignal_update_bound);

WIth matching handlers:

JavaScript code:

_on_esignal_refresh: function(e) {
        this._clear_esignal();
        this._on_esignal_update(e);
},               
_on_esignal_update: function(e) {
        const json = e.data;
        if(typeof json.data.listexg !== "undefined") {
                const listexg = json.data.listexg === "ARCX" ? "PSE" : json.data.listexg;
                this.set('primaryExchange', listexg);
        }   
        ...
}

MrMoo fucked around with this message at 20:48 on Nov 7, 2017

# ? Nov 7, 2017 20:45

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Thermopyle posted:

I usually enjoy the talks at Chrome Dev Summit, and I think they're important because Google and Chrome are important, but I rarely have the time or patience to sit through the videos.

Luckily, I just came across this article that summarizes all the talks and the summit as a whole.

Lots of interesting stuff even though there wasn't a bunch of new stuff announced.

Just made it all the way through and boy oh boy it'll be an interesting world when I can finally stop caring about IE 11 at work.

# ? Nov 8, 2017 17:06

geeves: Sep 16, 2004

Webpack question: How does ~12kb of imports turn into 200kb when transpiled and bundled? These are all small global helper methods and static objects. ~ 7 files overall.

edit: If I move them from separate files into 1 file, the size increases from 200k to 230k :psyduck:

Also, not one of these options stops sourcemaps from being generated https://webpack.js.org/configuration/devtool/

Munkeymon posted:

Just made it all the way through and boy oh boy it'll be an interesting world when I can finally stop caring about IE 11 at work.

Just as I think we're close to this day, we sign on another client who are stuck in the stone age and Windows 7 and IE11 users only and won't allow Chrome.

geeves fucked around with this message at 18:55 on Nov 8, 2017

# ? Nov 8, 2017 18:28

SimonChris: Apr 24, 2008; The Baron's daughter is missing, and you are the man to find her. No problem. With your inexhaustible arsenal of hard-boiled similes, there is nothing you can't handle.; Grimey Drawer

MrMoo posted:

Why would you do any of this, it sounds as dumb as balls?

In addition to the performance issue, server-side rendering is also necessary if you want your users to post links to your site on, say, Facebook or Twitter and have the link show a preview of the destination. With pure client-side rendering, the preview is always blank.

# ? Nov 8, 2017 18:56

duz: Jul 11, 2005; Come on Ilhan, lets go bag us a shitpost

geeves posted:

Just as I think we're close to this day, we sign on another client who are stuck in the stone age and Windows 7 and IE11 users only and won't allow Chrome.

We deal with governments exclusively. Up until recently we had several that were IE8 on XP only and nothing else was permitted. I just checked a couple of them last week and it looks like they're on Chrome or IE 11 now so I got permission to put an IE8 block in place on 1/1/2018.
Altho we amusingly had the reverse recently, a foreign government said the software had to support Windows 10 & Edge or Chrome and thankfully we could guarantee that (a sister company couldn't, lawl).

# ? Nov 9, 2017 04:10

geeves: Sep 16, 2004

geeves posted:

Webpack question: How does ~12kb of imports turn into 200kb when transpiled and bundled? These are all small global helper methods and static objects. ~ 7 files overall.

Figured this out. It was remove babel-runtime-compiler plugin, which I thought was needed, but wasn't for IE11.

Still figuring out sourcemaps tho.

# ? Nov 9, 2017 04:55

Sedro: Dec 31, 2008

geeves posted:

Webpack question: How does ~12kb of imports turn into 200kb when transpiled and bundled? These are all small global helper methods and static objects. ~ 7 files overall.

https://www.npmjs.com/package/webpack-bundle-analyzer

# ? Nov 9, 2017 05:33

Munkeymon: Aug 14, 2003; Motherfucker's got an
armor-piercing crowbar! Rigoddamndicu𝜆ous.

Chrome threw threw the Audits tab in my face when I clicked the Responsive option on the device mode options bar so I figured I'd try it and, for some reason, running an audit slows something down so much that it takes six seconds to paint anything with a total load time of 18 seconds. Whole thing loads in 1.5 seconds if I just hit refresh with DOMReady at .5 (the ZenDesk plugin takes ~a second to come in and bootstrap). It also defaults to checking for PWA features like service workers and crap like that, but at least you can turn that off.

At least the accessibility audit is useful, I guess.

# ? Nov 9, 2017 15:08

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

I'm always finding new things in chrome dev tools.

I'm convinced it has infinite features.

# ? Nov 9, 2017 17:12

Lonely Wolf: Jan 20, 2003; Will hawk false idols for heaps and heaps of dough.

Munkeymon posted:

At least the accessibility audit is useful, I guess.

It's far closer to useless. Use the SiteImprove chrome extension instead.

# ? Nov 9, 2017 17:47

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

It's not uncommon for me to find bugs in DefinitelyTyped type declarations. This manually-maintained system of types has always rubbed me the wrong way a little bit. How confident should I be that the author correctly implemented the types the JS library actually uses? My anecdotal observation leads me to think "not very confident". (of course, it's often good enough)

Here's a neat paper wherein they demonstrate a system for automated testing of types in TypeScript. They tested their system against the DT declarations for 54 libraries and found thousands of type mismatches. They note that there are not likely literally thousands of type mismatches and that many of them are different manifestations of the same root type mismatch.

However, they then randomly sampled 124 of the reported mismatches and found that 63 of them were definitely type mismatches that the programmer would want to fix, 47 of them the programmer would want to fix if non-nullable types is enabled in TS, and 14 of them were basically not something you would care about.

Here's a bugged TS declaration...

code:

declare var Path: {
  root(path: string):  void;   # path is a string, right?
  routes: {
    root: IPathRoute,   # I'm an IPathRoute!
  }
};
  
interface IPathRoute {
  run(): void;
}

And the actual JS...

JavaScript code:

var Path= {
  root: function(path) {
    Path.routes.root = path;   # Wait a second, we're assigning a string type to an IPathRoute!
  },
  routes: {
    root: null
  }
};

# ? Nov 9, 2017 18:40

Skandranon: Sep 6, 2008; fucking stupid, dont listen to me

Thermopyle posted:

It's not uncommon for me to find bugs in DefinitelyTyped type declarations. This manually-maintained system of types has always rubbed me the wrong way a little bit. How confident should I be that the author correctly implemented the types the JS library actually uses? My anecdotal observation leads me to think "not very confident". (of course, it's often good enough)

Here's a neat paper wherein they demonstrate a system for automated testing of types in TypeScript. They tested their system against the DT declarations for 54 libraries and found thousands of type mismatches. They note that there are not likely literally thousands of type mismatches and that many of them are different manifestations of the same root type mismatch.

However, they then randomly sampled 124 of the reported mismatches and found that 63 of them were definitely type mismatches that the programmer would want to fix, 47 of them the programmer would want to fix if non-nullable types is enabled in TS, and 14 of them were basically not something you would care about.

Part of the problem is often the type files are not written by the owner of the library they are for, they are written by someone who wanted to use the library in TypeScript, so is either only interested in some of it working, or doesn't understand the library that well. If a library is natively written in TypeScript with strict type rules in place, and the type file is simply outputted via compilation, it is a lot better.

But I don't see a better way forward for d.ts files for native JS libraries.

# ? Nov 9, 2017 18:49

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Skandranon posted:

Part of the problem is often the type files are not written by the owner of the library they are for, they are written by someone who wanted to use the library in TypeScript, so is either only interested in some of it working, or doesn't understand the library that well. If a library is natively written in TypeScript with strict type rules in place, and the type file is simply outputted via compilation, it is a lot better.

But I don't see a better way forward for d.ts files for native JS libraries.

Yeah, that's definitely true.

If I'm spitballing things to improve the situation, I think maybe some sort of toolchain that uses the code from this paper (TSTest) to automatically check libraries submitted to DT.

# ? Nov 9, 2017 19:11

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

New guy at work is just learning React and was pushing a new feature today to an app that I built, so I tried to give him some thoughts before he merged branches. And after I gave him a small critique, he said �I get what you�re saying, but i don�t think it�s correct�

:allears:

# ? Nov 10, 2017 00:37

prom candy: Dec 16, 2005; Only I may dance

Grump posted:

New guy at work is just learning React and was pushing a new feature today to an app that I built, so I tried to give him some thoughts before he merged branches. And after I gave him a small critique, he said �I get what you�re saying, but i don�t think it�s correct�

What was the critique?

# ? Nov 10, 2017 03:16

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

He was doing an if/else based on a variable and I suggested he use react state instead and write less code.

His way wasn�t wrong at all, but if you�re gonna learn react, learn react

# ? Nov 10, 2017 03:53

Sedro: Dec 31, 2008

Thermopyle posted:

It's not uncommon for me to find bugs in DefinitelyTyped type declarations. This manually-maintained system of types has always rubbed me the wrong way a little bit. How confident should I be that the author correctly implemented the types the JS library actually uses? My anecdotal observation leads me to think "not very confident". (of course, it's often good enough)

I'd rather see some runtime instrumentation for debug builds, to raise an error if anything ever contradicts the type declaration

# ? Nov 10, 2017 04:19

Love Stole the Day: Nov 4, 2012; Please give me free quality professional advice so I can be a baby about it and insult you

Grump posted:

He was doing an if/else based on a variable and I suggested he use react state instead and write less code.

His way wasn�t wrong at all, but if you�re gonna learn react, learn react

Can I have his job? /s

# ? Nov 10, 2017 05:53

prom candy: Dec 16, 2005; Only I may dance

How do you guys organize your large React apps? I've been doing src/components/pages and src/components/shared but it's starting to feel unwieldy. Should I just organize by concern? src/components/auth, src/components/products, src/component/cart, src/components/orders, src/components/shared, etc.? Should I make distinctions between components that are rendered as pages (i.e. as routes in React Router) vs. components that are just smaller pieces? Should I have a separate containers folder for components that connect to Redux? Trying to come up with a system that will scale as we head into having hundreds of components.

# ? Nov 11, 2017 04:26

Maluco Marinero: Jan 18, 2001; Damn that's a
fine elephant.

prom candy posted:

How do you guys organize your large React apps? I've been doing src/components/pages and src/components/shared but it's starting to feel unwieldy. Should I just organize by concern? src/components/auth, src/components/products, src/component/cart, src/components/orders, src/components/shared, etc.? Should I make distinctions between components that are rendered as pages (i.e. as routes in React Router) vs. components that are just smaller pieces? Should I have a separate containers folder for components that connect to Redux? Trying to come up with a system that will scale as we head into having hundreds of components.

I feel the same about folders that handle component scale, ie, for us it's atoms, molecules, templates, layouts. Works for small to mid size, but once you get right into proper component development it just feels like the wrong differentiation to make, and we've started doing it by concern in our big project, ie:

code:

/front-end/ui
  /Designs
  /Projects
  /Stories
  /Teams
  /SomeOtherFeature

with a couple of more general UI folders for things that truly share around like

code:

/front-end/ui
  /typography
  /config (contains palette, spacing, theming info)
  /atoms (small components that get used everywhere)
  /base (styling of bare DOM elements to get us to a reset level, we don't style on DOM elements specifically anywhere else)
  /_ (this is a shorthand for our utilities folder, general toolbox functions for stylesheets and javascript specific to UI)

Generally I haven't separated out major views, and instead assume that I will name anything that is a View with the word View in it, ie TeamHomeView, ProjectView, etc. Honestly don't mind this. This has the added benefit that in our component library because it groups by folder it's easy to easy all the stuff related to a single feature, which is more valuable to me than seeing every abstract type (page, atom, template, molecule, etc) of a component.

Maluco Marinero fucked around with this message at 05:11 on Nov 11, 2017

# ? Nov 11, 2017 05:07

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Yeah, I haven't really seen a project organization methodology that is equally good across projects of all scales.

# ? Nov 11, 2017 16:02

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Here's an interesting (to me at least) history of how React came about from Pete Hunt.

It's an audio interview but there's a good transcript if you scroll down...

# ? Nov 12, 2017 21:36

teen phone cutie: Jun 18, 2012; last year i rewrote something awful from scratch because i hate myself

Thermopyle posted:

Here's an interesting (to me at least) history of how React came about from Pete Hunt.

It's an audio interview but there's a good transcript if you scroll down...

Got around to listening to this today. Super interesting stuff. Hearing about how Instagram's team worked made me feel a lot better about my job. Mostly about how they just pushed stuff live continuously and didn't really have any concrete processes

# ? Nov 14, 2017 18:21

Adbot: ADBOT LOVES YOU

# ? May 16, 2024 10:09

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Grump posted:

Got around to listening to this today. Super interesting stuff. Hearing about how Instagram's team worked made me feel a lot better about my job. Mostly about how they just pushed stuff live continuously and didn't really have any concrete processes

People posting in programming threads have one perspective.

People running businesses have another perspective.

Us programmers often want everything to be set up with a sweet CD/CI system with tests and static typing and just everything perfect. On the other hand it's important to ship stuff ASAP and fix your poo poo later.

# ? Nov 14, 2017 20:14

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Modern front-end development: skinny jeans and handlebar mustaches ITT

«‹›235 »