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 »

Dominoes: Sep 20, 2007

Hey dudes: Reworking routing on a framework I'm working on. Found a shortcut where I set up an API where were the user builds a `routes` function that accepts a Url struct (wraps a list of path segments, eg what's between slashes, and some extras like hash and search), and outputs a message describing how to update state. Then the user can give any element a `href` attribute with value of a relative path, and clicking it will route based on the `routes` fn. (Or can be called from update logic using the lib's `push_route` fn, which can trigger from things other than clicking elements)

Is there a downside to this API design? I haven't built a website in a while, but when I last attempted with React Router, it was more complicated.

Ex:

Rust code:

fn routes(url: &Url) -> Msg {
    if url.path.is_empty() {
        return Msg::ChangePage(Home)
    }

    match url.path[0].as_ref() {
        "guide" => {
            // Determine if we're at the main guide page, or a subpage
            match url.path.get(1).as_ref() {
                Some(page) => Msg::ChangeGuidePage(page),
                None => Msg::ChangePage(Guide)
            }
        },
        "changelog" => Msg::ChangePage(ChangeLog),
        _ => Msg::ChangePage(Home),
    }
}

// ...

// Anywhere in program
a!["Guide", attrs!{At::Href => "/guide"} ],
button!["Changelog", attrs!{At::Href => "/changelog"} ]

The implementation was straightfwd: Listen for popstate, and clicks on elements that have an Href, wrap and pass href's val to the user's `routes` fun, then update state from its result. Wrote this in Rust, but a JS implementation would be similar, minus the pattern-matching.

edit: Included this in latest release.

Dominoes fucked around with this message at 16:37 on Mar 3, 2019

# ? Mar 1, 2019 19:45

Adbot: ADBOT LOVES YOU

# ? Jun 2, 2024 14:30

Pollyanna: Mar 5, 2005; Milk's on them.

We�ve got a lovely Rails monolith with a lovely home-grown tabulation/pagination JS library owned and maintained by someone who no longer works with the company. We need to rip it out and replace it with something that can provide tabulation and pagination of models/datasets with an arbitrary set of columns and column headers. There�s tens of thousands of these rows so we need pagination. We�d have to integrate with a typical Rails monolith setup where right now we�re doing the old �//require jquery� stuff in application.js or whatever.

What�s a good, well-established table/pagination library that allows for server-side querying and pagination? I�ve found DataTables and Tabulator, but I�m not sure which to go with. It also can�t require us to change code in order to add or remove table columns, since we�re rendering arbitrary bags of JSON (hstore technically) that can have some dynamic list of columns/keys. It should be dynamic in that way.

Pollyanna fucked around with this message at 17:25 on Mar 5, 2019

# ? Mar 5, 2019 17:22

Paranda: Jun 9, 2003

Looking for a quick sanity gut check here. So I've got an page that takes in a set of user supplied data, and then does a ton of layout computations on it (offsetWidth, etc.) to render various things. It's slow as balls on IE11 (10-20s render) but magically renders in browsers like Chrome and Firefox in under a second. As far as getting it to run better on IE, I've tried everything from removing CSS, optimizing code, reducing layout thrash & batchin, etc and devoted tons of hours in the lovely IE debugger looking at the render graphs, but at this point I'm about convinced that the current render speed is about as fast as I can realistically get in IE without me exiting this world in an early death.

I'm just about to throw in the towel, but my last ditch solution is to detect if a user is using IE, and if they try to load this awful page, I'm going to shoot all that user data to headless chrome instance that generates all the markup and then returns the final form back to the user, because even with the round trip to the server, popping up a loading screen for a few seconds and then showing the content is still way faster and less painful than the lovely experience they get today. This is basically SSR just purely to shortcut performance problems by using Blink engine instead of IE.

Does this sound totally insane to anyone else? My gut is this seems like a lovely idea, but OTOH maybe I shouldn't be afraid of using SSR to solve client performance issues?

# ? Mar 5, 2019 19:34

Honest Thief: Jan 11, 2009

I really should have put my foot down when product came asking for more animations on a already kinda slow react app. Now who has two thumbs and to magically solve a scalability problem? This guy, who is screwed.

Paranda posted:

Looking for a quick sanity gut check here. So I've got an page that takes in a set of user supplied data, and then does a ton of layout computations on it (offsetWidth, etc.) to render various things. It's slow as balls on IE11 (10-20s render) but magically renders in browsers like Chrome and Firefox in under a second. As far as getting it to run better on IE, I've tried everything from removing CSS, optimizing code, reducing layout thrash & batchin, etc and devoted tons of hours in the lovely IE debugger looking at the render graphs, but at this point I'm about convinced that the current render speed is about as fast as I can realistically get in IE without me exiting this world in an early death.

I'm just about to throw in the towel, but my last ditch solution is to detect if a user is using IE, and if they try to load this awful page, I'm going to shoot all that user data to headless chrome instance that generates all the markup and then returns the final form back to the user, because even with the round trip to the server, popping up a loading screen for a few seconds and then showing the content is still way faster and less painful than the lovely experience they get today. This is basically SSR just purely to shortcut performance problems by using Blink engine instead of IE.

Does this sound totally insane to anyone else? My gut is this seems like a lovely idea, but OTOH maybe I shouldn't be afraid of using SSR to solve client performance issues?

What sort of layout computations you're doing? Stuff like offsetWidth will trigger layout updates, and if you're not using some frontend framework to batch those updates it could be really impacting your performance. Are they based on any user input, or something you could reliably do on SSR? Cause there's nothing necessarily wrong with using SSR.

Honest Thief fucked around with this message at 13:09 on Mar 6, 2019

# ? Mar 6, 2019 13:06

IAmKale: Jun 7, 2007; やらないか; Fun Shoe

Pollyanna posted:

We�ve got a lovely Rails monolith with a lovely home-grown tabulation/pagination JS library owned and maintained by someone who no longer works with the company. We need to rip it out and replace it with something that can provide tabulation and pagination of models/datasets with an arbitrary set of columns and column headers. There�s tens of thousands of these rows so we need pagination. We�d have to integrate with a typical Rails monolith setup where right now we�re doing the old �//require jquery� stuff in application.js or whatever.

What�s a good, well-established table/pagination library that allows for server-side querying and pagination? I�ve found DataTables and Tabulator, but I�m not sure which to go with. It also can�t require us to change code in order to add or remove table columns, since we�re rendering arbitrary bags of JSON (hstore technically) that can have some dynamic list of columns/keys. It should be dynamic in that way.

I�ve been using React Table at work with server side pagination and it�s worked really well. There�s a prop you can set specifically to disable its handling of paginations, and a decent API for its onFetchData prop to help with making queries every time you click Next/Back or change the number of visible rows, etc... you can also specify arbitrary numbers of columns with a simple array of objects you can generate with a .map() or whatever.

The docs are a little rough but there are plenty of sandboxed examples. All in all I think it�s worth a look given your constraints.

# ? Mar 6, 2019 16:23

Vincent Valentine: Feb 28, 2006; Murdertime

Honest Thief posted:

I really should have put my foot down when product came asking for more animations on a already kinda slow react app. Now who has two thumbs and to magically solve a scalability problem? This guy, who is screwed.

Genuinely sorry man, that sucks. It might be worth it to say that removing as much of, or all, of the animations is the way to go.

I truly loathe animations, both as a user and a developer. I managed to compromise with my product team on using them by saying that the better someone is at using the product, the worse animations become. I showed them my phone, and if you pushed the button to bring up all the tabs of everything you have open, the "close all" button being a thing that slides in meant that once you got good at the phone, you would tap where the button was before it was actually there. The compromise was to show them once on sign up to help new users find their way around, then stop them after. It turned out to work really well, if that helps your case any.

# ? Mar 6, 2019 21:02

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Honest Thief posted:

I really should have put my foot down when product came asking for more animations on a already kinda slow react app. Now who has two thumbs and to magically solve a scalability problem? This guy, who is screwed.

What sort of layout computations you're doing? Stuff like offsetWidth will trigger layout updates, and if you're not using some frontend framework to batch those updates it could be really impacting your performance. Are they based on any user input, or something you could reliably do on SSR? Cause there's nothing necessarily wrong with using SSR.

You could say having animations is an accessibility issue?

# ? Mar 6, 2019 22:19

Splinter: Jul 4, 2003; Cowabunga!

I'm looking at learning either Vue or React to get some familiarity with a modern JS front end framework. From what I gather, Vue has less of a learning curve, but React is more popular (especially on the job front). What else should I take into consideration when choosing? Leaning toward React due to the popularity at this point.

# ? Mar 7, 2019 03:13

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

Haven't used React, and I use Vue daily at work. It was super easy to learn. I think a lot of concepts transfer to React, but there's more explicit stuff and less convention/magic thank with Vue. Neither will be a mistake.

# ? Mar 7, 2019 03:20

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

Learn both!

I prefer React, as 95% of what you write is just JS, so you don�t spend much time learning framework specific stuff. But both are easy enough to pick up you should give both a whirl.

Lumpy fucked around with this message at 04:01 on Mar 7, 2019

# ? Mar 7, 2019 03:59

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

Yup, this. Most of modern front end is just ES6/7 stuff and APIs that is transferable knowledge as both frameworks have the same underlying principles. As there will be a new shiny framework any day now, no need to tie yourself to a specific one. Solid knowledge of the core language will allow you to easily hop between the flavors of the day.

# ? Mar 7, 2019 04:59

Dominoes: Sep 20, 2007

Check out Elm too. If I'd known about it before, I'd probably have made my prev projects with it instead of React. I can't comment on Vue, but React has a nice declarative style, with some syntax warts.

The TodoMVC project's a good place to compare frameworks, with the caveat that some are different styles to program in each framework, and this may obfuscate the framework differences.

Dominoes fucked around with this message at 10:39 on Mar 7, 2019

# ? Mar 7, 2019 10:33

Honest Thief: Jan 11, 2009

Vincent Valentine posted:

Genuinely sorry man, that sucks. It might be worth it to say that removing as much of, or all, of the animations is the way to go.

I truly loathe animations, both as a user and a developer. I managed to compromise with my product team on using them by saying that the better someone is at using the product, the worse animations become. I showed them my phone, and if you pushed the button to bring up all the tabs of everything you have open, the "close all" button being a thing that slides in meant that once you got good at the phone, you would tap where the button was before it was actually there. The compromise was to show them once on sign up to help new users find their way around, then stop them after. It turned out to work really well, if that helps your case any.

The Merkinman posted:

You could say having animations is an accessibility issue?

I like the challenge inherent to them but it's the typical feature creep scenario where suddenly you get to have to account for all those transitions that don't animate, like the height of a div container in a list. I think I can defer the issue with them wanting pagination now, but that's a whole 'nother can of worms.

Dominoes posted:

Check out Elm too. If I'd known about it before, I'd probably have made my prev projects with it instead of React. I can't comment on Vue, but React has a nice declarative style, with some syntax warts.

The TodoMVC project's a good place to compare frameworks, with the caveat that some are different styles to program in each framework, and this may obfuscate the framework differences.

I really liked Elm when one of the creators gave a workshop in a conf in Europe, but I'm leaning more towards Reason these days due to a tighter community.

Honest Thief fucked around with this message at 12:30 on Mar 7, 2019

# ? Mar 7, 2019 12:23

Dominoes: Sep 20, 2007

Honest Thief posted:

I really liked Elm when one of the creators gave a workshop in a conf in Europe, but I'm leaning more towards Reason these days due to a tighter community.

I need to try Reason. The routing syntax I posted above is stolen from it, minus the adding href to arbitrary elements.

# ? Mar 7, 2019 13:36

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

Dominoes posted:

Check out Elm too. If I'd known about it before, I'd probably have made my prev projects with it instead of React. I can't comment on Vue, but React has a nice declarative style, with some syntax warts.

The TodoMVC project's a good place to compare frameworks, with the caveat that some are different styles to program in each framework, and this may obfuscate the framework differences.

I love most of Elm. Like, really, really love it. Is JSON handling any less painful since 0.17?

I need to check out Reason as well... I have something to do today!

# ? Mar 7, 2019 14:39

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

gbut posted:

Yup, this. Most of modern front end is just ES6/7 stuff and APIs that is transferable knowledge as both frameworks have the same underlying principles. As there will be a new shiny framework any day now, no need to tie yourself to a specific one. Solid knowledge of the core language will allow you to easily hop between the flavors of the day.

Well, yes and no. In Vue (and if I remember correctly, Angular) you have stuff like so:

code:

<div id="app-3">
  <span v-if="seen">Now you see me</span>
  <ol>
    <li v-for="todo in todos">
      {{ todo.text }}
    </li>
  </ol>
</div>

The whole v-[whatever] syntax is the "framework stuff" you have to learn that you throw away if you switch. Where React would do something like:

code:

<div id="app-3">
  { seen && <span>Now you see me</span> }
  <ol>
    { todos.map( todo => <li>{ todo.text }</li> ) }
  </ol>
</div>

which is more "just JS" (ignoring the whole JSX thing :v:

) I use JS's map for the LIs, not some framework-specific thing. Obviously it's not such a huge hassle or a recommendation *not* to use Vue, just illustrating a bit for Splitner.

# ? Mar 7, 2019 14:49

Paranda: Jun 9, 2003

Honest Thief posted:

I really should have put my foot down when product came asking for more animations on a already kinda slow react app. Now who has two thumbs and to magically solve a scalability problem? This guy, who is screwed.

What sort of layout computations you're doing? Stuff like offsetWidth will trigger layout updates, and if you're not using some frontend framework to batch those updates it could be really impacting your performance. Are they based on any user input, or something you could reliably do on SSR? Cause there's nothing necessarily wrong with using SSR.

Yeah I can tell in the performance graph I am getting killed by a billion synchronous calls to getBBox for text measurement among other things. It was even worse before but I overwrote some of that stuff to use canvas to measureText. Problems now are all in vendor charting libraries beyond my direct control and I don't wanna get into forking third party libs to rewrite for my extremely specific use case. There's no user input and thankfully no animations so it does translate to SSR well though, so I guess I am probably gonna push my boss down this route.

# ? Mar 7, 2019 15:24

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

Paranda posted:

Yeah I can tell in the performance graph I am getting killed by a billion synchronous calls to getBBox for text measurement among other things. It was even worse before but I overwrote some of that stuff to use canvas to measureText. Problems now are all in vendor charting libraries beyond my direct control and I don't wanna get into forking third party libs to rewrite for my extremely specific use case. There's no user input and thankfully no animations so it does translate to SSR well though, so I guess I am probably gonna push my boss down this route.

I'm guessing that many charts don't all fit on the screen at once, so consider lazy-loading them when the user scrolls them into view?

# ? Mar 7, 2019 17:09

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

Could someone please link me to a demo or something about multiple panel components in Vue? I'm trying to make one (well it's more of a thing stuck to the bottom) All the circular dependencies with making something outside the component make it visible, but the button inside the app toggling the same boolean is very confusing. Also everything I look up is like here is a demo that only uses one and only one modal and is the entire app and not a reusable component there can be multiple of :downs:

It probably doesn't help that I'm trying to use these in yet another component, so it's like app -> othercomponent -> modal

EDIT: Of course I figure out a solution after all this, I just learned watch: was a thing. Still might be good if anyone knows so I know my solution is OK.

showDrawer is a string, a key for what drawer to show, like 'a', 'b', etc... well the actual values are more descriptive.

code:

<component-a-comp v-bind:drawerToShow="showDrawer"></component-a-comp>
<component-b-comp v-bind:drawerToShow="showDrawer"></component-b-comp>

code:

Vue.component('component-a-comp', {
		template: '#component-a-template',
		props: ['drawerToShow'],
		data () {
			return {
				isShown: false
			}
		},
		methods: {
			/*  */
		},
		watch: { 
			drawerToShow: function(newVal, oldVal) { 
			// this checks for === 'b' in other component
			this.isShown = newVal === 'a'
		  }
		}
	});

the bottom-drawer component does $emit('close') when clicking the close button

code:

<script type="text/x-template" id="component-a-template">
    <bottom-drawer v-if="isShown" v-on:close="isShown=false"></bottom-drawer>
</script>

The Merkinman fucked around with this message at 21:32 on Mar 7, 2019

# ? Mar 7, 2019 21:06

Splinter: Jul 4, 2003; Cowabunga!

Lumpy posted:

Well, yes and no. In Vue (and if I remember correctly, Angular) you have stuff like so:
code:
<div id="app-3">
  <span v-if="seen">Now you see me</span>
  <ol>
    <li v-for="todo in todos">
      {{ todo.text }}
    </li>
  </ol>
</div>
The whole v-[whatever] syntax is the "framework stuff" you have to learn that you throw away if you switch. Where React would do something like:
code:
<div id="app-3">
  { seen && <span>Now you see me</span> }
  <ol>
    { todos.map( todo => <li>{ todo.text }</li> ) }
  </ol>
</div>
which is more "just JS" (ignoring the whole JSX thing ) I use JS's map for the LIs, not some framework-specific thing. Obviously it's not such a huge hassle or a recommendation *not* to use Vue, just illustrating a bit for Splitner.

Interesting. My instinct would be to keep HTML out of control statements (and vice versa). E.g. at an old job we used Twig for templating, and the above would look something like this:

code:

<div id="app-3">
  {% if seen %}
    <span>Now you see me</span>
  {% endif %}
  <ol>
  {% for todo in todods %}
    <li>{{ todo.text }}</li>
  {% endfor %}
  </ol>
</div>

Not sure off the bat which I prefer, but you guys have given me a lot to check out!. I'll probably just dive into React for 1 project then go from there in the future depending on what I like/dislike.

# ? Mar 7, 2019 22:23

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

Wasn't VUE originally made for those single page infinite scroll type pages? Looks like it's got exactly what you need there. I'm mostly asking because I'm wondering if it ever evolved past that.

# ? Mar 7, 2019 22:32

lunar detritus: May 6, 2009

Scaramouche posted:

Wasn't VUE originally made for those single page infinite scroll type pages? Looks like it's got exactly what you need there. I'm mostly asking because I'm wondering if it ever evolved past that.

It's a fully fledged "view" library, like React. Your comment is weirdly dismissive considering modern frontend nowadays is mostly working with React, Vue or Angular.

# ? Mar 8, 2019 00:13

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

gmq posted:

It's a fully fledged "view" library, like React. Your comment is weirdly dismissive considering modern frontend nowadays is mostly working with React, Vue or Angular.

This is true. I was literally just reading a blog post detailing the history of react-redux which reminded me that react itself is already almost 5 years old.

People like to make fun of frontend development being this hell hole of constant framework churn, but nowadays I think the vast majority of work is just a few pretty well established libraries.

On top of that, its fairly easy to get up to speed on all three of those so you can use whichever you want.

Thermopyle fucked around with this message at 00:23 on Mar 8, 2019

# ? Mar 8, 2019 00:18

Scaramouche: Mar 26, 2001; SPACE FACE! SPACE FACE!

gmq posted:

It's a fully fledged "view" library, like React. Your comment is weirdly dismissive considering modern frontend nowadays is mostly working with React, Vue or Angular.

I apologize if that's the takeaway from my message; at the time it was introduced that was the backroom-speak I picked up from other parties. That was obviously quite a while ago and hearsay in the first place. We're actually using it at work and I was asking more to see if I should commiserate with or congratulate the front-end guys.

# ? Mar 8, 2019 00:32

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

So, just today I was evaluating a code sample from one of the candidates, and I encountered a "possible infinite loop in render function" in a Vue app. Turns out the person was mutating the state in the template, that was then being looped over in the same template. Don't do that. I'm amazed I never saw that error before.

Btw, I don't agree that majority of web dev is Vue/React/Angular. I've seen so much recent jQuery that it brings sadness to my bitter, old heart.

# ? Mar 8, 2019 01:23

Ruggan: Feb 20, 2007; WHAT THAT SMELL LIKE?!

Adding to the list of subjective opinions:

I use both React and Vue in separate production websites. I also prefer React because it�s much more plain JS than Vue.

That said, I�ve found that Vue is much easier to plug into an existing website without a build system (progressive enhancement). I was able to rip out a lot of Razor and jQuery code and slot Vue in its place without any hassle. I was really struggling to figure out how to do that with React without giving up a lot of functionality.

# ? Mar 8, 2019 02:41

Honest Thief: Jan 11, 2009

gbut posted:

So, just today I was evaluating a code sample from one of the candidates, and I encountered a "possible infinite loop in render function" in a Vue app. Turns out the person was mutating the state in the template, that was then being looped over in the same template. Don't do that. I'm amazed I never saw that error before.

Btw, I don't agree that majority of web dev is Vue/React/Angular. I've seen so much recent jQuery that it brings sadness to my bitter, old heart.

It's kinda funny how the best paid work I got was bootstrapping a ng1.4 app on a Apache server with PHP acting as template renderer and it still had legacy jquery code that you couldn't uncouple cause it would all fall apart

# ? Mar 9, 2019 12:15

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

gbut posted:

Btw, I don't agree that majority of web dev is Vue/React/Angular. I've seen so much recent jQuery that it brings sadness to my bitter, old heart.

Ehh, jQuery is kinda like background radiation in webdev.

Even though it sucks, its kinda like part of JS in such a way I'm not even sure I would consider it.

# ? Mar 9, 2019 18:54

Vincent Valentine: Feb 28, 2006; Murdertime

I've been doing my best to phase jQuery out. This isn't an indictment on it or anything, jQuery is fine, it's just that these days there's rarely anything you need jquery for that isn't covered by your front end framework of choice.

# ? Mar 9, 2019 22:57

life is a joke: Mar 7, 2016

jQuery is something we don't use, but it's useful to bring up in interviews. It might show up now and again depending on the age of the project and the preferences of the original developer, and I think it's pretty good at firming up JS fundamentals / DOM manipulation in it's own of-its-time way.I don't do "gotcha" questions in interviews, but you can surmise a lot about real-world experience by seeing how someone feels about jQuery. People talk about it like it's ancient history but it's really not.

# ? Mar 9, 2019 23:13

Ruggan: Feb 20, 2007; WHAT THAT SMELL LIKE?!

Yeah, jQuery is functionally ok, I just find that it�s mostly replaceable by pure JavaScript and otherwise encourages poor coding patterns in larger projects (lots of spaghetti code).

I mentioned it before but I�ll mention it again - I�ve started replacing jQuery with Vue on a large website I work on at my job - the first page we�re refactoring has gone from 4,000 lines of jQuery JS to about 1,000 lines of Vue JS with greatly enhanced readability.

# ? Mar 9, 2019 23:14

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.

Oh god what the gently caress are you doing this is the worst idea I've ever

edit: re: jQuery.

I work in a house full of .NET MVC devs who all think they're full stack and argue incessantly that jQuery should continue to be used in projects (because it comes packaged with .NET MVC anyway) and there's no need to reinvent the wheel with any of this webpack es6 nonsense. My entire time at this company has been me kicking the back end team out of my front end garden.

Ape Fist fucked around with this message at 11:46 on Mar 10, 2019

# ? Mar 10, 2019 11:44

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

Why is it a bad idea?

# ? Mar 10, 2019 12:48

smackfu: Jun 7, 2004

Two years Angular, one year React, never touched JQuery yet.

# ? Mar 10, 2019 14:51

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

It's possible to have a career in we dev without touching jQuery. If you work at an agency (new projects/one-offs where you choose the stack) or a startup (recent code, again you choose the stack). The moment you start consulting or join a company with a large, pre-existing codebase, the probability of encountering it starts approaching 1.

edit: nothing against jQuery. It saved my butt many a time in my early career. I'm mostly against its misuse in the wild, but that can be said about anything. Oh, and monadic composition that doesn't enforce monadic laws, but that's another story...

gbut fucked around with this message at 15:45 on Mar 10, 2019

# ? Mar 10, 2019 15:39

Volguus: Mar 3, 2009

On the other hand, you have this simple page application, with a form with 5 fields on it that submits some information to the backend to be saved into the database, and there are people out there who use angular or react or god knows what other 3mb minified abomination only because they do not know that document.getElementById is a thing.

These libraries (Vue, react, angular, etc.) have their place. A To Do list app is not one of them.

# ? Mar 10, 2019 17:48

Drastic Actions: Apr 7, 2009; FUCK YOU!
GET PUMPED!; Nap Ghost

Ape Fist posted:

(because it comes packaged with .NET MVC anyway)

They�re gonna hate it when they see ASP.NET Core.

# ? Mar 10, 2019 21:22

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

Volguus posted:

On the other hand, you have this simple page application, with a form with 5 fields on it that submits some information to the backend to be saved into the database, and there are people out there who use angular or react or god knows what other 3mb minified abomination only because they do not know that document.getElementById is a thing.

These libraries (Vue, react, angular, etc.) have their place. A To Do list app is not one of them.

fwiw, preact is 3kilobytes.

I mean, I wouldn't use it for a simple form that is just going to get submitted and thats that. But I would possibly use it for a todo list app.

Thermopyle fucked around with this message at 22:03 on Mar 10, 2019

# ? Mar 10, 2019 21:28

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

jquery is a lot bigger than react too so people who don't want to use it for little things but happily add jquery are misguided.

# ? Mar 11, 2019 14:29

Adbot: ADBOT LOVES YOU

# ? Jun 2, 2024 14:30

smackfu: Jun 7, 2004

Anyone have tips on working with static assets (like images) and CDNs and file naming? We recently had a designer say �oh that SVG we gave you that you deployed into production had a small layering bug, here is the new one.� We could just add a �b� or �v2� to the filename but maybe we should version them from the start? It�s our first time dealing with the CDN for this stuff so we are kind of winging it.

# ? Mar 11, 2019 15:39

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

«‹›235 »