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

«‹›2 »

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ender.uNF posted:

Anyone have suggestions for organizing large applications? Most of the examples for various tools and frameworks are laughably simple, but if you aren't building the next Twitter, you end up with a mess. In ASP.Net MVC terms, a million partial views strung together, most of which have intimate knowledge of the HTML generated by other partial views because the app actually needs to support a complex layout suitable to replace a full-blown Win32 app.

I've been slowly chipping away at the problem by trying to make JS APIs that hide implementation details of each "widget" or "component" on the page, but it is difficult, error prone, and requires all the other devs on the team to avoid the temptation to just have their component assume it has a child grid named resultsGrid that must be 500px wide and can be refreshed with resultsGrid.Refresh().

We are dealing with million+ object datasets with each object having potentially 1000+ properties. The number of things the user can do is insane, there is no way the UI can be less complex or (laugh) a single-page application.

Oh, do you work for a hosed up medical company? Are they using google closure? Trying to replace a win32 gui with a webapp is a loving bad idea and won't make anyone happy.

# ¿ Dec 21, 2013 17:21

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 20:16

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ender.uNF posted:

No. We already replaced the Win32 client with a web one, it just has much worse performance than it should because everything does post backs on WebForms, or uses massive callbacks containing the world (that has to run the entire page's post back logic anyway). I managed to get WebForms and MVC to interop and our new features are using MVC, so performance wise we are in much better shape, but my grand plan to make the UI clean and more maintainable was promptly turned into spaghetti code once everyone else was let loose on it.

This is an inherent problem with doing UI in client side javascript - it's too easy to monkey patch and if you have too many people developing the UI, you end up with bad poo poo happening.

# ¿ Dec 22, 2013 00:16

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Helicity posted:

DOM3 is 11 years old, and how we use Javascript, and even the web, has changed quite a bit since then. Probably the worst thing about it is that every browser has implemented it differently. That there was an almost ubiquitous need for an API on top of the DOM like jQuery is the best evidence that it was broken. Although things have gotten better for small sites that only need to support modern browsers, large sites can't just say "gently caress off" to IE9 users (yet). Even with new features being discussed in 2015, we have Safari lagging behind, Mozilla/Google fighting among themselves and implementing things differently. A portion of the toolchain hell that is commonly lamented about in here is directly trying to workaround limitations of the DOM.

edit: GraphQL chat - a ton of my work is building/maintaining a broad variety of APIs, so I'm starting to poke around and see if it could solve any of my problems without introducing other ones that are worse. That's not really a topic for front-end dev chat, but I'd be interested in hearing others' experiences with it.

JQuery isn't useful past IE8 or so. It's a frankenstein monster consisting of
a) A really hosed up event handling normalization library that made sense when you needed to support both IE8 and Chrome but is now slow as poo poo
b) JQuery selectors, which are great for writing horrible monkey patches if you're too lazy to put ids and classes on the elements you create.
c) A half-baked promise library that works really well as long as nothing throws an exception but is otherwise functional. Hands down the best thing in the JQuery library.
d) A wrapper for XHR that again made sense when you used to support IE7 but now is only useful because of JQuery's aforementioned half-baked promise library.
e) A bunch of functions that mirror exactly vanilla JS functions except it's in JQuery.

# ¿ Aug 26, 2015 13:07

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

obstipator posted:

I still use jQuery because it makes convenient and consistent shorthands for funcs I use all the time.

$('.poop').on('click', fart);

It really depends on if you care about performance and event listener leaks. Most of the time you probably don't. But if you use the JQuery event handling, there's a whole bunch of bullshit code that does event normalization - like, in a mousemove handler, I've seen JQuery take 30% CPU time just doing event normalization (JQuery.fix()), just so the event will look the same (sort of) in IE8 as it does in Chrome or Firefox. Another problem is that if you leak a regular event handler (like say you attach an event handler to an element and remove the element) - with regular event handlers, it goes away. With JQuery, JQuery has its own layer that holds references to whatever JQuery event handlers are assigned, and that layer will keep a reference to the element that was removed, and it'll never garbage collect and you're hosed. Similarly, if you use like $.proxy instead of .bind(this), you can get screwed because since JQuery implemented keeping the scope in the library, whatever scope you're holding will just stick around and not garbage collect.

So in short it's really easy to get hosed when writing long running single page apps using JQuery. It's not impossible to use if you're disciplined but JQuery has wasted a lot of my time in my front end career so far.

# ¿ Aug 28, 2015 13:19

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

The Wizard of Poz posted:

One of the major potential benefits I can think of that using TypeScript might offer, would be an IDE being capable of using decent Intellisense and 'instant' error checking (so if you type the wrong property name, you find out right away thanks to a red line or something). Is there an IDE that supports this? Please keep in mind I've never actually tried TypeScript.

Microsoft Visual Studio 2013.

# ¿ Sep 3, 2015 10:59

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

ddiddles posted:

How much vanilla javascript knowledge is required for an entry level front end dev job?

I've been doing HTML/CSS work for the past five or so years, but it was usually because I was the companies IT guy, so obviously I must know "how to make the internet sites". I'm pretty comfortable with HTML5/CSS3 and can build a responsive site from scratch, but my javascript experience was really lacking, mostly consisting of taking premade scripts/plugins and knowing enough to implement and edit the basics of them to fit the company needs.

I'm moving from the US to the UK in 8 months, and really wanted to get my skills up to be able to land an entry level front end job, so I've been focusing on learning vanilla javascript before moving on to any frameworks.

I know it's kind of an open ended question, but does anyone know of some sort of checklist of concepts/abilities most entry level dev jobs require?

EDIT: Realized theres a newbie get a job thread, I'll move it if this question doesn't belong here.

You're going to confuse people if you say you're comfortable with HTML5 but aren't a javascript developer. The interesting parts of HTML5 are the apis exposed to javascript developers (like HTML5 canvas/web storage/<video tag>/HTML5 drag and drop/ File API/ geolocation).

# ¿ Oct 15, 2015 12:30

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Vulture Culture posted:

Management is usually the ones explaining the code to Bangalore

wtf? at my company management just allocates us Indian contractors, we communicate directly.

# ¿ Dec 29, 2015 09:36

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Pollyanna posted:

We've been wrestling for weeks with a problem where our app doesn't work on IE or Safari or what have you, and only now are we figuring out why: String.startsWith isn't available on IE11. What fucks me up is that we're already using Lodash, which works just fine on IE11 and has startsWith, yet the people who propagated the original, non-portable solution didn't even bother to use it or check to see if their own solution worked on one of our target browsers. I thought this poo poo was front-end 101? Like, really goddamn basic?

This whole thing makes me sad. The project has been an exercise in how not to make a front-end.

How does that take more than navigating to the web page once with "disable script debugging" disabled in IE to figure out?

# ¿ Apr 19, 2017 11:10

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Honest Thief posted:

I guess the issue is at the API server itself, but I'm not sure if that's something they did on purpose or what, I mean I could try going through jsonp.

edit:gently caress this, I'll make a small backend api and run the external requests through there

If you run Chrome with --disable-web-security it'll ignore all cors errors and let you do your thing.

# ¿ May 4, 2017 03:56

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

a hot gujju bhabhi posted:

I'm trying to understand the various options for transpiling TypeScript. I'm not sure which is the best approach for my app. For medium-large apps do people tend to transpile down to a single file, or should I be using a bunch of files with a client-side module loader? I assume the way to go is to transpile to separate files and use something like SystemJS to load the modules dynamically, does this sound right?

The one giant TS file run through webpack is the standard and will perform better except in cases where you have so much goddamn javascript that lazy loading is beneficial and you have a requirement to have fast page loads(that's usually around the dozens of megs point.) And honestly the one time I had that problem, I rolled my own loader because it would've taken longer to figure out how to use System.js than to write it from scratch.

Bruegels Fuckbooks fucked around with this message at 02:31 on Jun 15, 2017

# ¿ Jun 15, 2017 02:29

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Dogcow posted:

From what little I've messed with it I really like C# but I really almost never see it in job descriptions even if you include .NET. Has MS just failed again? I don't understand why a good rear end thing like C# withers on the vine for modern web dev but apparently RoR is still everywhere at least by my googling.

Maybe it's just a kind of generational problem and all the cool teenagers making Unity games will make C# the poo poo in 5 years. One can hope anyway..

ASP .net MVC is leagues better than dealing with RoR/node/django. RoR/php/node etc. got popular because those projects are free, open source software, and run on linux, and people gravitate towards free (the alternative being paying money for a windows server license and running on IIS, which costs money and sucks, and that was after the cost of the visual studio licenses, etc). MS is realizing this - ASP.net MVC and .Net Core went open source, and the introduction of OWIN and .NET core decouples ASP.NET from IIS and allows deployment to other platforms.

Now knowing this, would I go out and base a new project on .Net Core? Probably not, it's relatively new and I suspect somewhat immature - but it might be good in the future.

# ¿ Jun 16, 2017 04:57

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Tei posted:

Do people care about that? for me is the ability to google any problem and find solutions. With closed source projects you get less hits on the google searchs.

Open source makes it easier to troubleshoot problems, but developing free software means that you don't have to worry about the whole microsoft eco-system, with its 1.2k a year per developer MSDN Visual Studio Pro subscriptions (enterprise is 6k a year), and then come deployment, a lot of hosting companies didn't want to have to deal with buying thousands of windows server licenses or having to make sure everything is licensed so microsoft doesn't sue you. Medium-sized microsoft development shops might be paying hundreds of thousands of dollars a year to microsoft on msdn alone. If you're one developer or doing something non-commercially, or if you just have one windows server, the cost difference is completely negligible.

# ¿ Jun 16, 2017 12:20

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

a hot gujju bhabhi posted:

So I'm trying to get this to work, I was hoping to just be able to use the TypeScript compiler (tsc) with a tsconfig.json configured to spit out a single file, but it's not working. Even as a single file it's including SystemJS stuff. Do I have to use a third party tool for this (i.e. webpack?) Is there somewhere I can find up-to-date documentation on this, everywhere seems to suggest different methods and tools for doing this... (welcome to front-end development, I know).

Basically I don't want something that is like "copy-paste this config file and type npm watch". I want to manually introduce each tool and understand why they're being introduced and what role they're playing so I can stick with the bare minimum while I learn. As you can tell I'm woefully underskilled at this stuff, backend is my day-to-day.

If you're a backend developer who is familiar with Visual Studio, just making the TS project in Visual Studio 2013 or later will have the shortest learning curve. If you're using visual studio 201X, you can right-click your project in the solution explorer and chose Properties> Click on the TypeScript Build tab. Select Combine JavaScript output into file, and type in a name to use for your combined file in the input field right next to the option.

Otherwise in TSC you can --outfile "name of file" to combine to single file.

# ¿ Jun 19, 2017 01:15

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Pollyanna posted:

Having trouble figuring out exactly why a `hide` event is happening when I click on a particular element. For background, I'm leveraging Overlay from react-bootstrap, and whenever I have `rootClose` set to true (i.e. close this Overlay when the overlay is clicked out of), clicking on the button that opens an Overlay opens and then immediately calls hide on it, causing it to basically never pop up. This only seems to happen when the Overlay is spawned from a Modal. Setting `rootClose` to false solves the problem, but then I lose the original click-out-to-close functionality, which will probably piss off my product owner who hates whenever functionality is lost.

I tried using the Chrome performance monitor to try and figure out why the hide event was happening, but I couldn't really figure out what I was looking at and attempts at debugging (literally, as in the `debugger` statement) failed due to some bundling issues. Anyone have tips for debugging this? I'm at a bit of a loss.

Try putting a DOM breakpoint on the element in Chrome debugger - chrome can break when an element is changed.

Another thing you could do is in IE11, use the F12 debugger there, highlight the element in the DOM explorer, and put breakpoints on every method listed in the events tab and see if that works. (Chrome has an events tab but it doesn't seem as reliable as IE's)

# ¿ Aug 16, 2017 21:55

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Nolgthorn posted:

Bind returns a new reference, it performs essentially the same thing as an inline function in this case.

well, it's more that bind makes it so when the event handler is called, the context of the invoked function is the object passed in as first parameter, with the parameters being the subsequent args. arrow function and bound functions are pretty similar, but I generally like bound functions over arrow functions in event handlers because arrow functions can't be invoked recursively (as they are not named functions) and you might want to invoke an event handler recursively so you can debounce it.

# ¿ Sep 24, 2017 14:26

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Thermopyle posted:

There's nothing wrong with Angular really...its right in there with React and Vue as far as being a modern thing that makes front end work better.

Angular early adopters were smoking crack. Recent angular is better but it still has a learning curve. I'd be willing to work with a project that uses a recent angular but I probably wouldn't pick it for a new project.

# ¿ Sep 24, 2017 20:34

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

prom candy posted:

Do I have to get on a Microsoft stack if i go that direction? Like IIS and poo poo? I don't think I could handle that.

The explicit goal of .NET core is to be able to use ASP.NET on non-IIS, non-microsoft platforms.

# ¿ Sep 29, 2017 06:10

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

gmq posted:

I have one of those awful style questions: Should every type be explicit in Typescript or maybe allow contextual typing for the ones that can be inferred?

I am a complete nazi about types in Typescript, even to the point where I'll do:

code:

var x: Foo = new Foo();
var y: number = 5;
var z: string = "foo";

I recognize that in the above examples, the implicit typing would work just as well, but implicit typing is a gateway drug that leads to code looking like regular javascript.

# ¿ Sep 30, 2017 09:34

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Love Stole the Day posted:

While we're being Nazis or whatever... if I remember correctly, I think the official TypeScript thing says that you should be doing "let" instead of "var"? Sorry if wrong

I started the project I'm working on now with Typescript 1.1, and let was introduced in 1.5, so I look at TS code every day that uses var instead of let all over the place. I've been trying to use let in new code just to look trendy but tbh it doesn't really matter, there is something hosed up with your code anyway if let versus var actually makes a difference (const is useful though).

# ¿ Sep 30, 2017 18:29

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Nolgthorn posted:

Is MDN better? The same information always seems to be on both.

MDN is much better maintained, and the browser compatibility section is extremely useful if you do this for a living. w3schools is generally 5 years out of date and has no information about browser compatibility.

# ¿ Oct 21, 2017 07:40

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Lumpy posted:

I'm having a Stupid Day and want you guys to think for me! I have a list of urls. I send these URLs off to a service to score them. This can take up to a second each, so obviously I don't want to block the UI while this happens because there could be a couple hundred!! Since I do want the UI to update as each URL is processed (a progress bar and showing the results so far) ditching the whole thing off to a WebWorker may not be the best option (but maybe it is?) So how do I do this (this is in React / Redux btw) in a non-blocking way:
JavaScript code:
const scoreURLs = listOfURLs => {
  return ( dispatch, getState ) => {
    listOfURLs.forEach( _url => {
      // this will perform a fetch, then update state via an action 
      // on success or failure
      dispatch( scoreTheUrl( _url ) ); 
    })
  }
}
Is that already going to do what I want because the scoreTheUrl calls return a fetch / Promise? Do I need to setTimeout those calls? Why can't I think today, even though I already had two cups of coffee?

This isn't strictly redux but you could do something like:

code:

var promises = urls.map(url => fetch(url).then(y => y.text()));
Promise.all(promises).then(results => {
    // do something with results.
});

In the case of the connection limit, xhr will wait for a connection to become available but won't block on it, still event based (although if all connections are timing out the browser will hang because it can't establish a new connection, but you've got bigger problems if that happens)

# ¿ Feb 2, 2018 14:55

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Vincent Valentine posted:

But man, I just had to work on a legacy project where this guy installed a dependency for everything. There's dependencies for generating dates, tooltips, formatting paragraphs, load bars, sliders, buttons, dropdowns, everything. You name it, if you could possibly stick it on a page, this guy had a dependency for it. Dates are already native in JavaScript, there's like thirty different ways to display them, even!

The date object has so many hosed up idiosyncrasies between browsers that I can't recommend using bare Dates unless you want to deal with super hosed up esoteric bugs.

For example, one time, we had a web service that returned a date as an ISO string - it worked OK on IE11/Chrome/etc, but on IE9, 1% of the time, Date.parse would just return the string "invalid date".

It turns out what was happening is that the format for ISO string is:

YYYY-MM-DDTHH:mm:ss.sssZ (e.g. 2018-02-06T13:36:51.710Z)

However, the web service would not preserve trailing 0's. So say you have:
2018-02-06T13:36:51.7Z

Date.parse("2018-02-06T13:36:51.7Z") will work fine in Chrome, IE10, etc.

In IE9, Date.parse("2018-02-06T13:36:51.7Z") will return 'INVALID DATE', because according to the standard, an ISO string must always be 24 or 27 characters long - so clearly, that string is not an ISO string. Brilliant.

Let's not get into the arbitrary ways Chrome and IE vary on basis of timezone handling, or region formatting. gently caress using the raw date object.

# ¿ Feb 6, 2018 14:43

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Thermopyle posted:

Context strikes me as something that, while useful, is going to require a lot of care to avoid becoming global variables by another name.

Every class I've encountered in the working world that had 'context' in the name ended up being a singleton housing hundreds of global variables.

# ¿ Apr 24, 2018 15:02

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

a hot gujju bhabhi posted:

Why are there no logs? How do you look at historical events?

if this is still that stock ticker project, if there's a problem, he'll see it on TV.

# ¿ Jun 14, 2018 11:53

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

JazzmasterCurious posted:

Yup. It's one thing to write it to get the practice, but there's (almost) always something done already that 20-1000 people have contributed input and fixes to already.

it's thinking like that which ended up making me a contributor to the SJCL when I was doing my master's project.

# ¿ Jun 19, 2018 13:54

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Thermopyle posted:

Code modularity and the idea of libraries that code modularity enabled, is among the greatest ideas to ever arise in computer languages.

Use libraries.

actually javascript is unique in how terrible libraries can be, and web developers are particularly terrible at assessing whether or not they are any good because they are (mostly) all fresh out of college, so just because you hear a library name at some meet-up or something, you really can't assume the library is any good at all. i'm not saying that you shouldn't use libraries, you just need to be smart about isolating them from your project. i've spend literally months debugging poo poo in the jquery library for instance - that's months i could've spent on solving problems with business value.

Bruegels Fuckbooks fucked around with this message at 16:49 on Jun 19, 2018

# ¿ Jun 19, 2018 16:46

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Thermopyle posted:

Yeah, so instead of finding a good library, we should let all these terrible web develoeprs develop the functionality from scratch.

it depends on the problem you're trying to solve. like, would i roll my own js crypto library or date library? gently caress no. but it can actually take longer and be a bigger cost to use a library than to just solve the problem yourself. it's not like you're standing on the shoulders of giants with this web development stuff, there's an incredible amount of bs.

# ¿ Jun 19, 2018 19:17

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Doom Mathematic posted:

What went wrong in jQuery?

Let me talk about jquery event handling.

So like, around the IE6/IE7 days, different browsers had different, incompatible properties in their event handlers. JQuery's approach to fixing this was to 'fix' the event using JQuery.event.fix(), which basically would try to make it so you could use event handlers in a cross-browser way without doing a bunch of bullshit.

Unfortunately:
a) JQuery.event.fix() is loving slow. It uses properties that can trigger browser reflows, and I've seen fix take upwards of 30~40% of cpu time in mousemove handlers just to normalize properties.
b) JQuery.event.fix() is almost completely unnecessary if you don't care about IE8 and before.
c) Rather than just be like 'gently caress this, screw JQuery.event.fix()', the JQuery took the approach of having 'an event handler cache.' What this means is that when you create an event handler in JQuery, it will create the function in the JQuery namespace itself, and have another function point at that function in the JQuery namespace.

The consequences of this are:
a) If you call removeElement on an element that has an event handler in vanilla js, the event handler goes away. If you call removeElement on an element in JQuery, the original function and whatever is bound to it lives in the JQuery event handler cache forever - if you bound this to the function scope, well, your stuff is never going to garbage collect.
b) Moreover, JQuery fucks up all the memory profiling tools because this event handler cache bullshit makes it so instead of the leaked memory being in the namespace of the code that leaked, everything is leaked in the JQuery namespace instead. God help you if you use $.proxy, say goodbye to anything in that function ever releasing the memory again.
c) The JQuery pros will recommend that you use features like 'event delegation' and bullshit to speed up your JQuery, not realizing that vanilla js event handlers are fast, idiot proof, and don't leak - you don't have to use event delegation in vanilla js because just attaching the event handler to every element that would trigger the event would perform better!

Like, in 2006-2008 timeframe, I remember that people still used IE6 and IE7, so all this bullshit made sense. In 2018, all JQuery event handling does is make the setting 'break on every exception' super annoying because it throws exceptions in expected program flow.

Similarly, sizzle (the jquery selector engine) is worse than just doing querySelectorAll in anything later than IE9. God I remember spending like three weeks balls deep in that library because of some bullshit involving iframe and unload event handlers.

(I am actually a contributor to this library, but in my defense I was new when I had these problems.)

# ¿ Jun 20, 2018 05:03

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Thermopyle posted:

Everything about that is terrible and illogical and i wish i hadn't read it. Thanks!

Ok, well not everything. I do agree people should learn the basics. If you can't at least theoretically implement whatever framework you're using yourself, you're doing yourself a disservice.

Speaking as a former person who used frameworks and a JQuery, bootstrap and node.js contributor, I can see where this guy is coming from.

a) In 2012, this attitude was totally correct. In 2012, people were still using JQuery even though JQuery is worse than useless, and were really into monolithic frameworks that were slow, hard to debug, and sucked total rear end. I still remember people sucking the v8 engines dick even though all the performance measurements made the assumption that no one used a try catch anywhere in the call stack, I remember google closure, Kendo UI, and angular 1, all of which were hilariously terribly implemented and evidence that no one ever reads the source code of this poo poo before trying to make web sites. People would talk about unit testing and then write all sorts of crazy poo poo - like I remember a mocking framework that went on for pages about its unit tests, and it was all pages of, literally, "ninja.swing()" that asserted nothing. There was an endless progression of grunt/bower/etc - people would start using all these tools, the developer would get bored of fixing problems, and then the devs would jump to a new project.

b) 2017 has gotten a lot better - angular4 is actually a really smart web framework that has a lot of good features for writing maintainable SPA, including first class dependency injection support for components! .Net core is loving brilliant in that not only does it institutionalize first class dependency injection support, TestHost also always writing unit tests with a minimum of fuss. poo poo like babel and browserify actually work with a minimum of effort. Instead of SPA frameworks concentrating on solving the super difficult problem of "hey, you know, how do I update my view if my model changes, and vice versa", they provide useful features that you don't want to write yourself. Since JQuery is no longer a thing, you can actually loving use the "break on exceptions" feature in your browser's debugger without JQuery throwing exceptions in ordinary program flow whenever you move the mouse.

That said, my point would be more "think for yourself, don't be sheep." loving put breakpoints in the libraries you are including, step through them, and figure out how they work, and analyze for yourself why they have value! Don't just use libraries because some dude at a meetup tells you they're the next best thing.

# ¿ Jul 27, 2018 14:53

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Mr Shiny Pants posted:

I just read the linked page and I think I can understand his reasoning, Its the same argument as with an ORM I guess, all the extra work you need to do to get stuff from the DB when, if you had just learned SQL in the first place, stuff would be lot simpler and faster. SQL is still alive and kicking but NHibernate seems to have lost a lot of love since MS came out with EF.
Not saying it is 100% the same for webdevelopment though.

Reading the last of couple of posts, I am that guy learning stuff and undoubtedly doing stupid stuff with plain javascript and HTML right now.
Got to start somewhere I guess, otherwise its hard to see the forest for the trees with all the web stuff. Usually this works out though, you come across some repetitive coding work and figure out why you want a framework for some tasks instead of the other way around.

NHybernate and Entity Framework and all that stuff are great products. What unfortunately happened is that the underlying architecture of a product is generally dictated by the structure of the organization, so if you have, say a database team, it'll become it's own monolithic organization, and many organizations that made the horrible mistake of using, say, Oracle as their back-end database ended up with scores of Oracle dbas, programmers, and a generation of legacy databases. EF is great if you're doing a database from scratch and don't have a database team, much less if you have to adapt a ten year old database designed by people who don't understand 3NF and that there are other datatypes besides varchar - however most of the entity framework applications in the wild ended up being "make a lovely legacy application/database use EF" and EF got blamed for the original design being lovely, to say nothing about idiots who would find a slow query, and both rewrite it in standard SQL and somehow conclude it was writing the sql that hand that fixed the problem as opposed to, you know, having an index on the column that needed it.

# ¿ Jul 30, 2018 09:07

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

BlackMK4 posted:

After doing this long enough, I figured it was time to see if there was an easy way to improve my quality of life.

Is there a package or easy way to determine which Angular 6 component is injecting a given style tag (and included styles) within the head of a document? It seems like in a fairly complex Angular application you may easily end up with well over 20-30 style tags in the head of a page, and it can be difficult to track down where a given tag is coming from, especially if you have multiple libraries of components in use (like Angular Material) or if you're using SCSS mixins where the SCSS can differ considerably from what actually gets injected.

I just got bitten by a breaking style change in Material, and it took a little bit of time to figure out exactly what happened.

Perhaps there is a way to add a simple sourcemap comment at the top of the contents of a style tag?

I feel like you may be defeating the purpose of components by having your components inject styles into the head. One of the big sells of angular is that each component can have their own 'component styles' (https://angular.io/guide/component-styles) - the framework will ordinarily make it so the style applies to the component, instead of the whole document. Is there a specific reason why you're injecting the styles into the head element?

# ¿ Aug 11, 2018 21:06

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

BlackMK4 posted:

Where do you think those styles get put? They get injected into the head of the document in individual style elements with an Angular component id selector tacked on.

ok, so now the question becomes, if the styles are isolated, why do you care where they come from?

# ¿ Aug 12, 2018 06:13

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

BlackMK4 posted:

Because I am dealing with a project that has hundreds of components across multiple packages, some that use /deep/, and it can sometimes be irritating to figure out where certain applied styles come from when there is no good hint in the style tag associated with a given style on the element. This is mostly painful when doing a big upgrade, like I am now, from Angular 5 to Angular 6 (and RXJS/Material) where there are a ton of broken things.

The real issue happens when you have multiple internal packages that provide sets of modules.

ok, so if you really need to do this (and this is assuming you use the viewport.component stuff)

a) Every component on the page will get a 'ngcontent' style - e.g.

The original code in my viewport.css looks like:

code:

video {
    background: black;
    border: 2px solid gray;
}

)

When angular injects it, it adds a token to make it so the style can automatically be applied:

code:

<style>video[_ngcontent-c2] {
    background: black;
    border: 2px solid gray;
}</style>

That _ngcontent-c2 class is what is used to associate the style with the component. So from your style tag, take the '_ngcontent-c2' string, and search the dom using the debugger.

The result I get is:

code:

<app-viewport _nghost-c2="">
<div _ngcontent-c2="">
...
</div>
</app-viewport>

What this means is that the style tag I see in the head corresponds with the style tag for the component with selector "app-viewport" (as defined in viewport.component.ts)

For a one off scenario, this technique will work, but suck. If you want to speed this process up:

1. Go into all your *.component.css.
2. Add a fake attribute with the component name:
e.g.

code:

video {
    originator: "viewport.component.css";
    background: black;
    border: 2px solid gray;
}

(css comments get removed in this process so fake attribute is the way to go)

I'm not at the point where I feel comfortable debugging angular framework itself (playing with this was an eye-opener, I really need to download the angular source and getting it to the point where I can feel comfortable stepping it.)

# ¿ Aug 12, 2018 19:59

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Dominoes posted:

Typescript's not a bad lang, but the node ecosystem's messy, and can be frustrating if you don't know how to config it.

this is what initially drew me to angular/angularcli (https://github.com/angular/angular-cli/wiki), having working typescript and angular projects with karma for unit testing etc without having to screw around with config files.

# ¿ Aug 27, 2018 21:38

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Dominoes posted:

Your comment is hyperbole, but this is why I'm excited about WASM.

all the speed of javascript with the ease of use of C/C++.

# ¿ Sep 2, 2018 07:19

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ape Fist posted:

Can someone who has worked on Angular AND React give me reasons to like one or the other?

I'm doing a React Udemy course for my next role which tends to be a 'bit of everything' role just coming out of an Angular job for the last year and all I can say is that I feel that everything React does Angular does better and in a more organized fashion and literally every rebuttal to that argument is basically WeLl SoMeTiMeS i DoNt nEeD a RoUtInG LiBrArY sO tHeReFoRe rEaCt iS FaSteR aNd bEtTeR. I can definitely see booting up React to quickly throw it into a div on an existing website and use it to create some sort of cool widget and given that that's what Facebook initially intended it for its a real powerful tool for doing exactly that. But Angular is just this complete SPA solution that React doesn't seem to be and it feels like people 'force' React to be that when Angular is just top-down better suited for that purpose.

I could be entirely wrong here.

what happened was old angular was terrible, they introduced a new angular, everybody was like "gently caress this, let's go to react."

the problems I have with react are that
a) it empowers front end developers to make their own choices about libraries to include and how to structure the project
b) returning stuff that looks like HTML in a function is gross. i really like the angular separation of code from template

# ¿ Sep 2, 2018 15:55

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

my bony fealty posted:

Tbf I'm very glad I have to maintain AngularJS stuff and not the likely alternative, jQuery spaghetti piled high.

Seeing jQuery in AngularJS is weird and uncomfortable though. Was that a normal thing?

that was one of the biggest weaknesses of angularjs, angularjs was dependent on jquery (or to be more accurate, a subset of jquery called jqLite, although it would use the included jquery if it was available). if you're wondering why the angular is faster than angularjs, well, that's one of the reasons.

# ¿ Sep 4, 2018 18:01

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ape Fist posted:

You can do this with Angular as well?

Yeah it's angular's default behavior.

# ¿ Sep 6, 2018 20:52

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ape Fist posted:

Ugh no you're absolutely right.

One of the main reasons Angular sits behind React is because of the gigantic naming mistake. Because people see 'Angular' and assume they're talking about AngularJS and go ughhh I'm not touching that poo poo.

yeah.

angularjs was hilariously terrible and it was amazing it got as popular as it ever did - between angular and google closure there was a point where I couldn't take google seriously, and would just refuse to work at any company stupid enough to use angularjs.

angular was so different than angularjs that people mostly didn't port and just kept using angularjs, and would use react for new projects just because react was more mature at that time and since they'd have to learn a new framework anyway...

angular doesn't use 'virtual dom', it uses direct rendering with change detection (e.g. dom is only updated when model is actually changed.) in terms of rendering speed, angular is generally going to be on par or slightly faster than react (https://www.stefankrause.net/wp/?p=454), although react has an advantage in memory use and initial display performance (although if you care about initial display, use server side rendering!)

# ¿ Sep 7, 2018 14:43

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 20:16

Bruegels Fuckbooks: Sep 14, 2004; Now, listen - I know the two of you are very different from each other in a lot of ways, but you have to understand that as far as Grandpa's concerned, you're both pieces of shit! Yeah. I can prove it mathematically.

Ape Fist posted:

I just realized that react treats

this = (kind) => {
of function
}

differently than

this(kind) {
of function
}

specifically when it comes to scoping in-JSX function references.

If you use the first kind of syntax, you won't need do this.function = this.function.bind(this) in the constructor(), but if you use the second you will.

Anyone know why?

(and what the major consequences of using function = ( argument ) => { result } over function(argument) { result } are? I always thought they were relatively interchangeable)

it's nothing to do with react, arrow functions are an es6 feature.

the big benefit is avoiding all the var self=this in closures, e.g. in vanilla js

code:

var self = this;
var note = document.createElement('div');
note.addEventListener('mousedown', function(e) { return self.onMouseDown(e) }, false);
note.addEventListener('click', function() { return self.onNoteClick() }, false);

the value of 'this' in these functions... would be window. which is almost certainly not what you want, which is why you'd use the self = this.

code:

var note = document.createElement('div');
note.addEventListener('mousedown', (e) => this.onMouseDown(e) , false);
note.addEventListener('click', () => this.onNoteClick() }, false);

is much nicer.

Bruegels Fuckbooks fucked around with this message at 13:27 on Sep 8, 2018

# ¿ Sep 8, 2018 13:25

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

«‹›2 »