Earlier quoted context omitted.
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.
It's an extremely large and diverse field. There are plenty of us who aren't celebrities and don't care about celebrities (except to the extent that it is caused by deep expertise). Just like you ignore reality TV celebrities, ignore these guys. It's just noise. Turn off Twitter and read "Growing Object-Oriented Software, Guided by Tests" instead.
Why Is Front-End Development So Unstable?
101–110 of 366 posts
Re: Why Is Front-End Development So Unstable?
#102This 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…
Re: Why Is Front-End Development So Unstable?
#103UI used to be simple, a page, a few links, click through to other pages. Then we needed templated pages, because we had a lot of pages.
Then full blown 'applications' were ported to the web, and life was a nightmare of double-headed dragons and dark holes with pikes. Jquery provided some help here but it was more in terms of nuts and bolts, than as an architecture.
Then came all the MVC libs which really helped enforcing a structure for large apps.
Then came Angular and all of its madness, but a positive step ahead, giving us usable SPA.
React brought some sanity back and now Vue (in my opinion, don't shoot) brings the sanest/cleanest way forward.
My guess is what we do on the web will change once again, in a few years, and we will throw all that out and start again with new framework. Whether it will be in AR or still on the web, there are still many problems to solve.
E.g. the whole 'responsive' thing.
Re: Why Is Front-End Development So Unstable?
#104This 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.
The aggressive personal branding is clearly spillover of startup hype/marketing/branding styles and techniques. If your whole career has been at startups then that is just called "marketing" to you.
Also: it works. "No one ever got fired for going with IBM" is now applied down to the micro-level. Few choose a project because of a code/architecture review, most choose one because it has a good reputation. The industry has fantastic expertise at manufacturing reputations by now.
Re: Why Is Front-End Development So Unstable?
#105Earlier quoted context omitted.
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'm not sure what changed in the incentive structure for this to happen, and I would like to find out. People started getting paid more for doing this because managers have no idea what programming actually is.
Re: Why Is Front-End Development So Unstable?
#106Earlier 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?
There were a ton of times where the complexity of the situation made it so hard to know how to debug something. I mean you had to keep track in your head in a given piece of code what the UI state was, what classes or event handlers were toggled on or off, what the value of various variables were etc. In order to keep my sanity I would have to create functions that basically do what React or other frameworks give you out of the box so it would be easy to reason about everything.
There was so much code like this: var $snippet = $().append(...).addClass().on('click', handler => { if (alienState) { $snippet.off('click') } else { $snippet.on('click', handler2) } }) $(".parentClass > ").remove() /clear any dom framents in there //before a fresh injection! fingers crossed!*/ $(".parentClass").append($snippet)...
etc etc
I'm sure there is a way to do disciplined excellent jquery code. I'm always quick to say its the coder(s) that make a piece of software code good or bad. But if you were to make a well made jquery application you would need to implement some kind of design pattern, and exercise some kind of conventions and discipline that you could really get for free with a framework.
Re: Why Is Front-End Development So Unstable?
#107Earlier 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…
I’ve seen 10,000 line single jquery files handed off to other teams who were asked to merge them into their 4,000 loc customized quasi consumer of the 10,000 loc file. This was at a well respected and iconic tech company with very smart engineers.
Even good people and teams can suck at architecture.
I’ve taken those codebases and refactored them to be testable so I know it’s possible. But why not just use something sane like react to begin with, considering it’s 2018 now. At that point, backbone was only a year old.
Re: Why Is Front-End Development So Unstable?
#108> 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…
I personally dislike js but this doesn't seem like an unusual phase, although js is so widely used it involves a lot more people than normal.
Developers don't frown on jQuery for a tiny dynamic thing, but it is not for applications. jQuery is CGI and they need WSGI, Django and Flask now.
Re: Why Is Front-End Development So Unstable?
#109because browsers changes a lot.
Re: Why Is Front-End Development So Unstable?
#110Earlier quoted context omitted.
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 suppose…