Live data from Hacker News

Why Is Front-End Development So Unstable?

breck-mckye.com

91–100 of 366 posts

Re: Why Is Front-End Development So Unstable?

#91

Earlier quoted context omitted.

In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure. This is not a fault of jQuery, as it never intended to solve those problems. Like you said, it is purely meant to solve the DOM issue.

>In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure What does that even mean?

Bad jQuery apps follow the pattern: When “.x” is clicked, show “.x .y”, add className “xyz” to “.z”, and fire off an XHR to “/api”.

This defines what the developer wants to happen, but is brittle and hard to test. Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes, so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic.

This is possible to do with jQuery too, but the library doesn’t do anything to help you. This is one of the primary complaints levelled at React, too.

Re: Why Is Front-End Development So Unstable?

#92
post #74
post #62

Earlier quoted context omitted.

> How did it happen that junior JavaScript developers feel so insecure about using the standard stuff? I know a lot of "developers" that are learning frameworks and not javascript. When you start in a black box then you look for other black boxes to fill in the gaps you need. I am not even opposed to that. I strongly believe in never re-inventing (unless its academic) what can be used and has been tested, but when th…

One has to learn somehow, and reinventing is an important part of that. Aspiring artists will paint nude figures and flower arrangements and white cubes on draperies, even though these subjects were done to death centuries ago. Junior programmers should feel the same way about doing things that have already been done: someone probably has done it better, but I still have to do it for myself, maybe a few times over to…

I don't disagree its why i said unless its academic.

Re: Why Is Front-End Development So Unstable?

#93
post #73

Earlier quoted context omitted.

>I picked up Python at 14 and that had absolutely no barriers for entry other than installing IDLE on a laptop. Will you ever be employed by a "serious company" to make commercial desktop software just for few demos you show from your laptop?

I set up an entire flask dev environment with one pip command, too. Still no real barrier to entry, at least not any more than front-end development.

I would say: 1 loose portfolio of demos without any history of signed off successful projects will still be getting you a decent job in webdev, but for sure not in commercial desktop software industry

Re: Why Is Front-End Development So Unstable?

#94
post #93

Earlier quoted context omitted.

I set up an entire flask dev environment with one pip command, too. Still no real barrier to entry, at least not any more than front-end development.

I would say: 1 loose portfolio of demos without any history of signed off successful projects will still be getting you a decent job in webdev, but for sure not in commercial desktop software industry

Ah, I see what you mean. I can't really comment any further as I don't know what it takes to get hired as a webdev, but I'll take your word for it.

Re: Why Is Front-End Development So Unstable?

#95
post #6

> 2.5 years for the youngest isn’t that old in the scheme of things - it’s less than half the support lifespan of your typical desktop OS, for example - but it’s still a ways off our caricature. Let's compare it with some server-side technologies: Python/Django: 2005 Python/Flask: 2010 Nginx: 2004 Perl/Catalyst: 2006 Maybe I'm biased towards older software, but the difference to the popular frontend stuff is striking…

The difference is that the backend model has been around for 20 years if not more. You're locating lots of old-ish and stable libraries because that's when that stuff was made. Maybe you don't remember the days of Zope, Subway, Turbogears, Paste, Pylons, Werkzeug etc just within Python, but that happened. React is a relatively young model for the web. Wait 10 years and it'll look the same. I personally don't feel it'…

The front-end world is rediscovering lessons learned in the days of desktop thick clients from the 90s, if not earlier. I rage far too often that I have to jump through all these hoops to slam out some UI that I could have done in high school with VB6.

Re: Why Is Front-End Development So Unstable?

#96

This is a really well-written and well-thought out piece. The author touches on a number of points but never gets polemical. This piece resonated with me particularly well: > Be wary of self-promotion > Over the last few years I’ve seen much more aggressive self-marketing in the JavaScript world, possibly due to the rise of paid online training materials and the employment/consulting advantage of being a Github ‘cele…

I'm finding the growing celebrity culture of programming to be troubling. I find that programming is becoming less and less about code or architecture and more about evangelism and marketing, but I'm not sure what changed in the incentive structure for this to happen, and I would like to find out. Aside: This has made me reconsider being a career programmer.

I think that this was inevitable given the rise of social media and the Internet. It’s still entirely possible to be a great developer without having a Twitter or Facebook account, but it’s tempting to feel like I’m missing out on information from not subscribing to the latest fight on Twitter.

Re: Why Is Front-End Development So Unstable?

#97
post #6

> 2.5 years for the youngest isn’t that old in the scheme of things - it’s less than half the support lifespan of your typical desktop OS, for example - but it’s still a ways off our caricature. Let's compare it with some server-side technologies: Python/Django: 2005 Python/Flask: 2010 Nginx: 2004 Perl/Catalyst: 2006 Maybe I'm biased towards older software, but the difference to the popular frontend stuff is striking…

No love for Rails? It's also been around since 2005.

I hate the fact that Ruby doesn’t get more love. It’s a great language on its own. It doesn’t need Rails.

Re: Why Is Front-End Development So Unstable?

#99

Earlier quoted context omitted.

>In my experience the app tends to evolve around jQuery selectors and event handlers, rather than having a well defined structure What does that even mean?

Bad jQuery apps follow the pattern: When “.x” is clicked, show “.x .y”, add className “xyz” to “.z”, and fire off an XHR to “/api”. This defines what the developer wants to happen, but is brittle and hard to test. Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes, so that the parts can be effectively unit tested and the UI can be changed witho…

> Bad jQuery apps follow the pattern: When “.x” is clicked, show “.x .y”, add className “xyz” to “.z”, and fire off an XHR to “/api”.

This defines what the developer wants to happen,

Yes, it does. All in one place, in about 10 easy to understand, easy to debug lines of code.

>but is brittle and hard to test.

I don't see how it's brittle, or hard to test. You click the button, and verify that it does what it's supposed to. Having done it more times than I can possibly count, and ending up with robust code, shipped on time, I can tell you that it's not hard, if you know how to do it.

> Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes,

Which, IMO, makes something simple to understand and dead simple to debug into something painfully, ridiculously complex. And people complain about "jQuery spaghetti code".

>so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic.

You cannot effectively unit test UI code, if by effective, you mean that it can replace manual testing. It can't replace manual testing. Someone will have to click that button under all of the likely scenarios and verify that it works. I'm sure it's not to you, but to me, writing unit tests for UI code would be a massive waste of time.

If someone thinks they can be more productive using JS frameworks, and I don't have any personal financial stake in their productivity, then they should use them. But I don't see web development using a few simple tools like jQuery as difficult or mysterious or time-consuming.

Last year I interviewed a few recent boot camp grads and they all sent me a link to their copy of the same React-based project. When I asked them questions about how things worked, in generic terms, for example, "what do you think makes this picture slide down slightly and expand in size when I mouse over it", they had no clue. I guess it was just a React component they dropped in, following the steps in the tutorial. I'm not faulting those people -- they paid a lot of money and did exactly what they were told they needed to do to land a sweet high-paying programming job. But they're simply of no use to me. I need the one who looks at it and knows right away that it would take about 4 lines of CSS to accomplish, even if they had to consult a CSS reference to find out exactly which properties/values to use.

Post reply on HN