Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Is Front-End Development So Unstable?

breck-mckye.com

Post reply on HN
Print view View original

31–40 of 366 posts

Re: Why Is Front-End Development So Unstable?

#31

Post by kotrunga »

mseebach wrote: post #16

> Put yourself in the shoes of a junior-to-mid-level JavaScript developer, writing a new application for the first time. > But how could you do better, Junior Developer? Who was there to guide you? The Senior Developers, too, are learning as they go. We’re caught in this avalanche too, just trying to keep up to date and remain employable. No, this is exactly the problem: junior developers making major architecture de…

> But this can easily hide the complexity that pretty quickly creeps in, and reasoning about complexity is one of the crucial things that a senior developer brings to the table.

Yes- so true. Taking a web app / whatever from the beginning stages to handle proper complexity, anything from scaling to ... the business wanting cough forcing cough a "quick fix".

Re: Why Is Front-End Development So Unstable?

#32

Post by freedomben »

I do wonder how much of the instability relates to the strong opinions that the JS community often has (I'm guilty of this too). Any broad stereotype is going to be wrong a lot, but it does feel like JS devs on average are a lot more opinionated about the way things ought to be. They are also more disgusted and unhappy working in codebases that don't conform to their standards.

I truly don't mean this as a bad thing, in fact I put myself in this category. Obviously it can be a bad thing if it causes you to be unable to work with others, but it can also make for elegant, consistent, and hackable codebases that boost productivity and minimize bugs.

Re: Why Is Front-End Development So Unstable?

#34

Post by michaelbuckbee »

mseebach wrote: post #16

> Put yourself in the shoes of a junior-to-mid-level JavaScript developer, writing a new application for the first time. > But how could you do better, Junior Developer? Who was there to guide you? The Senior Developers, too, are learning as they go. We’re caught in this avalanche too, just trying to keep up to date and remain employable. No, this is exactly the problem: junior developers making major architecture de…

We're missing the context here. For many (most?) web apps I feel like things have kind of gone wrong if the front end requires "major architectural decisions". That's not a knock against the greatness of React, etc. so much as it's my observation that most web apps are small and from a technical standpoint quite boring, a smattering of static pages, a couple web forms, etc.

Re: Why Is Front-End Development So Unstable?

#35

Post by dustingetz »

dustingetz wrote: post #5

It's because of all the icky data-sync for the client/service round trips. An async, slow, failure-prone concern wired throughout the entire codebase. I/O hurts everyone in subtly different ways and it's hard to solve so you see a lot of churn. service/database has this problem too (the ORM flamewars of the 00s) but to a much less degree because it is in a happier place on the latency chart: https://gist.github.com/j…

Continued: Churn is further compounded by the Lisp Curse; an individual hacker can scratch his itch in Javascript all by himself and then stick it on github, the other three 1995 langs (Java/Ruby/Python) never quite reached this level of empowerment of individuals. That's great but also means an explosion of activity from smart inexperienced hackers who don't quite have a full understanding of the problem they are trying to solve because they are just one person. And when the problem is I/O that's a recipe for going in circles. http://winestockwebdesign.com/Essays/Lisp_Curse.html

Re: Why Is Front-End Development So Unstable?

#36

Post by jillav »

mseebach wrote: post #16

> Put yourself in the shoes of a junior-to-mid-level JavaScript developer, writing a new application for the first time. > But how could you do better, Junior Developer? Who was there to guide you? The Senior Developers, too, are learning as they go. We’re caught in this avalanche too, just trying to keep up to date and remain employable. No, this is exactly the problem: junior developers making major architecture de…

Yes exactly. Building something fast without understanding the complexity behind can be both a blessing and a curse.

It's a blessing for the one who needs to deliver. It's a curse for the one who needs to learn.

To be efficient in the long term, and not get lost among the framework wars, one must use what was learned in Engineering School, University or from seniors : write specs, set priorities, plan ahead. Use or build the tool that suits your need, do not follow trends.

Think like an engineer.

Re: Why Is Front-End Development So Unstable?

#38

Post by rhapsodic »

underwater wrote: post #23
freedomben wrote: post #11

Earlier quoted context omitted.

> but it seems many developers frown upon it these days This is sadly very true. jQuery is almost used as an insult these days. Having code be called "jQuery Spaghetti" is about the worst epithet that can be hurled at a javascript codebase these days.

jQuery is great for small snippets of code, but encourages a quick and dirty style that collapses for larger applications. Most jQuery applications couple their business logic to the mechanics of working with the DOM. It was also intended to smooth over browser inconsistencies and gaps in APIs. This is less relevant these days now that browsers are more mature.

> jQuery is great for small snippets of code, but encourages a quick and dirty style that collapses for larger applications.

I keep hearing (well, reading on HN) criticisms of this sort about jQuery and they are absolutely not supported by the years of experience I have using jQuery for front-ends that have in many cases been quite complex. I use it because it greatly simplifies DOM manipulation and event handling. (e.g., no need to remove event handlers for a subtree removed by the .remove() method.)

Re: Why Is Front-End Development So Unstable?

#39

Post by pavlov »

This part puzzles me:

> "Put yourself in the shoes of a junior-to-mid-level JavaScript developer, writing a new application for the first time.

> "It starts innocently enough. You have a completely clean slate and want to keep things simple. You are a devout Agilist and YAGNI is your watchword. So you begin with a ‘simple, barbones framework’. That sounds good, doesn’t it? (Even if it did not, that’s often the only choice you’ve got).

> "Being barebones it does little, so the task falls on your shoulders to choose some helper libraries. If you are doing frontend work, it might be helpers for Redux for forms and API requests. If backend, it might be middlewares for Express."

Why is the default answer to the problem of "it does little" to "choose some helper libraries"? Shouldn't it be: "I'll write some code to make it do more"?

Why does this first-time app developer need Redux? Why would she need a helper for Redux to do API requests? These days you can just call fetch() — it really doesn't get any easier.

All the APIs that one gets in the browser or in Node.js are already very high-level and easily understandable by entry-level developers. If anything, piling more leaky abstractions on top will just make things more complex. How did it happen that junior JavaScript developers feel so insecure about using the standard stuff?

Maybe it's because more senior developers have spent two decades crapping on the standard stuff. Therefore, as a self-appointed spokesperson for the veterans, I hereby grant all junior JavaScript developers full permission to just go ahead and program whatever they want without having to look for a single library or creaky build tool — and they shouldn't feel bad about it in the least.

Re: Why Is Front-End Development So Unstable?

#40

Post by rossdavidh »

I give the author credit for thoughtfully trying, but not much of this seems to actually explain why it is Javascript that has this problem, more than Python or Ruby or Java or C#. The reason for Javascript's excessive churn must, I think, be related to its most typical use case as a browser client-side language, and in particular to its use in single-page apps. The rest of it are all good points, but I'm not sure they explain why Python, etc. don't have this problem (as bad, anyway).
Post reply on HN