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 »

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

Lambdas, err, sorry arrow functions absolutely still have a this available - it's just a closure over the containing scope's this.

JavaScript code:

//try me in the console!
function fun() {
    return (() => console.log(this))();
}
fun();
//Window {...}

mfun = fun.bind(Math);
mfun();
//Math {...}

# ? Jul 3, 2019 14:09

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 03:48

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

How do you folks feel about long-running codebases that use a mix of styles/approaches to solving problems? For example, we have a React codebase that's about 18 months old, and it's probably 90-95% written by me. I like to stay current on things and I also just like trying things out so when Hooks came out I started using them, but I didn't go back and convert everything to Hooks. I also started the project using styled-components but after a while I found it didn't scale all that well and started peppering in some utility classes to avoid having to come up with new variable names every time I wanted a div to be display: flex. There are also some small stylistic things like some function components being declared as "function MyComponent" and others being declared as "const MyComponent = () => {}"

I used to work at a semi-dysfunctional agency so I was just starting new projects all the time and didn't really need to worry about long-running projects, but I want this app to stay in prod for as long as possible, so I don't want to be stuck doing what was popular/available in early 2018. We're looking at hiring another FE developer soon and I'm wondering if this is the kind of stuff that would drive you nuts if you were joining a team or if it's just kind of expected on larger/longer running apps and not really a big deal?

# ? Jul 3, 2019 14:42

Harriet Carker: Jun 2, 2009

I think introducing new tech/patterns in new code is fine and doesn�t require updating all the old stuff. However, if you end up working on the old stuff (refactoring, bug fixes, whatever) that can be a good time to redo that portion. Just keep in mind that it will require extra documentation for new devs about best practices.

# ? Jul 3, 2019 15:26

minato: Jun 7, 2004; cutty cain't hang, say 7-up.; Taco Defender

I find it's useful to at least comment that some old code is considered out of date. That helps avoid spreading bad practices when people inevitably copy/paste code from elsewhere in the codebase.

# ? Jul 3, 2019 16:29

Doom Mathematic: Sep 2, 2008

dupersaurus posted:

What�s the diff between arrow and expression?

I wrote a bunch of stuff here but it's been explained in greater detail and with better examples elsewhere. Here are the two sections of this longer document which you should find useful:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Functions#Defining_functions
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Functions#Arrow_functions

prom candy posted:

I use statements because it's easier to do

export default function Whatever() {}

than

const Whatever = () => {}

export default Whatever

You can do export default () => {} if you want, but admittedly the resulting function is anonymous.

# ? Jul 3, 2019 19:20

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

I just think the Lambdas look prettier :downs:

# ? Jul 3, 2019 20:18

Vincent Valentine: Feb 28, 2006; Murdertime

prom candy posted:

How do you folks feel about long-running codebases that use a mix of styles/approaches to solving problems? For example, we have a React codebase that's about 18 months old, and it's probably 90-95% written by me. I like to stay current on things and I also just like trying things out so when Hooks came out I started using them, but I didn't go back and convert everything to Hooks. I also started the project using styled-components but after a while I found it didn't scale all that well and started peppering in some utility classes to avoid having to come up with new variable names every time I wanted a div to be display: flex. There are also some small stylistic things like some function components being declared as "function MyComponent" and others being declared as "const MyComponent = () => {}"

I used to work at a semi-dysfunctional agency so I was just starting new projects all the time and didn't really need to worry about long-running projects, but I want this app to stay in prod for as long as possible, so I don't want to be stuck doing what was popular/available in early 2018. We're looking at hiring another FE developer soon and I'm wondering if this is the kind of stuff that would drive you nuts if you were joining a team or if it's just kind of expected on larger/longer running apps and not really a big deal?

Every single lead dev on the flagship product at my company has wanted to do things with whatever is newest or best. As a result, the UI is a proprietary 3rd party framework, an in house developed component based framework based off jQuery 1.4, Angularjs, react and Vue.

It's a total disaster and infuriating to work with. But at it's core, almost all of those were the right call. This 3rd party framework was garbage and it needed to go. The component based jQuery was a good idea, but it just didn't work(this was long before Angularjs would take it's debut, so it was ahead of it's time). Angularjs isn't really supported anymore and it needs to go. React was a great replacement for Angularjs. Vue was a waste of time, even though Vue is very good, because there was no need to replace react. For the record, all this occurred over something like 8 years.

I think the idea of not going back and fixing older code is fine for awhile. I think since that code works, it's perfectly reasonable to leave it alone. However, it should be obvious that you're creating a ton of technical debt by doing that, and continuously kicking the can doesn't help.

My two suggestions for that:

If you need to make an improvement to a feature that is no longer in line with the best practices and frameworks you use in the newer parts of the application, alot extra time to that ticket to allow it to be brought up to par. This will probably take considerable time in a lot of cases to make these upgrades, but it's time you need to take to save yourself more time in the long run.

The other is to dedicate Q4 to paying off debt. It's a great time because you don't really have as much to do due to every dev taking off time for all the different holidays, as well as clients doing the same thing. You can dedicate actual, real time to paying off that debt.

I realize my situation is not the same as yours. There's a big difference between using a new framework, and incorporating hooks. But as you said, your app is only 18 months old and you're already running into this debt of the newer parts of your app being different than existing parts so you've taken that first step in the same road.

Consistentency is hugely important in development. It supports best practices and prevents bugs. It makes code reviews easier and makes your app more stable. It's just a matter of knowing when to make your old code consistent and when to just leave it alone.

# ? Jul 3, 2019 20:49

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

If you have coding style things you would like to be standard practices I would recommend putting as many of those rules as possible into a linter like eslint and make sure all devs get their editor set up to auto fix or at least highlight where the linter fails. Auto fix will take a lot of the small annoyances out of code review as well.

# ? Jul 3, 2019 20:59

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

Doom Mathematic posted:

You can do export default () => {} if you want, but admittedly the resulting function is anonymous.

Yeah I used to do this until I realized that React Dev Tools is then filled with a bunch of <Unknown>s and it's hard to debug

# ? Jul 4, 2019 14:04

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

Vincent Valentine posted:

Every single lead dev on the flagship product at my company has wanted to do things with whatever is newest or best. As a result, the UI is a proprietary 3rd party framework, an in house developed component based framework based off jQuery 1.4, Angularjs, react and Vue.

It's a total disaster and infuriating to work with. But at it's core, almost all of those were the right call. This 3rd party framework was garbage and it needed to go. The component based jQuery was a good idea, but it just didn't work(this was long before Angularjs would take it's debut, so it was ahead of it's time). Angularjs isn't really supported anymore and it needs to go. React was a great replacement for Angularjs. Vue was a waste of time, even though Vue is very good, because there was no need to replace react. For the record, all this occurred over something like 8 years.

I think the idea of not going back and fixing older code is fine for awhile. I think since that code works, it's perfectly reasonable to leave it alone. However, it should be obvious that you're creating a ton of technical debt by doing that, and continuously kicking the can doesn't help.

My two suggestions for that:

If you need to make an improvement to a feature that is no longer in line with the best practices and frameworks you use in the newer parts of the application, alot extra time to that ticket to allow it to be brought up to par. This will probably take considerable time in a lot of cases to make these upgrades, but it's time you need to take to save yourself more time in the long run.

The other is to dedicate Q4 to paying off debt. It's a great time because you don't really have as much to do due to every dev taking off time for all the different holidays, as well as clients doing the same thing. You can dedicate actual, real time to paying off that debt.

I realize my situation is not the same as yours. There's a big difference between using a new framework, and incorporating hooks. But as you said, your app is only 18 months old and you're already running into this debt of the newer parts of your app being different than existing parts so you've taken that first step in the same road.

Consistentency is hugely important in development. It supports best practices and prevents bugs. It makes code reviews easier and makes your app more stable. It's just a matter of knowing when to make your old code consistent and when to just leave it alone.

Thanks for this feedback (and everyone else who gave feedback as well!) I would love to dedicate Q4 to tech debt but we're in a highly competitive space right now with a small, scrappy team (we only have two developers) so I don't think there's any way not working on new features for 3 months would fly. Maybe I can pitch tech debt Fridays or something so that we can dedicate more time to taking care of debt, improving test coverage, etc.

Anyway I feel better that I'm not stacking multiple separate frameworks on top of each other at least. V1 of our app (before I came along) was AngularJS and they decided to just do a complete teardown and rewrite in React.

Speaking of stacking separate frameworks etc. what's up with micro front ends? It seems incredibly stupid to me which means I'm probably going to think it's the greatest thing ever in 6 months.

# ? Jul 4, 2019 17:31

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

Anybody here that uses TypeScript and Material-UI know how MUI pulled this off?

Specifically, how does TypeScript just infer the key names from useStyles()? How does it know that useStyles() returns a Record<'header' | 'root | 'link', string>? It's amazing I want to learn how to properly create inferences without having to actually type out my variables.

e: ah nvm I think I got it

teen phone cutie fucked around with this message at 17:32 on Jul 5, 2019

# ? Jul 5, 2019 17:19

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

I sat down to take a serious look at Vue today and I sort of get why people are hollering about it.

# ? Jul 5, 2019 17:28

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

Ape Fist posted:

I sat down to take a serious look at Vue today and I sort of get why people are hollering about it.

We switched to it at work about a year ago, and I still have pretty much nothing but good things to say about it.

# ? Jul 5, 2019 19:04

Spime Wrangler: Feb 23, 2003; Because we can.

I've been using vue for about a year now and it's been great.

Do any of you use vue with typescript? I brought it in for our latest project and it seems like using it with vue-class-components/vue-property-decorators/vue-module-decorators (for vuex) is the most robust setup right now but class syntax is losing first-party support in v3. I'd rather not have a huge pile of tech debt to unfuck six months from now, but there's not a lot of good documentation on other best practices from what I can find.

# ? Jul 5, 2019 19:47

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

Spime Wrangler posted:

I've been using vue for about a year now and it's been great.

Do any of you use vue with typescript? I brought it in for our latest project and it seems like using it with vue-class-components/vue-property-decorators/vue-module-decorators (for vuex) is the most robust setup right now but class syntax is losing first-party support in v3. I'd rather not have a huge pile of tech debt to unfuck six months from now, but there's not a lot of good documentation on other best practices from what I can find.

We are using typescript and vue-property-decorator.

Wasn't aware of that change coming in v3 - got a link where I can read up on it?

# ? Jul 5, 2019 19:49

Spime Wrangler: Feb 23, 2003; Because we can.

It's mentioned in an update to the preview blog post: https://medium.com/the-vue-point/plans-for-the-next-iteration-of-vue-js-777ffea6fabf

The new api RFC is here: https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md

# ? Jul 5, 2019 20:15

reversefungi: Nov 27, 2003; Master of the high hat!

Another React Question: I'm trying to refactor some code to use React Hooks + functional components instead of classes. Within the docs, if we have a function like, say, handleClick(), the docs usually show an inner function being created, something like this:

JavaScript code:

function Thingy(props){
  const [counter, setCounter] = useState(0);
  function handleClick() {
    setCounter(counter + 1)
  }
 return (
    <button onClick={handleClick} />
  )
}

This makes sense for stateful things, since you need access to both the counter and setCounter variables being declared at the top of the function. However, what if you're trying to move other parts of logic into separate functions, like say some complex calculation that requires using various props and other variables being declared/parsed before hitting the return block with JSX? Is it sensible to put these inside the Thingy function as well, or do you move them to the module scope? It seems like with the former, there's the potential danger of running into weird variable declaration/hoisting issues or very easily accidentally trying to use a variable inside a function before it's declared somewhere farther down, and potentially making things look a little messy. I'm envisioning a scenario that might look like this:

JavaScript code:

function Thingy(props){
  const [counter, setCounter] = useState(0);

  function handleClick() {
    setCounter(counter + 1)
  }
  
  function doStuffWithBlorp() {
     // do stuff with blorp
     // maybe pass blorp in directly?
  }
  const blorp = props.foo ? props.bar : props.bazz


 return (
    <button onClick={handleClick}> {blorp} </button>
  )
}

Would I have to move blorp to the top of Thingy()? Or does JavaScript's way of handling variables intelligently grab the right values even if they are being declared afterwards? Alternatively but similar question, if I tried to use setCounter inside of handleClick before declaring it, would it still go work normally at the end of the day due to the execution context? Admittedly this is where my knowledge of JavaScript gets fuzzy, and I'm perhaps over complicating things here, but I'm also trying to think of the best way to organize these purely functional components.

# ? Jul 5, 2019 21:51

tankadillo: Aug 15, 2006

You can reference a variable inside a function before the variable has been declared as long as it's declared before the function is executed, IIRC. JavaScript does a weird "hoisting" thing behind the scenes where functions are actually moved to the very top of their scope when the code is compiled. That being said, I always try to have my variables declared at the top of each component because I find it more readable and easier to debug. I think the code you posted should work fine.

For any functions that rely on props or state, I typically keep them inside the scope of that component function, not at the module level. Unless you're reusing the same logic across components, then moving them outside the component usually makes things more complicated. Apparently some people are concerned that declaring functions inside functional components has a performance impact because the functions are being re-declared for every render, but my understanding is that declaring functions has a negligible performance cost in browsers anyway so it's not really an issue.

# ? Jul 5, 2019 23:18

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.

tankadillo posted:

You can reference a variable inside a function before the variable has been declared as long as it's declared before the function is executed, IIRC. JavaScript does a weird "hoisting" thing behind the scenes where functions are actually moved to the very top of their scope when the code is compiled. That being said, I always try to have my variables declared at the top of each component because I find it more readable and easier to debug. I think the code you posted should work fine.

hoisting is a very special case thing. initialization to a value is not hoisted.

code:

x = 5;
var x;

// works, var is hoisted.

code:

console.log(x);
var x = 5;

// doesn't work, initialization is not hoisted;

code:

helloWorld();  // TypeError: helloWorld is not a function
var helloWorld = function(){
  console.log('Hello World!');
}

// does not work, assignment in initialization is not hoisted

# ? Jul 6, 2019 00:53

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

Is there a tool/framework that�ll let you give it a set of data and it�ll build a API for you without (much) code? Like Wordpress but instead of making web pages you�re making an API?

# ? Jul 6, 2019 01:59

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

dupersaurus posted:

Is there a tool/framework that�ll let you give it a set of data and it�ll build a API for you without (much) code? Like Wordpress but instead of making web pages you�re making an API?

Swagger comes to mind.

# ? Jul 6, 2019 02:32

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

Chenghiz posted:

Swagger comes to mind.

Doesn�t swagger just document an API you�ve already written?

Edit: to be clear, I�m talking about something like you give it a csv or xml and it�ll spin up a database and express, and give you a control panel to make endpoints.

dupersaurus fucked around with this message at 02:38 on Jul 6, 2019

# ? Jul 6, 2019 02:34

Chenghiz: Feb 14, 2007; WHITE WHALE
HOLY GRAIL

You can generate code from a swagger definition: https://swagger.io/tools/swagger-codegen/

That doesn�t cover the database though. I don�t know of any more complete solutions and honestly it seems like the kind of one size fits all solution that would never really fit well.

# ? Jul 6, 2019 15:54

Flat Daddy: Dec 3, 2014; by Nyc_Tattoo

There�s something called Datasette that sounds like that https://simonwillison.net/2017/Nov/13/datasette/

# ? Jul 6, 2019 16:02

RC Cola: Aug 1, 2011; Dovie'andi se tovya sagain

Should I focus on React or Vue? I know the basics of each, but want to start diving deep into learning one or the other.

# ? Jul 6, 2019 16:12

dupersaurus: Aug 1, 2012; Futurism was an art movement where dudes were all 'CARS ARE COOL AND THE PAST IS FOR CHUMPS. LET'S DRAW SOME CARS.'

Chenghiz posted:

You can generate code from a swagger definition: https://swagger.io/tools/swagger-codegen/

That doesn�t cover the database though. I don�t know of any more complete solutions and honestly it seems like the kind of one size fits all solution that would never really fit well.

Oh cool that�s neat

Flat Daddy posted:

There�s something called Datasette that sounds like that https://simonwillison.net/2017/Nov/13/datasette/

That�s really neat, that might be enough.

Half-solutions are cool. My non-coding sister has a dataset and she�d like to make an API from it, and while I think she�d like to learn some coding I don�t know how deep into the weeds of she wants to go so I�m scoping out stuff that might ease the burden

dupersaurus fucked around with this message at 16:40 on Jul 6, 2019

# ? Jul 6, 2019 16:17

Doom Mathematic: Sep 2, 2008

Flat Daddy posted:

There�s something called Datasette that sounds like that https://simonwillison.net/2017/Nov/13/datasette/

Did someone mention "Datassette sounds"?

# ? Jul 6, 2019 16:39

biceps crimes: Apr 12, 2008

RC Cola posted:

Should I focus on React or Vue? I know the basics of each, but want to start diving deep into learning one or the other.

They're both cool technologies, but React has greater market share. Otherwise I don't think you can go wrong with either.

# ? Jul 6, 2019 18:53

gbut: Mar 28, 2008; 😤I put the UN🇺🇳 in 🎊FUN🎉

Yeah, pick one that looks easier to you, and you'll be able to transfer vast majority of that knowledge to the other one later on. They are not that different.

# ? Jul 6, 2019 19:38

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

My perspective as primarily an Angular Developer and having touched neither React nor Vue in a professional capacity is that Vue seems a lot more, I dunno, interesting? It may be because React's Component-based language is familiar to me as an Angular developer but that I'm not as wild about JSX as I am about Angular's templating language, which a lot of people despise but I like. Vue takes a lot of its templating language from Angular I think. The <template> <script> <style scoped> thing in a Vue 'component' takes a minute or two to get used too if you're coming from an Angular OR React background but its actually nice. Finally Vue does a shitload of things 'Under the hood' which things like Angular like to be really loving verbose about. Looks like if you just declare a property in the data() method of a Vue component and then declare the same property as a function in the watch() method then you pretty much immediately subscribe to that property in the data() method which is insanely convenient shorthand for what Angular would require you to set up as an RXJS observable and its mind-blowing. Child-parent communication in Vue is a piece of piss as well and its super easy.

I think above all else Vue doesn't necessarily 'show up' React as much, but it shows Angular up by doing most of what Angular's often-used features and methods do but way easier and more conveniently.

But as everyone says, React has the absolutely dominant market share right now and it's going to net you a job faster than learning either Angular, React, or Vue. But you could also say that React is arguably the less 'personally profitable' FED Library out there right now because React devs are more common and Angular is a major preferential candidate for internal-facing systems applications in large companies. Finance, medical, government, etc, all use Angular preferentially because its robustness is viewed as being more, I dunno, secure or some poo poo, if you consider it from that perspective Angular & React aren't actually necessarily targeting the same market but I'd still view Vue as more of a competitor to React than Angular at this moment in time.

# ? Jul 6, 2019 20:56

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

I feel like Vue is more like Angular, in that it does more than just a view layer, and it's templating is similar, but it keeps the "custom tags / logic in templates" thing that I personally dislike, but I understand that's a personal preference. React is a just a view layer, and it does templates either via JSX (which to me is perfect) or via "pure" JS, but keeps framework logic out of them. Conceptually, React makes a ton more sense to me, but I know it also introduces some other issues (you have to make decisions on non-view things, for example). At the end of the day, I think Vue and React are cool and good, and that Angular is not as well thought out as is should be to a be a "everything and the kitchen sink" framework. I still think React is the way to go though.

# ? Jul 6, 2019 23:05

Vincent Valentine: Feb 28, 2006; Murdertime

Vue is probably the better framework technically.

React is the better framework to actually use.

Almost any error you've had with react, someone else has written an essay to explain. Any concept or problem you try to engineer a solution for, someone has a five hour tutorial on explaining it.

The react devs are active in the community, and the people developing supporting tools are there to answer questions with their tools.

This is also kind of a self fulfilling prophecy. As more people use react because of its great support system and tool ecosystem, both of those become more true.

You can't really go wrong with either one, but I feel like react makes things better where it counts: when poo poo isn't going well.

I use Angularjs 1.5 at work, btw. It doesn't really matter what you learn, there's a job out there for it.

# ? Jul 7, 2019 00:48

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

Lumpy posted:

Angular is not as well thought out as is should be to a be a "everything and the kitchen sink" framework.

I'd just say that angular is hugely over engineered and exposes too much of what should probably just be under the hood and IS under the hood in Vue. But I think the original idea may have been something along the lines of "Let's build ASP.NET but on the front end."

# ? Jul 7, 2019 06:45

Ape Fist: Feb 23, 2007; Nowadays, you can do anything that you want; anal, oral, fisting, but you need to be wearing gloves, condoms, protection.

Spent a few more hours playing with Vue this afternoon. Honestly it feels like Evan You walked out of the Google buildings in 2014 with the prototypes of Angular 2 in a brief case going 'I can do thing better than you idiots, I'm not staying here.' and honestly he might have pulled it off.

# ? Jul 7, 2019 14:54

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

I've played with Vue a bit and it didn't do anything for me, I don't like the tag template stuff. I can see why people love it though. I can especially see why it's popular with people who aren't all that jazzed about JavaScript as a language, like back-end engineers who find themselves needing to do a front-end (not that people who are jazzed about JavaScript can't like it too)

# ? Jul 7, 2019 22:28

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Vue is closer to the metal than React and is therefore superior for that alone. Mutable state using vuex as opposed to redux is absolutely fantastic. Both tools work but I wouldn't use React for a personal project. Learning both if you're already learning one is easy, I don't really buy this idea that React is big because it's already big.

# ? Jul 8, 2019 02:15

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Big isn't always necessarily a good thing, PHP is big.

# ? Jul 8, 2019 02:17

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

Nolgthorn posted:

Vue is closer to the metal than React and is therefore superior for that alone.

This is the wrongest thing thats ever been said.

assembler is "closer to the metal" than every other language, I guess its the best.

# ? Jul 8, 2019 02:23

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

I'm going to start writing all my frontend code in raw webassembly.

# ? Jul 8, 2019 02:24

Adbot: ADBOT LOVES YOU

# ? May 23, 2024 03:48

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

React is actually a framework, and Vue is its competing framework. Your sarcastic comment is actually not helpful, and my comment is its competition.

# ? Jul 8, 2019 02:28

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

«‹›235 »