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

311–320 of 366 posts

Re: Why Is Front-End Development So Unstable?

#311

Post by lolsal »

Doctor_Fegg wrote: post #212
ggregoire wrote: post #131

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…

I could not quite articulate what I was thinking, but you have captured my thoughts very well.

I used to be a 'full-stack' developer - back when 'installing' JS libraries meant dropping the file(s) into your `static/js/` directory and running with it. I find frontend technology so chaotic (not complicated, just chaotic) that combined with the rapid improvements of browser/css/html feature support I was left in the dust and relegated to be a backend engineer.

Re: Why Is Front-End Development So Unstable?

#312

Post by hajile »

digitalzombie wrote: post #163
eropple wrote: post #118

Earlier quoted context omitted.

Something like React isn't even an application framework, though, it's a view library of compositional functions feeding into a tree diff. How does functional, side-effect-free code increase complexity ? What makes your side-effecting code more testable and verifiable than unambiguous in/out functional transforms?

Personally for me it's a trade off and it does increase complexity. With jQuery and such you just include a script and back then there were no package management system, glup/grunt, webpack, yeoman/brunch, etc.. Also the client side rendering make SEO hard. jQuery just get stuff done but at the same time the organization of your code is up to you and you do sacrifice some reusability but in general the trade off is c…

I've heard about webpack and build tools a ton and I don't understand the issue.

If your project is simple, webpack setup is copy/paste (v3) or no config at all (v4). If your project is doing complex stuff, webpack is more in-depth, but a breeze compared to the make files and XML config of other languages. More importantly, webpack has a very clear tutorial and extensive documentation. You have to go incredibly far off the normal path to run into something that isn't covered. Off topic, but augmenting webpack dev server express instance made dev work many times easier on my current project.

Re: Why Is Front-End Development So Unstable?

#313

Post by chrisco255 »

lkrubner wrote: post #210
meredydd wrote: post #56

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…

HTML has lots of problems, but it's there, sitting on every computer and mobile phone that you can think of. There's not really another viable cross-platform alternative. Your only option would be to render to HTML5 canvas and create some alternative rendering model from the DOM (not unlike Flash). There are tools that exist to do that today (CreateJS, for example), but they're not mainstream. You pay a huge penalty by going against the standard platform. All the interop, tooling, and libraries out in the world work on HTML/JS. Re-inventing that from scratch and coming up with your own hacks/solutions for accessibility, responsive design, style sheets, components, etc, is expensive and unlikely to succeed. I agree that OOP is an expensive disaster...but thankfully JS is flexible enough to code using functional patterns.

Re: Why Is Front-End Development So Unstable?

#314

Post by jhall1468 »

emodendroket wrote: post #290
Chris_Newton wrote: post #274

Earlier quoted context omitted.

That stuff works fine if your client-side needs are simple To be fair, just about anything works fine if your client-side needs are simple. However, I have reached the opposite conclusion to you: the more customised and complicated and large-scale and long-lived the software becomes, the less value I see in a lot of the popular but ever-changing web technologies and the more I am likely to favour building on the stan…

I don't like microlibraries very much either, but that's a different question. A monolithic frontend framework can make your life easier.

Monolithic frameworks can also corner you into edge cases where you end up having to write shitty work arounds because their "opinionated" framework didn't have an opinion based in reality.

Re: Why Is Front-End Development So Unstable?

#315

Post by hajile »

The real complaint right now should be Babel v7 -- or more specifically, the community around it. Babel v7 has been in development for quite a while. It's still changing and isn't even a RC yet.

I understand the need to test new compiler builds, but production isn't the place to do that (especially not until a RC is released). A beta designation is meaningless if its used as though it were just a normal production release.

Using a beta compiler in production tools, libraries, etc shows EXTREME inexperience. I have a number of dependencies that I cannot update because the new versions rely on various v7 builds (ranging from ancient alphas to bleeding edge betas).

I suspect the issue is that most JS dev teams are small with projects small enough that edge cases are uncommon and easier to find and fix.

Stackoverflow dev survey shows that the average US dev is 28.7 (down from 31.6 in 2015) with an average of 10 years of experience despite 58% having less than 5 years of experience.

That means that on average, you have a very young team. Further, the vast majority of teams most likely do not have ANYONE with more than 5 years behind them. It's not surprising that such things aren't recognized for the disaster-in-the-making that they are.

Web technologies have settled down and stabilized dramatically over the past 3 years. I suspect that as more web devs gain more experience, we'll see this continue as rashness is replaced with a more conservative approach.

Re: Why Is Front-End Development So Unstable?

#316

Post by Clubber »

unclebucknasty wrote: post #242
bonesss wrote: post #206

Earlier quoted context omitted.

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

About 17 years ago, I wrote a GUI-based code generator that allows me to generate the boilerplate JDBC cruft from SQL statements, with several options for common scenarios. The code it generates is extensible and provides helpers for extending. To this day, I haven't found anything (including ORMs, Spring support, etc.) easier to use, more flexible, or more sensible.

I recently wrote one for C# / MSSQL. I've been using EF on side projects, but work was concerned with it, so I just wrote a CRUD sproc / Entity / Repository / Service / DTO generator. Connect to a database and select the tables you want to build for, and done. 5 layers of abstraction in under a second. It gets me to about 95% of what I need and I custom build the special circumstance stuff from the generated objects. It creates the "if exists / drop" stuff, exception handling and comments w/ dates in the sprocs that reference the objects in C#, and vice versa, what table was referenced, proper [Key] and [MaxLength] attributes, etc. Puts them in their proper folders for git too. It does exactly what I would have done had I done it manually.

Works great with no ORM abstraction and it was fun to write.

Re: Why Is Front-End Development So Unstable?

#317

Post by jhall1468 »

gkya wrote: post #297
collyw wrote: post #295

Earlier quoted context omitted.

> You are being very rude with that statement. If you want to write a blog by all means do so. I have written a handful of blog posts but I don't have the time / motivation to do that in my spare time on a regular basis. I think its silly to assume that all software engineers want to and are good at writing blog posts. Could you explain what is rude about that? > you owe to the community a blog or something similar D…

I'm not going to answer the second part, but for the rudeness, you are being rude because you reduce blogging about one's experiences w/ programming and related stuff to self marketing.

Nobody owes you anything. He gets to have whatever perspective he wants and it's not rude because you disagree with it. You need to take a step back and pretend for a moment that your perspective isn't the only one.

Re: Why Is Front-End Development So Unstable?

#318

Post by vram22 »

dhruvarora013 wrote: post #26

I'd actually say that its less about instability and more about rapid experimentation. There's two main catalysts - the youth of single page web apps and the openness of the modern web. The complexity of your everyday website is increasing as they move from static sites to web apps. The pressure to be as responsive and fluid as a mobile app is high, and that requires solutions for data management and synchronicity. T…

>The pressure to be as responsive and fluid as a mobile app is high, and that requires solutions for data management and synchronicity.

Can you explain what you mean by that? Is it related to mobile apps supporting notifications, as one point?

Re: Why Is Front-End Development So Unstable?

#319

Post by vram22 »

dhruvarora013 wrote: post #26

I'd actually say that its less about instability and more about rapid experimentation. There's two main catalysts - the youth of single page web apps and the openness of the modern web. The complexity of your everyday website is increasing as they move from static sites to web apps. The pressure to be as responsive and fluid as a mobile app is high, and that requires solutions for data management and synchronicity. T…

>The pressure to be as responsive and fluid as a mobile app is high, and that requires solutions for data management and synchronicity.

Can you explain what you mean by that? Is it related to mobile apps supporting notifications, as one point. maybe?

Re: Why Is Front-End Development So Unstable?

#320

Post by [deleted] »

lolsal wrote: post #311
Doctor_Fegg wrote: post #212

Earlier quoted context omitted.

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

I could not quite articulate what I was thinking, but you have captured my thoughts very well. I used to be a 'full-stack' developer - back when 'installing' JS libraries meant dropping the file(s) into your `static/js/` directory and running with it. I find frontend technology so chaotic (not complicated, just chaotic) that combined with the rapid improvements of browser/css/html feature support I was left in the du…

[deleted]
Post reply on HN