Live data from Hacker News

Why Is Front-End Development So Unstable?

breck-mckye.com

211–220 of 366 posts

Re: Why Is Front-End Development So Unstable?

#211

Earlier quoted context omitted.

The minimum ability someone needs to have for me to consider them a programmer is the being able to write a parser using yacc or something equivalent. Anything a person with that ability does is programming because they know enough to realise when switching to putting legos together it more efficient.

If not programmers, what are these people who spend their days programming, but who may not necessarily have ever written a parser using yacc because none of the jobs they've ever had have required that?

Depends how superior you want to make yourself feel.

Re: Why Is Front-End Development So Unstable?

#212

Sorry but I find font-end development pretty stable. Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal? In my career I also had to learn Java, PHP, C#, Node.js, bash, batch, Python… Build apps with Spring, CakePHP, Symfony 1 & 2, ASP.NET MVC 3 & 4… Query database with Hibernate, Entity Framework, Linq SQL… Handle dependencies with Maven, Nugget… Store data in Post…

> Having to learn a new library every 3-4 years (because of a new job, generally) is it really a big deal?

_If_ frontend development is all you do, then no, it isn't.

One of the good things about the internet is that it's possible for a lone wolf to build and ship something amazing. One person can understand enough of the full stack, from HTML/CSS through JS to a serverside language and basic server administration, to build something great, unfunded.

The constant churn in frontend development makes that increasingly difficult. If you find a useful library for your backend code, great, just 'gem install' it (or pip or whatever). Useful JS library for your frontend code? You've got to learn the packaging technology du jour just to be able to install it. In two years' time this'll be different, and you'll have to get to grips with another complex web of tiny little components that fit together in ways you don't fully understand. Whereas your backend (for me, Ruby+Postgres) is still essentially the same it's always been, and just as great.

Indie full-stack developers can no longer keep up with frontend development, and I think that's a great loss.

Re: Why Is Front-End Development So Unstable?

#213

Earlier quoted context omitted.

The minimum ability someone needs to have for me to consider them a programmer is the being able to write a parser using yacc or something equivalent. Anything a person with that ability does is programming because they know enough to realise when switching to putting legos together it more efficient.

If not programmers, what are these people who spend their days programming, but who may not necessarily have ever written a parser using yacc because none of the jobs they've ever had have required that?

Stamp collectors.

Re: Why Is Front-End Development So Unstable?

#214

Earlier quoted context omitted.

Someone with that attitude isn't going to last long working for you anyway: as soon as they're hired, they'll put your company on their resume, blog about everything they've learned, trump up their first project, and start looking for their next gig, usually getting a big pay increase in the process.

Indeed - and possibly write an expose about how terrible it was to work for us that will gain traction across a variety of social media sites. (I am not usually this cynical before lunchtime, honestly.)

You mean realistic.

NDAs are there for a reason.

Re: Why Is Front-End Development So Unstable?

#215
post #113

Earlier quoted context omitted.

Somewhat unrelated, but a couple of questions for you: 1. How did you learn elm? 2. Was elm your first functional language? (Not wanting the "javascript is a functional language" battle here plz) 3. What is your backend written in? Do you maintain that? 4. What libraries do you make use of? 5. Any regrets?

I wrote this in Elm: https://ixberg.com . (feel free to sign up, use it, share it). I learned Elm by going to an intro course at Lambdaconf, and watching this https://frontendmasters.com/courses/elm/ and coding in it. Elm was my first PURE functional language. I've done some Scheme before. Backend is Firebase. No special libraries in particular. No regrets.

Am I missing something on ixberg.com, I can't sign up?

Only have sign in but that is not clickable?

Re: Why Is Front-End Development So Unstable?

#217

Calling out Vue.js as a possible solution is hilarious. Selling a trending technology as a silver bullet is exactly the problem he complains about in the article. Comparing the development methodology of Facebook - the company behind React - and this mindset is illuminating. Facebook famously rewrote PHP and added extensions like XHP rather than start their codebase from scratch. React follows a similar philosphy. It…

To be fair, he said he was interested in it and not necessarily it was a solution.

Still though, he does make it sound like "Oh hey there are all these problems... but this one, the newest of em all, seems to be interesting" lol

Re: Why Is Front-End Development So Unstable?

#218
> Before we get carried away, it’s worth validating whether the meme really has basis in reality. Do front end technologies actually change that quickly?

> In the sense of major view technologies, probably not. Consider this list of the highest ‘starred’ JavaScript front-end technologies on Github:

Seriously? So you're basing front end technology changes based on stars on Github?

Also I think it's wrong to say that front end technologies have "changed." It's just people have discovered better or just different ways of building things and that should be okay.

I agree with the portion how it can be overwhelming to a junior developer, but it is also easier in some ways. In truth, if you are a junior developer (or hell any developer really), your focus should be less on choosing the right technology and more on understanding what technologies fit what needs.

Re: Why Is Front-End Development So Unstable?

#219

Web frameworks are churn-y because they are incredibly leaky abstractions covering really awkward impedance mismatches. This means that they are never quite satisfactory - and that just to use one, you need to be capable of building a new one yourself. Think of a typical web app. Your data exists: 1. As rows in a database, accessed via SQL 2. As model objects on the server, accessed via method calls and attributes 3.…

What is curious is that the tech industry has been very conservative about rethinking these 6 things that you just listed. Why rows in a relational database? Why objects? Why Javascript? And why HTML? We'd surely be in a better place if we got rid of these things and rethought our approach from first principles. I've written about these issues many times before. Regarding the problem with objects, I wrote "Object Ori…

There have been attempts at rethinking it though; noSQL was the buzzword of a couple of years ago, and even nowdays there's mature tools like Firebase that allow you to store and retrieve data much more directly than e.g. SQL. The challenge in nosql storage is of course data migrations and whatnot. But yeah, in theory you can just open up a MongoDB instance to your front-end and not have to bother with SQL or much of a back-end.

And your last comment doesn't make much sense tbf; the big frameworks, most notably Angular and React (and its ecosystem) were both designed to be great front-end technologies.

Re: Why Is Front-End Development So Unstable?

#220

Web frameworks are churn-y because they are incredibly leaky abstractions covering really awkward impedance mismatches. This means that they are never quite satisfactory - and that just to use one, you need to be capable of building a new one yourself. Think of a typical web app. Your data exists: 1. As rows in a database, accessed via SQL 2. As model objects on the server, accessed via method calls and attributes 3.…

That's good, in each cycle, sooner or later you get improvement: webpack over grunt, react over jQuery and npm over vendoring your jQuery plugins. OP forgot how life looked when your web app project was handcrafted HTML page with manually inserted scripts tags. When your form submission was multi-level backend API in PHP. jQuery plugins with 20+ options published randomly on the internet.

there's still lot of churn coming from following a moving target.

like when ios made the top of the page untouchable least it pulled safari out of full screen, breaking the toolbar convention of the past two decades.

and when ios made the bottom of the page untouchable least it pulled safari out of fullscreen, breaking the bottom bar icon webapp did under the very apple guidelines > https://developer.apple.com/ios/human-interface-guidelines/b...

and when ios made the app sides unusable due to a varying notch, having a whole set of unstandard properties you have to handle to manage correctly being into safari on a iphone x

if we had companies following standard decently and a linear, planned grow instead of the organic mess we're into, it'd be far easier to produce building blocks that work in a stable manner over time.

we're better today than in netscape days, but marginally. as complexity increase the cost of this constant churn does too and the saving from better framework are not quite enough to offset the constant fads that come and go.

Post reply on HN