Live data from Hacker News

Why Is Front-End Development So Unstable?

breck-mckye.com

261–270 of 366 posts

Re: Why Is Front-End Development So Unstable?

#261
post #14

> What is to be done? ... Consider non-microlib architectures What about what happened with Angular (1), the 3rd library on your list? That whole framework was deprecated in favor of Angular (2). Additionally, the list of front-end libraries given doesn't really reflect the landscape front-end devs have traversed. Years ago, I remember working on an app that heavily relied on YUI around the time that library was shut…

I feel like Angular was reaching escape velocity and becoming the one thing to learn and just as it was happening they announced Angular 2, which was originally going to have no upgrade path and no two-way binding (arguably the killer feature), out of performance concerns that weren't a problem for the vast majority of use cases. Even after they backtracked on a lot of this it was too late; they had forever tarnished their own product.

I really loved Angular 1 precisely because it had everything you needed, more or less, built-in.

Re: Why Is Front-End Development So Unstable?

#262

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…

Did you read the article? Here's a snippet from the beginning: > 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: +------------------------------------------------------------+ | Library | Stars | Released | Age | |--------------------------------------------------…

I never understood this argument. You are comparing frameworks. All of those are nothing but fancy ways to play with the DOM. There's nobody telling anyone to jump from one to the other.

Do you migrate your PHP or .NET projects every time a new framework comes out? No. You shouldn't with front-end either.

It's as if you printed a table that goes "CakePHP; Yii; CodeIgniter; Laravel; Symfony; Phalcon; Zend." and then complained about the PHP ecosystem.

Re: Why Is Front-End Development So Unstable?

#263
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…

I think more developers should use jquery to prototype an app and move torward a framework when it is needed. The same should be said when adopting redux when using react . Also webpack for building and moving beyond SQLite for data .

IMO VueJs is new JQuery (evolotion). JSX(React) is more revolutionary way to build UI and not only web specific. If you need web specific or progressive enhancement or you just don't know modern JS development tools it's better to start with Vue. My friend who can barely code does quite nice pages in Vue. It's a big success of this framework. Although I prefer React as it's gives me more control/freedom.

And if you want easy start just open https://codesandbox.io/

Re: Why Is Front-End Development So Unstable?

#264

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.…

All of this is why, in the end, more and more... I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for, if I understand enough to write an SQL command, and use a library for that DB that does parameterized queries? On the front end, I tend to lean towards abstractions that work together... I really like React and the material-ui library's switch to JSS. It's relatively clean, and useful…

I do things "the hard way".

I agree, except that I would argue it’s often the easier way. If I had to give a one sentence answer to the original question, it would be, “Front-end [web] development is so unstable because people introduce so much accidental complexity.”

For example, while I don’t disagree with Meredydd that there can be awkward mismatches between the layers he described, I also think several of those layers only exist if you presuppose an object model in your programming languages. Arguments about object-relational mismatch have been made as a criticism of OO for far longer than we’ve been building substantial front-ends for web apps.

If instead you stay closer to the real data, your architecture reduces to the more traditional persistence and presentation layers. Since you’re on the web you have a distributed system so you also need a protocol for the remote communication between those layers. However, there aren’t any inherent mismatches in that combination, any more than there are if you build native applications or distributed systems using something other than web technologies.

Re: Why Is Front-End Development So Unstable?

#265

Earlier quoted context omitted.

All of this is why, in the end, more and more... I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for, if I understand enough to write an SQL command, and use a library for that DB that does parameterized queries? On the front end, I tend to lean towards abstractions that work together... I really like React and the material-ui library's switch to JSS. It's relatively clean, and useful…

> I do things "the hard way". If I'm using a dynamic language WTF do I need an ORM for I think it's mostly premature optimization. People think writing DTOs is challenging, so they want an ORM. But since you end up needing DTOs anwyays, removing SQL capabilities from the app means writing SQL in not SQL, and things like joins suddenly become slow and problematic and result in really heavy systems that are harder to c…

> People think writing DTOs is challenging

I don't think this is true. Writing these objects isn't difficult, it's tedious and repetitive. That's why people keep trying to automate it!

The problem is that you can't quite automate it smoothly, because SQL doesn't work like objects. You avoid this interface issue by taking the hit for the tedious-and-repetitive stuff directly (and I agree that's often the right choice) - but that doesn't dissolve the problem.

Re: Why Is Front-End Development So Unstable?

#266

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, t…

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

Who exactly? Did you ever hear a front-end developer say that or are you building a strawman?

There's nothing stopping anyone from building a simple jQuery powered website. There's nothing stopping anyone from building an app with Angular 1 either. Hell, you can even download .zip files on GitHub, unarchive them in a folder and start using them in your projects. Complex build system are only a way to streamline development when you get to a certain level of projects output.

Re: Why Is Front-End Development So Unstable?

#267

Earlier quoted context omitted.

Did you read the article? Here's a snippet from the beginning: > 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: +------------------------------------------------------------+ | Library | Stars | Released | Age | |--------------------------------------------------…

I never understood this argument. You are comparing frameworks. All of those are nothing but fancy ways to play with the DOM. There's nobody telling anyone to jump from one to the other. Do you migrate your PHP or .NET projects every time a new framework comes out? No. You shouldn't with front-end either. It's as if you printed a table that goes "CakePHP; Yii; CodeIgniter; Laravel; Symfony; Phalcon; Zend." and then c…

Did you actually read the argument though?

Re: Why Is Front-End Development So Unstable?

#268
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…

I think more developers should use jquery to prototype an app and move torward a framework when it is needed. The same should be said when adopting redux when using react . Also webpack for building and moving beyond SQLite for data .

I think more people should understand what problem jQuery was meant to solve:

a) provide sane API for DOM manipulation b) hide all the ugly bits and bugs of different browsers.

Re: Why Is Front-End Development So Unstable?

#269

Earlier quoted context omitted.

>You can test conditional logic, state mutation, and any function without side effects. It takes very little time and definitely improves the codebase. Testing is very dependent on the culture of your team and company though. For sure. We have a team of people dedicated to testing. Compared to developers, they're easier and cheaper to hire. Our developers, who are very brilliant and very expensive, mainly write code…

functional code is VERY maintainable... If you built it to be thrown away, or replaced, that tends to make it more maintainable. Making something testable, even if you don't write tests, leads to better code.

>Making something testable, even if you don't write tests, leads to better code.

That's strictly your opinion, which I do not happen to share.

Re: Why Is Front-End Development So Unstable?

#270

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.

Is this actually a new phenomena? I remember when I started programming c. 2000, the big-name programming gurus were folks like Kent Beck, Ward Cunningham, Uncle Bob, Ron Jeffries, Dave Thomas, Joel Spolsky, Jeff Atwood, Martin Fowler, et al. While some of them mostly knew their stuff, some were outright hacks (Peter Norvig's vs. Ron Jeffries' attempts to create a sudoku solver is one of my favorite examples [1]). Mo…

I think this is a very good point. But it's also important to remember that not all programmers/tinkerers that are creating blog posts/videos are looking for fame - some of them are just proud of something they built, and that's fine.

Inspiration is a great enabler, and taking a few shortcuts to make something work may be just the thing that allows someone to actually finish one of their projects. The problem is that if you lack the knowledge to see that something is a hack - you learn things the wrong way. Still, without this inspiration - some people wouldn't start to learning at all.

Post reply on HN