"Unstable", "Issue", "Problem". The opposite of the front-end world is not something to desire. Change means people are fixing problems and giving away their solutions for free. To desire less change means wishing fewer people gave away their work.
I am ok with that. If more people giving away their work ends up with "left-pad" situation. Also most of git hub repos are crap to be abandoned after couple months.
As in article if people share code to be "ninja", "rockstar" devs that is wrong approach and I don't want that code. Because solution is not honest, not reliable and probably will be dumped as soon as "rockstar" will find another flashy term where he can gain more "ninja" points.
Change is not necessary a good thing. Bad change is worse then no change at all. However, when it comes to programming frameworks, rapid, unstable, change is generally not very desirable. Take a look at the most popular open-source OS/kernel in the world: Linux.
It's a Unix-clone using a monolithic kernel made in a time when Lisp machines existed and microkernels were all the rage. It used ANSI C which, to be fair, was new at the time, but stuck with it, in the face of C99 and C++.
And, as a windowing system, it still uses X11, a system designed in the mid '80s. There has been a very slow migration towards Wayland (which is now already 10 years old).
As it's scripting language it uses bash (1989), which inherits a lot of it's characteristics from the Bourne shell (1977).
Yes, in the case of Linux may be a little bit biased as OS development back than was still more mature than front-end is now, but still, the principle still holds: "slow and steady wins the race".
Because on average, the skill level in the whole webdev community is low. Below that of "a dev with average schooling, and average industry experience"
Webdev has close to no barriers for entry, and is under the strongest influence from the fact that the evaluation of deliverables is not done by another tech professional out of all software development jobs
The combo above makes things that are unheard of in other software development niches possible, like meeting borderline or de-facto frauds running webdev businesses selling "ultrasophisticated" corporate websites on Wordpress to F500 types for few $k USD per hour of dev time, or well entrenched in-house "developers" in tech giants who made it to six digits on technobabling to non-tech managers and copy and paste.
All of this is evidently projecting onto to the tech solutions used in the trade, and the popular image of the webdev development process. And over the time, popular stereotypes are becoming self fulfilling prophesies: Angular - was an okish framework at near 1.0, but marketing messaging made it look like an "enterprise stuff," and their devs eventually turned it into it - purposelessly overengineered monster filled with SOAisms; jQuery - got bad fame for unusable, animation rich websites made by least talented part of the dev community, and this infamity has both sealed its further development, and was responsible for attracting even more unskilled devs into making websites with crawling slow animation;
And like this for few pages, as well as for the notion of webdev world being "unstable." Many people here who are not novices to webdev can probably call few sites that had a "single piece of JS code continuously maintained over 10 years" or more. I myself knew people who were making yandex.ru homepage in nineties, they say that a very sophisticated ajax autocomplete code there was developed and maintained continuously since 2004
Well, I can say that I am just coming out of few years long miserable period of my life that came after I was kicked out of Canada thanks to "LMIA disaster" after spending 6 years of my life securing my future in the country. Right now, I am easily passing under the points system, but nah, after such shameless bait and switch with immigration policy, there is no way I am going back.
Good things, I am out of webdev as an industry, and finally working in a more serious function in an engineering consulting now - something I was aiming at from my teen years, when I was still not in "money over job satisfaction" mode of thinking.
I don't necessarily disagree with you, but I don't think that has to do with FE development in general. Some of the sharpest/smartest devs I know are FE JS guys. Seriously.
On the backend I have seen probably more "low skill" and even "incompetent" Java devs than any other language. Why? My guess is the low barriers to entry (as you say) and the ubiquity. I've also worked with some amazingly sharp Java devs too.
You're definitely right about the "borderline or de-facto frauds running webdev businesses selling 'ultrasophisticated' corporate websites on Wordpress to F500 types for few $k USD per hour of dev time." That's a rough problem and makes legitimate big-time web development bids induce sticker shock.
How does something like regular desktop development have any more barriers? I picked up Python at 14 and that had absolutely no barriers for entry other than installing IDLE on a laptop. If anything, webdev has more barriers for entry because you need a webserver and a backend of some kind.
I would say: 1 loose portfolio of demos without any history of signed off successful projects will still be getting you a decent job in webdev, but for sure not in commercial desktop software industry
I work with elm now for frontend. It has often been criticized for being too conservative and slow paced in its development. But the result is that code is easier to maintain, libraries have a great quality and most of the time there is only one, obvious, way of doing something.
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.
1. By chance, after a long and tiring typescript project, I looked for something else.
2. No, my first functional language was clojure script, which I tried before elm, I liked the concept but just couldn't bare the syntax.
3. Phoenix elixir, I do maintain it. (in fact I'm more of a backend programmer)
4. Now I work mostly with style-element (the alpha, called stylish elephant) which is the only "framework like" library I use. Otherwise I use different utility libraries for date, color manipulation (hsluv which I wrote the elm implementation), data structure manipulation (many in elm-community, like list.extra)... I use way less libraries that I would with JS, and that's good.
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/jboner/2841832
I agree with this. It also doesn't help that frontend code usually has to run on several versions of at 3 different runtimes. With backend code you can freely either stick with an older platform for stability, and adopt a new platform for new features. With frontend you don't have that choice in the same way.
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
Not really - those things exist in native frontend as well but it's more stable than js. Writing GUI is not trivial, people take stuff like data binding/templates/MVC etc. for granted nowadays, go check out early desktop UI libraries like say win32/MFC/winforms/gtk+. Took a long time to get to stuff like WPF, Qt quick, etc.
With browser there were several constraints :
ES5 is extremely error prone and scales very poorly to larger codebases
slow JS VMs
missingt for sane layout like flexbox
1. Got better with npm, we pack, es6 transpilers, typescript/flow and tooling built along the way
2./3. Got solved by finally depricating everything < IE9 (IE in general if you're lucky) and tooling
I'd say angular is relatively stable now and decently productive once you get a hang of their patterns, I've been using it for different frontend projects since early betas, written ionic apps for mobile with it - have very few complaints about the framework, some of the stuff didn't always work along the way (like ahead of time compilation, i18n) but recently (5+) I've had 0 issues with the framework and I'm quite productive with it. I think the alternatives will mature as well and things will settle.
Native frontend on desktop and mobile have in-memory database and sync out of band. Web browser tab is too resource constrained to run a in-memory database, and less secure as well (you don't have root on your iphone so Facebook can restrict your data access patterns, prevent scrapers, prevent mass-delete of all those old posts, etc)
Those things don't remove the sync issues, blocking the UI thread, they just enable a slightly better use experience.
And dealing with asynchronous code is not the only issue in writing frontend code, GUI apps can be really complex beasts, managing that complexity effectively requires tools that didn't exist in js world untill recently.
They kind of do though, the complexity of data sync can now be dealt with entirely separately from the complexity of the app logic itself (which is not true of, say REST architecture)
Related to this is the idea that people believe front-end software development is easy. In reality, it's one of the most challenging, chaotic and difficult parts of the development chain, especially when talking about web development.
> 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.
The only thing in the frontend with a comparable history (that I can think of) is jQuery -- and I still use it today, but it seems many developers frown upon it these days. And it's a library, not a framework.
I used it before then, but could see why a lot wouldn't touch it until well after 2013-2015 or so. Despite following and using pretty early on... it wasn't until 0.8 that a lot of the core issues were really resolved and it stabilized a lot at that point. The ensuing iojs split, joyent handoff, and node org was a lot of turmoil.
Add to that, the fact that NPM is its' own company, and not part of the Node Foundation could be mildly concerning.
Don't get me wrong, I love node/npm but it wasn't really a catalyst until a little later than 2009.
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 .
They really shouldn't. Modern browsers have lots of the selector magic built-in, and frameworks that are very, very small can handle the rest without the spaghetti.
jQuery alone isn't enough because it solves a completely different problem. It doesn't have a built in templating system which means you need a seperate plugin at which point it makes more sense to use Vue or React instead.
> I think more developers should use jquery to prototype an app and move torward a framework when it is needed.
They really shouldn't. With VueJS it's not that difficult to get setup and running with the CLI and components is such a game changer.
Don't get me wrong. I love jQuery, there's nothing better than taking someone else's library and then extending it. Here's an example [0].
However, one thing that I have learned. It's much simpler and easier to develop code in Vue compared to jQuery. It took me a day to develop a wizard exactly the same as [1]. Of which it's now a component which I can drop in anywhere in my codebase (which I do numerous times) and in future Vue projects.
So FuelUX code: 463 LOC vs my Wizard: 180 LOC.
One last thing to leave with. I have a page builder much like Elementor. In jQuery I'm doing a lot with the Dom and it's such a pain in the ass. It's about 20k LOC alone with hundreds of functions.
Today, with Vue. I prototyped a JSX/JSON backed version, where a watcher listens to the store. The UI commits any changes to the store and the watcher re-renders the HTML. I did this with just ~90 LOC.
Completely unbelievable from my perspective and I'm still only a newbie when it comes to Vue, Webpack, Babel, etc.
jQuery/jQuery UI. It was great, but it's time to move on.
Yeah I'm aware. Some guy insulted Varoufakis and I insulted him in turn and dang banned me.
I'd appeal but honestly this place is hostile to any kind of anti-status quo sentiment from the left so I'd just get banned again. This way I just post rarely.
> One last thing to leave with. I have a page builder much like Elementor. In jQuery I'm doing a lot with the Dom and it's such a pain in the ass. It's about 20k LOC alone with hundreds of functions.
> Today, with Vue. I prototyped a JSX/JSON backed version, where a watcher listens to the store. The UI commits any changes to the store and the watcher re-renders the HTML. I did this with just ~90 LOC.
The community with the first decent (open-source or paid) page builder gets my vote. I could use that in so many projects (and tell people "Yes it's WordPress" when the underlying tech is something else).
I was expecting it to be React, with each component having a frontend view and an admin view, and then I'd do server-side-rendering, but happy if it's VueJS...
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.
The difference is that the backend model has been around for 20 years if not more. You're locating lots of old-ish and stable libraries because that's when that stuff was made.
Maybe you don't remember the days of Zope, Subway, Turbogears, Paste, Pylons, Werkzeug etc just within Python, but that happened. React is a relatively young model for the web. Wait 10 years and it'll look the same.
I personally don't feel it's that unstable. Pick a library, stick with it, stop jumping to the next framework and the churn stops. It's part of being a mature dev. Things always look worse to outsiders than they are.
These are some very fair points. React also really does seem to be becoming a "standard" more so than anything I've seen in years. Time will tell of course, but I think you're on to something.
> Pick a library, stick with it, stop jumping to the next framework and the churn stops.
I wish it were that easy. At work, we've picked angular 1, and now there's angular 5, which is a totally different framework (and the migration path only works well if you did everything juuuust right), and no clear policy on how long angular 1 will be maintained.
So either we churn, or we have no idea how long there will be any support.
This is the risk in the authors advice to just pick a monolithic framework.
We’ve been building a React framework. We’ve been careful about how we choose components to use, so there has been very little churn. And because we control the implementation we’ve been able to build things we could never have done with a library like Angular.
They made a fair number of mistakes with Angular.js (1), so the rewrite was a sensible, if painful change for early adopters. Since version 2, the model has remained relatively stable with changes being improvements rather than completely breaking.
The front-end world is rediscovering lessons learned in the days of desktop thick clients from the 90s, if not earlier. I rage far too often that I have to jump through all these hoops to slam out some UI that I could have done in high school with VB6.
Well, then take Qt Designer if you must - automatic layout management to gracefully handle window resize.
The amount of crap you have to go through to make that work properly (and even then it won't work right in all cases) using the common web frameworks is just astounding ...
I'm referring to CSS media queries in HTML/CSS, which don't have a nearly as clean equivalent for applications. Even then, I've done better with React. If I had to build native apps today, I'd look for a React Native adapter for whatever platform or reach for electron first.
> VB6 apps I've ever seen didn't even handle, or enable a window resize properly.
I think the complaint is that GUI builders from the 90s could have been adopted and improved (responsive for one) on the web in the last 20 years. Flash had a GUI builder, animation timeline, etc. ten years ago.
It’s a real stretch to compare a reactive library like vue with vb6. Building uis in vue is a pleasure and you almost entirely avoid ui state bugs since you aren’t directly manipulating the ui controls (dom)
> 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.)
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.
CSS selectors are highly dependent on the structure of your HTML. If you refactor your HTML then you’ll be required to rewrite many of your CSS selectors. None of that is surprising at all, but jQuery makes it hard to abstract the use of CSS selectors away from the rest of your UI code. Compare with Angular2+ where the logical separation of Components and the HTML of the template is rigidly enforced making refactoring and “scaling” considerably easier.
jQuery is library that provides DOM shorthand - it isn’t a true application framework.
>If you refactor your HTML then you’ll be required to rewrite many of your CSS selectors.
I haven't found that to be a major issue. And I don't think the term "refactor" is the best choice here.
jQuery is library that provides DOM shorthand - it isn’t a true application framework.
Of course not. I don't want a third-party application framework. I discovered years ago that they're not worth the extra effort or the technical debt one incurs with them. (At least not to me. I'm not telling anyone what they should think or that they should design their applications like I do.)
My approach for me and the developers on my team is to develop a deep level of understanding of HTML, CSS and JS. Once you have that, the prospect of doing things for yourself that frameworks would otherwise provide does not seem all that daunting. To me, frameworks like React, Angular, etc. don't reduce complexity, they increase it.
And I hasten to note that I realize that many bright, capable people hold a different view , and I'm not saying they're wrong.
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 complexity.
VueJS as much as I love learning this framework, it is complex with webpack, cli, browser plugin, and etc...
So I'm gonna be honest: I don't have much time or patience for "but webpack is complex" complaints. Webpack is complex, sure. It has many moving parts. It is not complicated, and that means its complexity is more or less "remember a few nouns". Each of the parts those nouns encapsulate is simple and obvious with straightforward inputs and outputs. The interactions may not always be so straightforward--but, in practice, they are. I am comfortable asserting that you shouldn't be surprised by anything webpack or gulp or whatever does. If you are, you haven't internalized what you're working on to a sufficient degree. Because it is just. not. that. big. a. deal.
"Just get things done" when the way you're doing so is less clear, less testable, and less reliable is not, to me, the hallmark of a developer I would trust with anything I cared about.
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.
Now evolve that to say React, where your components aren't separated by a DSL from your component code. ;-)
Not to dig on Angular too much, I think it's fine, but I'd much rather use Vue if I was going for small, or React if I'm going for larger interactions/components/applications. Angular does have a lot in the box, but when it takes 4 guys to lift that box, there's a lot less value than 4 smaller boxes.
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 without touching the rest of the logic.
This is possible to do with jQuery too, but the library doesn’t do anything to help you. This is one of the primary complaints levelled at React, too.
> 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 supposed to. Having done it more times than I can possibly count, and ending up with robust code, shipped on time, I can tell you that it's not hard, if you know how to do it.
> Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes,
Which, IMO, makes something simple to understand and dead simple to debug into something painfully, ridiculously complex. And people complain about "jQuery spaghetti code".
>so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic.
You cannot effectively unit test UI code, if by effective, you mean that it can replace manual testing. It can't replace manual testing. Someone will have to click that button under all of the likely scenarios and verify that it works. I'm sure it's not to you, but to me, writing unit tests for UI code would be a massive waste of time.
If someone thinks they can be more productive using JS frameworks, and I don't have any personal financial stake in their productivity, then they should use them. But I don't see web development using a few simple tools like jQuery as difficult or mysterious or time-consuming.
Last year I interviewed a few recent boot camp grads and they all sent me a link to their copy of the same React-based project. When I asked them questions about how things worked, in generic terms, for example, "what do you think makes this picture slide down slightly and expand in size when I mouse over it", they had no clue. I guess it was just a React component they dropped in, following the steps in the tutorial. I'm not faulting those people -- they paid a lot of money and did exactly what they were told they needed to do to land a sweet high-paying programming job. But they're simply of no use to me. I need the one who looks at it and knows right away that it would take about 4 lines of CSS to accomplish, even if they had to consult a CSS reference to find out exactly which properties/values to use.
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.
>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 for production, and leave testing to the testers. They write code designed to run efficiently and be maintainable, not to be more amenable to unit-testing.
This has proven to work extremely well for us. If you need unit testing to ship robust code in a short timeframe, it would be foolish for you to not write the unit tests. But our team culture is such that we don't do things that we don't need to do to be productive and successful, and unit testing is one of those things.
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.
Scale that to a VERY large application. There are lots of applications where class names and even hierarchies get re-used by other teams working on another portion of an application. In practice, CSS blows up, other portions of the app stop working correctly. Yes, you CAN use discipline in order to create good applications with jquery and others.
In the end, I'll take my single state tree (source of truth) and one-way rendering path, and find it much more sane, without weird state and interaction bugs that show up.
>In practice, CSS blows up, other portions of the app stop working correctly.
Perhaps in your practice, tracker1. But not in mine.
That's what everyone seems to be missing here. This is all a bunch of hand waving to me, because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me.
If you need all of this stuff to ship robust, maintainable code, then you would be foolish not to use it. But I would be foolish to use some complex framework that I do not need to ship robust, maintainable code.
I think the facade is starting to crack with many of these JS frameworks. More and more people are writing articles like the OP and saying that this particular emperor has no clothes.
> because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me
Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. Frameworks and modern tools help to take care in these situations.
The application above was around 2007-2008 IIRC... different parts made by different teams, cobbled together. Layers of backend cruft as well. I did help start a new project, that had much more consistent/clean structure. But when you have too many hands in a pie, and no automated testing in place, you wind up with that eventually.
I've been developing web based applications since 1996. I've lived through the eras without the browsers and abilities we have today... the growth of the DOM and the JS language from a few interfaces for forms, to being able to do so very much.
You don't have to use anything to ship your code... but you have to do something to get a few dozen devs working on something cohesive.
>Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare.
I was a rank and file developer on a similar shit show years ago. The main difference was that it was a greenfield project at a startup. The people calling the shots were dead set on using the latest fads -- at the time it was the Rational Unified Process, with all the attendant documentation, and EJBs. I knew that Entity Beans were a monumentally stupid idea when I first read the O'Reilly book about them. And I said so, to anyone who would listen, to no avail. I think the team reached 40 developers at its peak, of which maybe half were totally incompetent. (By my standards.) The schedule slipped rapidly, we were put on mandatory 6 day work weeks, I bailed out, easily finding another job, and eventually the whole project cratered.
I'm not going to argue with your experience, tracker1, but all of my experience tells me that the ability of the developers is the best predictor of the outcome of a software development project. And our profession, unfortunately, is awash with incompetent people. For example, people who have worked for over 5 years as a Java developer, who are unable to write a Hello World program in Java from scratch in a plain text editor, and compile it and run it from the command line.
I came into my example above 5 years in... it was "Enterprise" .Net and not Java, but a lot of the same techniques at play... I hated it all. I'll take today's JS/NPM ecosystem over those days. I rally against ORM, and DI/IOC frameworks to the end, they aren't needed in JS.
That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers.
As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad. I did learn C# from the command line compiler and a book early on, I didn't have VS to hold my hand. I later did learn VS etc, and that was nicer still.
Getting the pieces together with node/js has been difficult, and painful and a slow process even keeping up with node since it was first announced in 2009. It's taken effort. But anything more than a quick demo, I'd rather have it. I'll leave TypeScript/flow and similar alone though, I don't think they bring more than they take most of the time.
>That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers.
I realize I'm outside the mainstream schools of thought. My approach to developing software absolutely depends on having a rare and special kind of developer doing the work. The emphasis is on deep expertise in the core technologies - JS, HTML and CSS -- that will stay around while fads come and go. And quite frankly, my approach does not scale well. It's not that I couldn't keep 40 developers of the caliber I require productive, it's just nigh on impossible for a non-Google-class company to hire that many in one place. (Considering all you've heard about Google's hiring process, imagine how much it costs them to hire a single developer -- even before the first paycheck is cut.)
>As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad.
Maybe you're reversing cause and effect. Maybe your exposure has been so bad because you've never made the effort to learn it from scratch.
When I adopt a technology for use, I go really deep. I'll get a book, start on page 1, and work through it to the end. (Sometimes I might deem the last few chapters skippable.) After a few months I'll re-read parts of it as a refresher. (That has proven super-helpful.)
That's why I think Reactjs and its like are a lot of fuss and bother to do something that I can already do easily with a lot fewer moving parts. And also, if I decide to use React, I, and (perhaps to a slightly lesser extent) my developers, will go deep into it, and that takes a lot of time and effort. So I have to be very judicious in what new shiny thing I go chasing after. I need to see an obvious, significant return on that type of investment. (I don't care about my resume having the latest buzzwords.) And I just don't see it with any of these frameworks.
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.
Having worked with large codebase written in jQuery here are some of my thoughts,
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 = $(<div></div>).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.
That sounds like an issue caused by an indecent debugger to me. I havent had to debug JS, but indeed the browser debuggers can use some sophistication and customisability, IMHO.
JS debuggers are generally very good. The level of interactiveness of JS also puts them ahead of most non-lisp languages.
Debugging async code isn't like debugging other code. Once you cross that async barrier, all stack traces disappear (I understand Google's doing some work on making that better).
In this particular case, debugging is harder because the UI is also holding all the data, so in order to reset to known good data, you have to reset the page itself. One of the biggest benefits to moving to React (or similar) is that you start keeping all that data in a central place.
The fact that you're keeping track of your actual DOM and event handling at all? That's what I got sick of. Going from jQuery to React was a huge breath of fresh air.
I am one of those people. It isn't that I don't understand it's purpose. What I hate is when people like my boss, who haven't read a text book on the subject for 13 years pull Jquery out automatically and force it into everyones face before any actual purpose for doing that is established. It really winds me up.
We can definitely agree on that. I tend to think about what the actual JS needs will be. If it's going to be relatively simple then I can hack it together in lighting speed in jquery and it stays easy to work on. If the complexity is going to be higher or needs to do more than a few fetches or xhr calls, it's time to consider something else like React.
Personally I'd rather use Grape over Sinatra. I also wrote Modern[0] to provide a really nice, functionally-oriented OpenAPI server for Ruby that is very much Not Rails. (Looking at porting it to TypeScript soon to provide a similar-feeling API.)
This 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 ‘celebrity’. I’ve no problem with people being incentivised for good content, but increasingly I feel I see dishonest tactics: self-citation; invented, proprietary terminology (so searching takes you back to the author’s materials), and name-squatting (e.g. ‘Standard.js’)
This is becoming a big problem in JS world, particularly over the last 3 to 4 years. Like the author, I have no problem with people taking credit and being respected, but we as a community are becoming much too centered around people/personality than technology. I've been guilty of this in the past too (love you Pete Hunt ;-) but it's not healthy IMHO.
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.
Man, I couldn't get through it! It seemed like its own kind of hype-y proselytizing and I didn't find its examples spoke to the kind of issues I actually have. Maybe I didn't give it enough of a chance, but I don't know, I had been hearing for years that it's so great and I was really excited to start reading it, and it just didn't speak to me at all. Anyway, YMMV I guess!
It's not a religious text or anything (I suspect that the proselytising tone comes from the fact that at the time it was written, it's recommendations were still a bit controversial, especially in the kind of organisations likely to have these kinds of codebases). If it's not useful to you, then that's that. The point is, other books written ten years ago by people with deep expertise (rather than a hypey blog post by someone who just discovered some principle five minutes ago) probably will be.
This is a different topic than my comment that you replied to but the "ten years ago" thing stuck out to me: I think books (and blog posts!) written very recently by people with deep expertise are likely useful as well. Figuring out which ones those are is the tough part.
No, it was a quip, basically intended to mean "forget about minute to minute popularity and read a book that is well respected by practitioners in the field and has stood up to the test of time". And I didn't mention the authors, it's about content, not personalities.
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?
Ha! I'm not sure how serious this comment is in terms of how you choose to spend your time at work, but a person with that attitude isn't going to last long working for me. I expect them to deliver.
I'm not a tyrant, and I avoid setting hard deadlines as much as reasonably possible, but I do expect concrete evidence of output that delivers customer and/or business value.
Still, in many organisations I think you're right. So much energy is expended on marketing to/currying favour with managers that not much is actually delivered. It's how you end up with 100+ people taking more than 6 months to deliver two pages that allow customers to register for a service (names omitted to protect the guilty).
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.
Yikes! As someone who can't stand being the center of attention and also can't stand talking about themselves (yes I see the irony here), this is terrifying.
I am a software engineer that loves to help others. Nothing to do with self-marketing, at least not intentionally, but a welcomed skill in the team. So the question makes sense to me.
I have tried it a couple of times (I do have a couple of posts on my github pages). I just don't have the time / motivation combination to do it on a regular basis.
I find it quite time consuming writing in a way that makes it clear to others what I am doing. I'll come over to your computer and explain the same concepts in ten minutes that would take me an hour or two to write up and format in a manner that I would want to display publicly.
(I find answering questions on Stack Overflow a lot less time consuming to get a useful point across).
And because you don't have time / motivation everyone that has is a self marketer?
I agree it's silly to expect every developer to have a blog. I strongly disagree with the only motivation for it being self marketing, or it being a somehow unreasonable question if you have one.
I agree there are talkers and there are do-ers, and very few who are good at both. They do exist but they are rare. This is true for many professions, not just programmers.
Sure. Luckily the blogs written by the two categories are fairly easy to tell apart. Even checking if the domain is medium.com or something else is a good first estimate, but to be sure you should look at the content.
I'll come over to your computer and explain the same concepts in ten minutes that would take me an hour or two to write up and format in a manner that I would want to display publicly.
That’s right, but multiplied by the number of people who read it…?
If you ever used any F/OSS software, or made use of a blog post when solving some problem, you owe to the community a blog or something similar. That can be answering SE questions etc. occasionally or an anonymous blog, not contributing knowledge to the community that saves you many years of work every day is outright selfish.
Furhtermore, I don't see what makes self marketing a bad thing given it is of the honest kind. The CV you send to them in order to get the interview is self marketing too, and so are thw clean clothes you wore to that occasion.
I cant count how many times a random blog post has saved me blinking weeks. 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
Do I?
Maybe that should be put in the terms and conditions if that is the case.
I have a decent score on Stack Overflow from answering questions (~379k people reached apparently), is that good enough for you?
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.
> Any why don't you want to answer the second part?
Because I think the answer is obvious. BTW I did not see the Stack Owerflow part, that is the exact kind of compensation for tge greater community I was talking about. Thank you for that.
For the other paragraph, well, that's how I read you comment in its context, and I maintain my interpretation. Maybe I'm misunderstanding.
I answer Stack Overflow out of mainly self interest. I don't have a portfolio of work to show people at job interviews - my work is mainly in house. I realized it isn't that hard to get a decent score on SO if you know something well.
Also because it annoys me seeing things done poorly having worked in enough maintenance programming jobs and worked with crap that could have been done so much better (this is probably a bigger motivation with certain topics).
I don't do it because I feel I owe anyone anything.
It does feel good to contribute somewhat, but that is far from my primary motivation.
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.
No, we don't. The FOSS community operates on the idea that people that want to contribute to it (financially, programming, etc) can do so. Nothing about open source obligates that behavior, outside of certain licenses. Nobody "owes" FOSS anything either, that's up to them.
It is really shocking people can think this way when also making use of hundreds of people's free labour, and when the very existence of most of programming careers are a direct product of OSS innovation. Hopefuly this attitude is not the widespread one.
Those people are volunteering their time. I'm one of them. But that doesn't mean owed something as a result, that's absurd. I made OSS because I wanted to.
I think that this was inevitable given the rise of social media and the Internet. It’s still entirely possible to be a great developer without having a Twitter or Facebook account, but it’s tempting to feel like I’m missing out on information from not subscribing to the latest fight on Twitter.
You're at the right place to work out what started it.
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.
Once the market is large enough, you're going to have some people at the top who excel at marketing. Look at almost any large market, it's not the "best" products that win, it's the best marketers.
Similar boat. I’ve been presenting passion projects to user groups / unconferences for a decade. Now, I wasn’t aware at the time but around 2013 seems like the turning point. I was getting tingles then. I never wanted to be a celebrity but it seems my aptitude has sent the wrong signals to some. I refuse to tow company lines, but acknowledge funding of open work or course. Starting to explore other outlets for sohpistic endeavors eg. live streaming (shameless plug, building an open source platform, search: ispooge live). People subscribe and keep coming back and chatting too, didn’t expect that but it’s pretty cool. I feel it can lead to a good career in some way, involving good natural collaboration. Maybe even money ;).
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]). Most of their names wouldn't be recognized by someone just getting into programming now.
As I've gotten older, I've learned that there's often an inverse correlation between how good a programmer is and how likely you are to have heard of them, because the folks who get good at programming are actually programming and not writing blog articles about programming. Most of the latter are really content marketing, trying to drum up business for consultancies, and so you should treat them as advertisement rather than advice.
People that are actually doing stuff have no time to talk about it, and people that are talking about it are wasting time by not doing it.
So beware of gurus. No one gets that popular without spending a large proportion of their time promoting. In the decade I’ve been programming I’ve never had time to write even one damn article.
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.
It's gone mainstream, and just like the internet going mainstream, it isn't what it used to be. These days I only enjoy the programming I do on the weekend.
It's a problem for other communities, like Python. I read a blog post recently from a well known python dev where he talks about explicitly cultivating "fame" around his open source tools. My experience, as one who has tried to promote my own tools, is that literally nothing good will come of it for the community as a whole. It's a bad practice in my opinion.
What incentives would a someone have to invest a considerable amount of time in releasing and maintaining an open source project if they can't even use that to promote themselves?
Maybe they have a genuine interest in the problem they're addressing, and in solving it. I work on some open source projects that gain little attention from others but have great utility to me, personally.
It's a nice sentiment but that's how you end up with abandoned, low quality projects that no one uses. Or even worse - abandoned, low quality projects that half the Internet relies on.
> It's a nice sentiment but that's how you end up with abandoned, low quality projects that no one uses.
How is it a bad thing that a piece of software that no one uses is abandoned by its developers? Or should i put it like this: how is it bad that no one uses a piece of software that has been abandoned by its developers? Whichever way you prefer to put it.
> Or even worse - abandoned, low quality projects that half the Internet relies on.
It's not my responsibility to make sure that my software is used for things that it is useful for. In fact, I typically use a license where I deny responsibility for fitness for a particular purpose, like MIT or GPL, exactly because it isn't and shouldn't be my problem.
I think this should be accounted for when deciding whether to use open source software in your project. Of course, with Javascript projects I often end up looking at shitty dependencies because some popular library depends on some slightly less popular library which depends on a brain fart someone put on github 10 years ago and never touched since despite stale, open issues. This is a problem with the community's attitude towards dependencies, not with what software I make available for others to use.
Besides, a low quality project that half of the internet relies on doesn't really need any additional promotion or advertisement, does it?
> 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 shutdown. I also heard stories about how ExtJS 4 wasn't backwards compatible. I'm not sure I buy into the author's thesis about the reason for front-end fatigue.
Additionally, there was no initial update path between Angular 1 and Angular 2 until the community cried foul. It's been a while, but after they finally released an Angular 1 to Angular 2 bridge, I read several tutorials and books that discussed the upgrade path but said to absolutely not use it in production. It would kill the performance of your app. That sort of made the value of an Angular 1 to Angular 2 bridge pretty weak. If one were to migrate to Angular 2, it would seem more time efficient to just to start fresh rather than spend time on a wonky bridge between the two frameworks.
At AngularConnect last year I now migration of large applications was a topic and if you are interested I think it should be available online.
Also: angular.js isn't dead, it is just stabilized. Yes, no more features (from Google) but it should be safe to use and also I think they signalled quite clearly that they would be happy to let the community pick it up.
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.
> 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 decisions unassisted. The "senior" developer who is "caught in the avalanche" isn't senior by any reasonable definition of the word.
Development in general, and, it seems, front end web development in particular, is both easy and hard. Somewhere between batteries-included frameworks, blogs, YouTube channels and MOOCs, it's very easy to get from zero to something good looking and more or less functional pretty quickly. 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.
> 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".
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.
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.
well, ever since the proliferation of mobile touch devices (it's been less than a decade) there's been this somewhat perverse history of "mobile-first" really meaning "native-first." tons of mobile websites are still essentially ads for their counterparts in app stores. this is for lots of reasons (mostly to do with financial incentives for both app makers and app stores), but ultimately the web still isn't as good as native. the chaos of the front-end world is a reflection of web developers trying to solve that, rather than those working on operating systems, web browsers, standards, etc.
the other reason is that vue hasn't be around very long ;)
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. There is no standardized way to solve these yet.
When you tie this increasing complexity with the free-form structure of the web (there is no recommended way to build a web app unlike mobile apps or to a lesser extent desktop apps), and then add the growth of JavaScript from a toy language to a full-blown complex ecosystem, you get even fewer established practices.
This is not to say that there will never be best practices but rather that what you're seeing is a language scaling with its needs without having a central dictatorial entity at its helm. You're seeing unprecedented growth and that can easily be confused with chaos and instability.
Programming industry is the only one more fashion-driven than the fashion industry. This is a known issue going back to the dawn time.
The big secret is that for most of us this is "works as intended". We like to program. Imagine being a mountain climber who loves climbing and gets paid (well!) to climb mountains. With real mountains, eventually you get to the top and you have to stop. With programming, the act of climbing the mountain creates more mountain above you. As long as you can find people to pay for it, you can keep climbing.
If you like programming please shoosh so the marks don't get wise.
If you just want to get shit done use Elm-lang and get on with your life.
Nice idea, but some hipster developer at a company we query decided it would be A Good Idea (TM) to switch from using DNS to query their data to a REST API over HTTPS that returns JSON. Normally, this would be a "whatever" type thing, but see, the code I work on is in a critical, real-time path (as a phone call is being made). We were promised that Java client code would be provided, but see, we don't use Java.
Knockout is incredibly lightweight and easy to get into. However, it's not the "in" framework like Angular and kin, so it gets a lot of bad reactions.
The biggest reason for this, I believe, separate to any technical benefits/advantages, is that the "big" and "in" frameworks have a gigantic knowledge-base hosted on the entire internet. Because of the sheer amount of people on that ship, they've all collectively encountered and tried/solved/figured-out a large amount of usages and combinations of the library. What that means is that mediocre and/or "shallow"-knowledged developers can easily leverage that to solve problems they might encounter by copy-pasting solutions. Rather than solving it for themselves.
Now, that doesn't necessarily mean they're not capable of doing it, it simply means that they have to spend more time figuring out the problem and/or learning the framework in order to be able to do so. Most people would rather opt out to doing a quick search, copy-pasting, adapting to their specific context, and moving along to the next problem. So, when they have to deal with something like KO, they know what it's going to entail: Hours of learning, or digging into internals and figuring out the quirks of the framework.
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.
I believe classifying libs/frameworks by number of stars is not enough ; "when" these frameworks got stars, or how many stars they got in the past 6 month, is probably important. Not sure jQuery or angular 1 got many stars lately...
Agreed. The quality of the stars are important. What percentage of people star repo's where they've read the Readme but never used the code or used the code and decided it was bad quality and never unstarred the repo
I built a system for filtering my HN feed and one of the first rules I put in was "no links to sites that have pop-ins" and tedium matched that. (Not like I have an automated way to do that but it is not too hard to add sites like that to a block list.)
> "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.
> How did it happen that junior JavaScript developers feel so insecure about using the standard stuff?
I know a lot of "developers" that are learning frameworks and not javascript. When you start in a black box then you look for other black boxes to fill in the gaps you need.
I am not even opposed to that. I strongly believe in never re-inventing (unless its academic) what can be used and has been tested, but when the developers are not javascript developers but react, vue, angular developers. Then you get this gap where the inexperienced are afraid to outside of what others have built.
One has to learn somehow, and reinventing is an important part of that.
Aspiring artists will paint nude figures and flower arrangements and white cubes on draperies, even though these subjects were done to death centuries ago. Junior programmers should feel the same way about doing things that have already been done: someone probably has done it better, but I still have to do it for myself, maybe a few times over to get the hang of what's the point.
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).
FWIW, the GitHub age isn't entirely accurate because both React and Vue had major rewrites and the current default branch doesn't hold the entire development history. Vue's first public release was Feb of 2014 and React is just celebrating its 5th birthday.
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 can be incrementally introduced into a codebase without radical rewrites.
These lessons are largely ignored in the open source community, where everyone will gladly tell you how your tech is all wrong. This is actually really easy to avoid. Just focus on solving the problems you have and only adopt technology that is relevant to you.
It's also much easier to adopt if you have a lot of people who aren't familiar with React or even SPAs in general. Templates feel more familiar to them than JSX. And if you're building something complex enough to need it, Vuex is a hell of a lot simpler to learn than Redux. In general, you don't have to know anything about functional programming to use Vue and it's core libraries, and that can be pretty nice if your team isn't familiar with it.
I will say that Vue feels like an evolution like a cousin to Angular 1, without trying to do so much in the box. I still prefer React, but can see the appeal. Similarly, I can see the appeal of WebComponents.
I think the appeal of Vue is that it's "Angular done correct" and "Angular without the bloat you never use". The core concept of Angular was never bad, it's just that it had tons of pitfalls and bugs and it wanted to be everything at the same time, not just the view-layer.
This offers a good explanation for why the most popular options are generally the ones that developers choose, but not why the thing that is currently popular shifts as fast as it does.
Why did React take the limelight while Angular fell out of favor? What caused that shift in what is popular?
My personal experience with this was that Angular 2 was announced, which was completely non backwards compatible. So there were a bunch of people that
1) Needed to rewrite their code
2) Distrusted Angular to be stable
React had a philosophy of small reusable components and incremental upgrade. This is a particularly attractive idea for people experiencing the above. I think this is probably part of the shift in popularity.
This problem is way deeper than web front ends. There were/are dozens of frameworks for Windows and Unix front ends too, before browsers were invented. Every year or two some new tool became popular which made all the previous ones obsolete.
Not really. On Unix it was Motif vs OpenLook. On Windows it was MFC vs OWL. On Mac it was PowerPlant vs MacApp. And that was it really, and you could have stuck with one for over a decade and never been short of work.
I think I'd add to this comment that you can't solve a lot of these problems with more code because in the browser code size is a very significant factor. On the desktop, or even on mobile, code size isn't very important. So we can have big libraries that do a lot of work.
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. As JSON, accessed via many HTTP endpoints with a limited set of verbs (GET/PUT/POST/DELETE)
4. As Javascript objects, accessed via (a different set of) method calls and attributes
5. As HTML tags, accessed via the DOM API
6. As pixels, styled by CSS.
--
Each time you translate from one layer to the next, there's a nasty impedance mismatch. This, in turn, attracts "magic": ORMs (DB<->Object); Angular Resources (REST<->JS Object); templating engines (JS Object<->DOM); etc. Each of these translation layers shares two characteristics:
(A) It is "magic": It abuses the semantics of one layer (eg DB model objects) in an attempt to interface with another (eg SQL).
(B) It's a terribly leaky abstraction.
This means that (a) every translation layer is prone to unintuitive failures, and (b) every advanced user of it needs to know enough to build one themselves. So when the impedance mismatch bites you on the ass, some fraction of users are going to flip the table, swear they could do better, and write their own. Which, of course, can't solve the underlying mismatch, and therefore won't be satisfactory...and so the cycle continues.
Of these nasty transitions, 4/5 are associated with the front end, so the front end gets the rap.
Some good points... but I think you're too pessimistic. Some tiny subset of those fraction of users you mention manage to do something different / better. React is one example. GraphQL is another.
This is a great comment and an amazing insight. What's particularly interesting is that people have attempted to collapse (almost?) every stage of that abstraction hierarchy individually, but none of them have been so successful as to take over the world.
If you were writing a desktop application, you would still have at least three of the layers (serialized data on disk, in-memory data, and the rendering of the objects), but without the dramatic impedance mismatch that the web platform introduces everywhere.
Even on the desktop those three layers involve impedance mismatch and much the same pathologies as
meredydd describes. But I guess three layers of it are better than 6.
It's data. There's a fix format for serializing it. In a lossless way. I don't know what meredydd talks about, there's no mismatch with regards to data.
You can get the same bits in your JS objects as you have in the DB. If not, that means your system is shit.
The problem with frameworks is not the hardship of funneling data up and down the stack.
The problem is that they are optimizing for different things. React optimizes for simplicity of making components. Angular optimizes for providing a full toolkit. And new versions then focus on different things. Server Side Rendering was hot, but now that Google just executes some JS and penalizes large downloads, it's the quest for less bytes on the wire. And tree-shake-ability. And faster time to first paint.
And as browsers and the web changes, so do frameworks. And frameworks try to target, at the same time, both the future, and the very present problems, they try to provide instant gratification, yet try to optimize for the future.
So they usually look half-assed useless pieces of autogenerated-by-MS-Word code all the time. But they work, nevertheless, and power a lot of sites.
> I don't know what meredydd talks about, there's no mismatch with regards to data.
He's talking about different services each having their own preferred way to structure the data. When the layout differs, it cannot simply be a memcpy, and so you get tools to try to ease the tedium of translating one structure's layout into to another. They get the job done most of the time, but run into edge cases that return the developer back to manual tedium. Since developers do not like tedious work, some set out to find a new solution that solves for those edge cases, but they end up leaving many more on the table for the next intrepid developer.
Absolutely. But user/business data? That doesn't matter. When you design the system/stack you pick the right components/tools (right data structures) that can losslessly represent the input/output of the neighboring/adjacent layers. If you want to store 500 byte long fields, then make your DB column 500 byte wide, make sure the backend accepts 500 byte long input, but rejects longer ones, make sure your HTML input has a maxlen=500 (and account for Unicode code point surrogate / multibyte fuckery if applicable)
There's mismatch, of course, but as I've detailed in a sibling comment [0], it's because of difference in purpose and function. A DB is different from a HTML/CSS layout rendering engine, because they have a very (set) of purpose(s), hence different interfaces, and so on. And frameworks are glue between these functions (and the layers as we allocate them to).
> Since developers do not like tedious work, some set out to find a new solution that solves for those edge cases [...]
Yes, perfectly agreed. And since we concentrate on different edge-cases each time, we move from trade-off to trade-off with each new framework, and browsing trend/fad (mobile, tablet, SSR, ultra-tree-shakable-gzip-able, "native" [mobile] compilable, etc).
>You can get the same bits in your JS objects as you have in the DB. If not, that means your system is shit.
I'm not sure what exactly you mean by that. But one thing is absolutely clear. You cannot automatically derive a logical layer from the layer above or below. If you could, there would be no reason to have seperate (logical) layers in the first place.
That's why you get an "impedance mismatch" that has to be bridged by providing some additional information, which often has consequences for performance, debuggabilty and clarity.
Maybe I misunderstand the gist of your comment though.
Maybe I misunderstood the original comment, but the claim was that frameworks are leaky (this I wholeheartedly agree with, and this of course leads to impedance mismatches, after all, pixels on the screen are very different from an SQL DB, but that's why we have the libraries and frameworks, to help us do this translation from one layer to the other, to glue together very different functional components of systems). But then follows it up with talk about data. How JSON and SQL is not a great match. Which is nonsense. You can losslessly represent the same data in both JSON and SQL, you can engineer a perfect system for handling data (you use the same field and column types, lengths, constraints, validation, and so on on both the front- and the backend, and it works), the mismatch is not around data.
The problems are about development trade offs (TypeScript vs JS, small library - few features, complexity - code modularization + chunked lazy loading, optimization - script load time vs development time, and throw in cross browser compatibility; supported features vs complexity - HTTP/2 is nice, and fast, but it's more complex plus you need HTTP1.1 too for old clients, and maybe your API somewhere doesn't support prefetch, or you can't hint your backend to push that to the client, or you can't access the raw request after the framework extracted the request attributes, blablabla), visual communication (current/modern components vs old jQuery sprinkled DOM result in different sites; mobile first, mobile browsers, React Native and Ionic). And these trade offs are different over time. So we get different frameworks over time. And since the change in browsing is very fast, and the effort to start a new framework is small, we get a lot of new unstable frameworks. (And since those frameworks rarely mature really, we get a lot of new ones, because there's not really a "sunk cost" for developers when abandoning the old ones. And it's easy and hip to pick up new skills, and try them out on a new project, etc.)
Also, you can put the "business logic" into one place, and represent it and then push that representation to the client. (GWT, Scala.js, or crude autogenerated forms, point and click website/workflow builders, and so on). Of course, if you want to change the system, then it might be a big pain in the ass to represent something very different than what it was designed for, so these kinds of entombed vertical complexity barriers lead to a metastable state - when you hack something quick on the layer most accessible for you with respect to the task, instead of properly implement it in the whole vertical stack, and these hacks grow and the elegant single source representation of business logic goes out of the window. (Or if you implement everything in one place, you are destined to implement a very powerful - or verbose - DSL to describe the "front end logic" - which should be CSS, and the DB optimization logic
- which should be SQL, and so on.)
Thanks! And funny you should mention that. We're challenging every layer of that heirarchy simultaneously, by building a development environment for the web and making it as integrated as Delphi or VB were on the desktop:
I'd guess that a large portion of new frameworks start simply because everyone who spent enough time with the old one gets sick of the bad or non-existent documentation for edge cases, etc.
Rinse and repeat.
Vue is no better, after reading the rest of the comments. In many ways worse.
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.
I feel like this is a false dichotomy. The choice doesn't have to be roasting squirrels over an open flame/handcrafting PHP pages vs. shiny futurism/Node+React. I have been getting along just fine with Rails, HTML, and a sprinkling of JS for over 10 years.
There is an immense productivity gain to be found in mastering a set of tools. After a while of dogmatic tooling changes you begin to analyze more critically whether the new shiny thing is going to provide any real value. I would argue that for the huge majority of websites, tried and tested tooling is perfectly fine and definitely more robust and supported.
Every tool you introduce is hours of troubleshooting just waiting to happen.
That stuff works fine if your client-side needs are simple, but if you actually want a single-page application, or just an application with a lot of rich JS functionality, it quickly becomes unwieldy.
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 standard foundations with minimal dependencies in between and usually a relatively small but high-value set of libraries.
The benefits of quickly fetching many tiny packages with a package manager or of building on top of all-encompassing frameworks or automation tools are mostly found in two situations, in my experience: getting started quickly (including rapid prototyping exercises) and ongoing development if (and only if) you are staying almost entirely within the bounds of what your chosen technologies already do well.
However, if your requirements start to evolve and diversify in a longer-lasting project, it’s all too easy for those numerous tiny dependencies to become a liability or for that framework or tool you built everything around to become a straitjacket. The relatively short lifetimes of many of these technologies can also become an expensive problem if the community drifts away and the security and compatibility work slows down or stops entirely but your project still depends on them as much as ever.
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.
That was my point, that nothing solves every problem. Monolithic frameworks aren't inherently better than micro libraries, they are just different paths to achieving the same goal. I'm still going to choose micro libraries, because flexibility is more valuable to me than batteries included, which is just as good an argument as batteries included is better than flexibility.
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.
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. Even then, it's only a mild syntax adjustment, not a full on abstraction. React is more of an abstraction, but that comes with functional paradigms that aid in testing, and predictive behaviors.
It really depends though. One can always do just JS/HTML/CSS, and there's something to be said for that. There are lighter tools that are similar to JQuery to smooth over a few of the rough edges. There's really an ala cart of available options.
The problem is that people assume that the PFM (pure fucking magic) will solve it all for them. You can use the cleanest or simplest abstractions, and then still write layers of incomprehensible spaghetti in between.
> 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 change. For the joy of a quicker startup the entire project moves slower.
ORMs have their place, but in the majority of the systems I've seen they were unnecessary, and in broad terms don't provide any particular productivity advantage over using "dumb" SQL-based mapping solutions (a la Dapper [https://github.com/StackExchange/Dapper]), that preserve the power of SQL.
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.
Yeah, very similar--with one primary enhancement: That is, I initially started generating objects-per-table, but found that it was a little limiting for a lot of use-cases I encountered. In particular, it didn't cover joins very well--particularly for queries that fed list views.
So, I expanded into supporting raw SQL SELECT queries that can include joins, which I parse and combine with DB metadata. I then generate the DTOs from there. So, a single DTO can have properties mapped to different tables, which I found much less redundant/limiting than entity-per-table designs.
In addition to the SELECT code, I can use simple checkboxes to also generate INSERT/DELETE/UPDATE/UPSERT code, which map the DTOs back to the underlying tables. It recognizes keys and includes multiple-table writes in a single transaction, etc. In addition to the DTOs and the DAO layer, it can also optionally generate a service interface.
Of the utilities I've written over the years, it is the one that most stands out as having paid me back incalculably.
I’m actually quite fond of SQL, but I disagree that ORMs are not a productivity boost. My experience is in Rails and I think ActiveRecord is a pretty clear win for simple queries. That being said, it is pretty common for less experienced developers to not understand what the ORM is actually doing.
On any project of sufficient size there will be fairly advanced reporting functionality that you generally will not be able to do using ORM so you will end up with a mix of ORM and direct SQL. Also ORM forces you to the lowest common denominator for supported RDBMs I generally do not want to be limited to the SQLite features if I am running PostgreSQL
I did qualify my statement with “for simple queries”.
For more complicated queries, a pattern I have become quite fond of is making database views and then using them as the backing table for an ORM model. In Rails, at least, this gives you the best of both worlds.
In my experience, migration scripts that include modifications to output JSON (as ALTER TABLE statements) are always tracked and programmed to be auto-executed on each version update.
If your application mostly reads from the DB then don't use a ORM. I think ORMs shine when you need to save/update a domain model to a relational DB.
In the CQRS world, a fairly typical choice when using a relational DB is to use a ORM for the write side and raw SQL for the read side.
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.
Have you ever looked into Clojure/ClojureScript? The Clojure ecosystem seems to favor your approach. They embrace the dynamic nature of this kind of programming, are data-oriented, shun ORMs, and generally have solid principles (in my opinion). I found it was well worth working through the (somewhat steep) onboarding curve.
> The Clojure ecosystem seems to favor your approach. They embrace the dynamic nature of this kind of programming, are data-oriented, shun ORMs, and generally have solid principles (in my opinion).
I've recently started my Clojure journey (< 1 month in!), after stumbling across aphyr's very interesting work, and it is being driven entirely by this line of thought. It's taken me a long time, at least a decade, of moving deeper and deeper in to web development to start to really appreciate this perspective but it _feels_ like The Right Way at this point in my career. I'm hoping to, at the very least, be able to take those lessons from Clojure and apply them to the areas of my professional life.
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.
I think a lot of the disconnect can go further away as JSON data types (regardless of actual serialization such as BSON etc) and use are more well supported at the database layer. When I did more C#, and Entity Framework came out, I'd add an XML column to most of my tables, as well as a base class wrapper for my own use... that allowed by to write extension properties that wrapped around XML nodes under the covers. So I could extend with extra properties for things that didn't need to be queried on.
It worked pretty well, of course I actually started doing it because getting schema changes at my workplace was a painful endeavor.
I agree that a lot of the disconnect is induced by developers. It's also part of why I'm a pretty big proponent of a JS UI talking to a service written in JS. It allows for a lot less cognitive adjustment. I remember doing HTML/CSS/JS with Flash/Flex, with .Net, T-SQL, and VB6 in one workplace regularly. I swear every time I had to change from one to another, I was typing the wrong way for a good 15-20 minutes... answering questions at times took 2 minutes just to shake my brain out of whatever I was working in.
I started using less stored procedure code and the DB more as dumb storage, and embraced node pretty early on. Even if it is a "lesser" language, there's something to be said for one language to rule them all. (I do like modern JS though.)
> 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?
I am getting into frontend for a hobby project after spending a few years doing ML and applied stats, and I am currently asking myself this question. If your db interaction is simple, a query is almost as easy to write and maintain as an interaction with an ORM, and is significantly more flexible. If it is something more sophisticated, then your ORM quickly becomes more of a hindrance than a help. What am I missing here? Where is the virtue of an ORM beyond not having to use SQL?
In more static languages, you generally need to convert from the DB types to the Native types to your language. This means a lot of code (more than boilerplate ORMs) and prone to a lot of mistakes.
Some tooling that generates it for you helps a lot in some cases. I can see the appeal, but not in a dynamic language environment where there is less disconnect.
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 Oriented Programming Is An Expensive Disaster Which Must End":
To answer the question "Why Is Front-End Development So Unstable?" the answer is surely, in part, the fact that we refuse to build technologies that are designed to be great front-end technologies.
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.
Angular and React both rely on Javascript and HTML, so you can't describe them as "designed to be great front-end technologies". HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML. It's gotten better over the years, but it is still far from what you would expect if you were trying to build a great programming environment for the front end. As to the limits of HTML, just consider forms. In the last 20 years, there have been very few new form elements added. Compare the form elements available in HTML in 2018 to what VisualBasic 6 had achieved by 1999, or what Netbeans/Swing offered by 2003.
I've been saying the same for years. As long as we are working directly with HTML, we will have these impedance problems.
The component/event model a la Swing et. al. is a far more elegant match for modern Web development, which is now essentially the same as building window-based native applications.
OTOH, HTML was designed for static content delivery. Even if a framework must generate some HTML to remain compatible with browsers, there's no reason we have to work or think in HTML as our central interface model.
Give me a canvas, let me lay out (and style) components, then let me respond to events.
> HTML was designed for document exchange, it is a descendent of SGML. Javascript was initially meant to be a light weight scripting language that allowed dynamic elements in HTML
I always see people saying this, but why does it matter? Electricity was originally piped into homes for lighting, but we don't need an alternate way to power all the electric devices in our home. Unix was designed for computers that are quite different from the ones we use today. And so on.
There have been decades of attempts at databases with a different model than relational and we have seen what happened.
The reality is that a relational model is very well suited for general purpose databases. For specific needs you can use timeseries databases or key/value store, but at this point I seriously doubt that the Nth attempt of killing the relational model will succeed.
And honestly I prefer an enforced relational schema rather than an ungodly mess of schemaless documents.
HTML is a good compromise between procedural / event-based UI frameworks (such Java Swing or Apache Wicket) and visual UI design tools (such as RAD Studio, Apple's Interface Builder or Adobe Dreamweaver) that allow you to implement the most common patterns fairly easily while often making the design of more custom UIs much more difficult.
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.
Even with all the improvement is web technologies in recent past, the browser is still not close to native widget.
And finally the users themselves. No matter how neat you managed to be in the underlying layers, the UI is messy. It can change fast, meaning either massive cost rebuilding an entire application, or breaking those neat layer.
Users also wants everything connected to everything. It does not matter if those connections are explicitely done via ugly spagetthi code or implicitely through clever abstractions, they effectively exist and that's how the requirements, user experience feedback, bugs and testing will be based on.
I think the instability is a byproduct of what it is.
Today we have https://caniuse.com but this sort of tool in one form or another has existed for a long time - I think that mobile, and native mobile have only compounded the problem.
Frameworks, and ecosystems (Node, and what it spawned) are practically a requirement to get things done. But abstracting issues away from front end developers, hiding them behind hacks and fixes only serves to make things worse, and harder.
The foundation of the front end isn't just broken, it is a fuckstorm... and we keep piling more stuff on top of that foundation trying to make it make sense, make it rational. With each layer we add creating new sets of issues that only get worse over time. Then someone "smart" enough to build something a bit better does just that, and we get this: https://xkcd.com/927/
(Note the above links are just my favorite "examples" of these issues not even a good indicator of the real problems therein, everyone has their own grievances)
And this IS the heart of the issue. Any one sane, any one with a high level of skill isn't going to want to work in an environment where they aren't in control where someone can yank the carpet out from under them at any given moment. No one is going to stay long when new browsers and missing packages create more work, or work that has to be re-done to deal with some edge case or issue that literally came out of nowhere. Front end people see those of us working on server side code where we have a HIGH degree of control (orders of magnitude) and realize how bad it is for themselves. Simply put any one who is good invests the time and energy to get OUT of that line of work. Tallent will quickly migrate away from the broken foundation of the front end. This only serves to exacerbate the situation, as a new "smart" person onboards thinking "I can do this better" and being right to some degree.
365 comments
[ 3.6 ms ] story [ 334 ms ] threadAs in article if people share code to be "ninja", "rockstar" devs that is wrong approach and I don't want that code. Because solution is not honest, not reliable and probably will be dumped as soon as "rockstar" will find another flashy term where he can gain more "ninja" points.
It's a Unix-clone using a monolithic kernel made in a time when Lisp machines existed and microkernels were all the rage. It used ANSI C which, to be fair, was new at the time, but stuck with it, in the face of C99 and C++.
And, as a windowing system, it still uses X11, a system designed in the mid '80s. There has been a very slow migration towards Wayland (which is now already 10 years old).
As it's scripting language it uses bash (1989), which inherits a lot of it's characteristics from the Bourne shell (1977).
Yes, in the case of Linux may be a little bit biased as OS development back than was still more mature than front-end is now, but still, the principle still holds: "slow and steady wins the race".
Because on average, the skill level in the whole webdev community is low. Below that of "a dev with average schooling, and average industry experience"
Webdev has close to no barriers for entry, and is under the strongest influence from the fact that the evaluation of deliverables is not done by another tech professional out of all software development jobs
The combo above makes things that are unheard of in other software development niches possible, like meeting borderline or de-facto frauds running webdev businesses selling "ultrasophisticated" corporate websites on Wordpress to F500 types for few $k USD per hour of dev time, or well entrenched in-house "developers" in tech giants who made it to six digits on technobabling to non-tech managers and copy and paste.
All of this is evidently projecting onto to the tech solutions used in the trade, and the popular image of the webdev development process. And over the time, popular stereotypes are becoming self fulfilling prophesies: Angular - was an okish framework at near 1.0, but marketing messaging made it look like an "enterprise stuff," and their devs eventually turned it into it - purposelessly overengineered monster filled with SOAisms; jQuery - got bad fame for unusable, animation rich websites made by least talented part of the dev community, and this infamity has both sealed its further development, and was responsible for attracting even more unskilled devs into making websites with crawling slow animation;
And like this for few pages, as well as for the notion of webdev world being "unstable." Many people here who are not novices to webdev can probably call few sites that had a "single piece of JS code continuously maintained over 10 years" or more. I myself knew people who were making yandex.ru homepage in nineties, they say that a very sophisticated ajax autocomplete code there was developed and maintained continuously since 2004
Good things, I am out of webdev as an industry, and finally working in a more serious function in an engineering consulting now - something I was aiming at from my teen years, when I was still not in "money over job satisfaction" mode of thinking.
On the backend I have seen probably more "low skill" and even "incompetent" Java devs than any other language. Why? My guess is the low barriers to entry (as you say) and the ubiquity. I've also worked with some amazingly sharp Java devs too.
You're definitely right about the "borderline or de-facto frauds running webdev businesses selling 'ultrasophisticated' corporate websites on Wordpress to F500 types for few $k USD per hour of dev time." That's a rough problem and makes legitimate big-time web development bids induce sticker shock.
How does something like regular desktop development have any more barriers? I picked up Python at 14 and that had absolutely no barriers for entry other than installing IDLE on a laptop. If anything, webdev has more barriers for entry because you need a webserver and a backend of some kind.
Will you ever be employed by a "serious company" to make commercial desktop software just for few demos you show from your laptop?
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?
Only have sign in but that is not clickable?
2. No, my first functional language was clojure script, which I tried before elm, I liked the concept but just couldn't bare the syntax.
3. Phoenix elixir, I do maintain it. (in fact I'm more of a backend programmer)
4. Now I work mostly with style-element (the alpha, called stylish elephant) which is the only "framework like" library I use. Otherwise I use different utility libraries for date, color manipulation (hsluv which I wrote the elm implementation), data structure manipulation (many in elm-community, like list.extra)... I use way less libraries that I would with JS, and that's good.
5. No.
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/jboner/2841832
With browser there were several constraints :
ES5 is extremely error prone and scales very poorly to larger codebases
slow JS VMs
missingt for sane layout like flexbox
1. Got better with npm, we pack, es6 transpilers, typescript/flow and tooling built along the way
2./3. Got solved by finally depricating everything < IE9 (IE in general if you're lucky) and tooling
I'd say angular is relatively stable now and decently productive once you get a hang of their patterns, I've been using it for different frontend projects since early betas, written ionic apps for mobile with it - have very few complaints about the framework, some of the stuff didn't always work along the way (like ahead of time compilation, i18n) but recently (5+) I've had 0 issues with the framework and I'm quite productive with it. I think the alternatives will mature as well and things will settle.
And dealing with asynchronous code is not the only issue in writing frontend code, GUI apps can be really complex beasts, managing that complexity effectively requires tools that didn't exist in js world untill recently.
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.
The only thing in the frontend with a comparable history (that I can think of) is jQuery -- and I still use it today, but it seems many developers frown upon it these days. And it's a library, not a framework.
Add to that, the fact that NPM is its' own company, and not part of the Node Foundation could be mildly concerning.
Don't get me wrong, I love node/npm but it wasn't really a catalyst until a little later than 2009.
You can also write decent code using jQuery.
They really shouldn't. With VueJS it's not that difficult to get setup and running with the CLI and components is such a game changer.
Don't get me wrong. I love jQuery, there's nothing better than taking someone else's library and then extending it. Here's an example [0].
However, one thing that I have learned. It's much simpler and easier to develop code in Vue compared to jQuery. It took me a day to develop a wizard exactly the same as [1]. Of which it's now a component which I can drop in anywhere in my codebase (which I do numerous times) and in future Vue projects.
So FuelUX code: 463 LOC vs my Wizard: 180 LOC.
One last thing to leave with. I have a page builder much like Elementor. In jQuery I'm doing a lot with the Dom and it's such a pain in the ass. It's about 20k LOC alone with hundreds of functions.
Today, with Vue. I prototyped a JSX/JSON backed version, where a watcher listens to the store. The UI commits any changes to the store and the watcher re-renders the HTML. I did this with just ~90 LOC.
Completely unbelievable from my perspective and I'm still only a newbie when it comes to Vue, Webpack, Babel, etc.
jQuery/jQuery UI. It was great, but it's time to move on.
[0]: https://github.com/bgrins/spectrum/issues/480#issuecomment-3...
[1]: http://getfuelux.com/javascript.html#wizard
It's not even close. It's depressing how little-known it remains.
You've been shadowbanned since https://news.ycombinator.com/item?id=14982937 (9 months ago) you may want to appeal that decision or create a new account.
I'd appeal but honestly this place is hostile to any kind of anti-status quo sentiment from the left so I'd just get banned again. This way I just post rarely.
> Mithril is my favorite by far.
> It's not even close. It's depressing how little-known it remains.
> Today, with Vue. I prototyped a JSX/JSON backed version, where a watcher listens to the store. The UI commits any changes to the store and the watcher re-renders the HTML. I did this with just ~90 LOC.
The community with the first decent (open-source or paid) page builder gets my vote. I could use that in so many projects (and tell people "Yes it's WordPress" when the underlying tech is something else).
I was expecting it to be React, with each component having a frontend view and an admin view, and then I'd do server-side-rendering, but happy if it's VueJS...
And if you want easy start just open https://codesandbox.io/
a) provide sane API for DOM manipulation b) hide all the ugly bits and bugs of different browsers.
Maybe you don't remember the days of Zope, Subway, Turbogears, Paste, Pylons, Werkzeug etc just within Python, but that happened. React is a relatively young model for the web. Wait 10 years and it'll look the same.
I personally don't feel it's that unstable. Pick a library, stick with it, stop jumping to the next framework and the churn stops. It's part of being a mature dev. Things always look worse to outsiders than they are.
I wish it were that easy. At work, we've picked angular 1, and now there's angular 5, which is a totally different framework (and the migration path only works well if you did everything juuuust right), and no clear policy on how long angular 1 will be maintained.
So either we churn, or we have no idea how long there will be any support.
We’ve been building a React framework. We’ve been careful about how we choose components to use, so there has been very little churn. And because we control the implementation we’ve been able to build things we could never have done with a library like Angular.
You can do a simple web app with straight HTML, and a light web server app pretty simply. Not as simply, but simply enough if you wanted to.
The amount of crap you have to go through to make that work properly (and even then it won't work right in all cases) using the common web frameworks is just astounding ...
I think the complaint is that GUI builders from the 90s could have been adopted and improved (responsive for one) on the web in the last 20 years. Flash had a GUI builder, animation timeline, etc. ten years ago.
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.
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.
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.)
What does that even mean?
jQuery is library that provides DOM shorthand - it isn’t a true application framework.
I haven't found that to be a major issue. And I don't think the term "refactor" is the best choice here.
jQuery is library that provides DOM shorthand - it isn’t a true application framework.
Of course not. I don't want a third-party application framework. I discovered years ago that they're not worth the extra effort or the technical debt one incurs with them. (At least not to me. I'm not telling anyone what they should think or that they should design their applications like I do.)
My approach for me and the developers on my team is to develop a deep level of understanding of HTML, CSS and JS. Once you have that, the prospect of doing things for yourself that frameworks would otherwise provide does not seem all that daunting. To me, frameworks like React, Angular, etc. don't reduce complexity, they increase it.
And I hasten to note that I realize that many bright, capable people hold a different view , and I'm not saying they're wrong.
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?
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 complexity.
VueJS as much as I love learning this framework, it is complex with webpack, cli, browser plugin, and etc...
"Just get things done" when the way you're doing so is less clear, less testable, and less reliable is not, to me, the hallmark of a developer I would trust with anything I cared about.
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.
Not to dig on Angular too much, I think it's fine, but I'd much rather use Vue if I was going for small, or React if I'm going for larger interactions/components/applications. Angular does have a lot in the box, but when it takes 4 guys to lift that box, there's a lot less value than 4 smaller boxes.
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 without touching the rest of the logic.
This is possible to do with jQuery too, but the library doesn’t do anything to help you. This is one of the primary complaints levelled at React, too.
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 supposed to. Having done it more times than I can possibly count, and ending up with robust code, shipped on time, I can tell you that it's not hard, if you know how to do it.
> Frameworks would typically break this into actions or methods that modify state and a UI that updates when the state changes,
Which, IMO, makes something simple to understand and dead simple to debug into something painfully, ridiculously complex. And people complain about "jQuery spaghetti code".
>so that the parts can be effectively unit tested and the UI can be changed without touching the rest of the logic.
You cannot effectively unit test UI code, if by effective, you mean that it can replace manual testing. It can't replace manual testing. Someone will have to click that button under all of the likely scenarios and verify that it works. I'm sure it's not to you, but to me, writing unit tests for UI code would be a massive waste of time.
If someone thinks they can be more productive using JS frameworks, and I don't have any personal financial stake in their productivity, then they should use them. But I don't see web development using a few simple tools like jQuery as difficult or mysterious or time-consuming.
Last year I interviewed a few recent boot camp grads and they all sent me a link to their copy of the same React-based project. When I asked them questions about how things worked, in generic terms, for example, "what do you think makes this picture slide down slightly and expand in size when I mouse over it", they had no clue. I guess it was just a React component they dropped in, following the steps in the tutorial. I'm not faulting those people -- they paid a lot of money and did exactly what they were told they needed to do to land a sweet high-paying programming job. But they're simply of no use to me. I need the one who looks at it and knows right away that it would take about 4 lines of CSS to accomplish, even if they had to consult a CSS reference to find out exactly which properties/values to use.
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 for production, and leave testing to the testers. They write code designed to run efficiently and be maintainable, not to be more amenable to unit-testing.
This has proven to work extremely well for us. If you need unit testing to ship robust code in a short timeframe, it would be foolish for you to not write the unit tests. But our team culture is such that we don't do things that we don't need to do to be productive and successful, and unit testing is one of those things.
That's strictly your opinion, which I do not happen to share.
In the end, I'll take my single state tree (source of truth) and one-way rendering path, and find it much more sane, without weird state and interaction bugs that show up.
I have. Without problems.
>In practice, CSS blows up, other portions of the app stop working correctly.
Perhaps in your practice, tracker1. But not in mine.
That's what everyone seems to be missing here. This is all a bunch of hand waving to me, because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me.
If you need all of this stuff to ship robust, maintainable code, then you would be foolish not to use it. But I would be foolish to use some complex framework that I do not need to ship robust, maintainable code.
I think the facade is starting to crack with many of these JS frameworks. More and more people are writing articles like the OP and saying that this particular emperor has no clothes.
Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. Frameworks and modern tools help to take care in these situations.
The application above was around 2007-2008 IIRC... different parts made by different teams, cobbled together. Layers of backend cruft as well. I did help start a new project, that had much more consistent/clean structure. But when you have too many hands in a pie, and no automated testing in place, you wind up with that eventually.
I've been developing web based applications since 1996. I've lived through the eras without the browsers and abilities we have today... the growth of the DOM and the JS language from a few interfaces for forms, to being able to do so very much.
You don't have to use anything to ship your code... but you have to do something to get a few dozen devs working on something cohesive.
I was a rank and file developer on a similar shit show years ago. The main difference was that it was a greenfield project at a startup. The people calling the shots were dead set on using the latest fads -- at the time it was the Rational Unified Process, with all the attendant documentation, and EJBs. I knew that Entity Beans were a monumentally stupid idea when I first read the O'Reilly book about them. And I said so, to anyone who would listen, to no avail. I think the team reached 40 developers at its peak, of which maybe half were totally incompetent. (By my standards.) The schedule slipped rapidly, we were put on mandatory 6 day work weeks, I bailed out, easily finding another job, and eventually the whole project cratered.
I'm not going to argue with your experience, tracker1, but all of my experience tells me that the ability of the developers is the best predictor of the outcome of a software development project. And our profession, unfortunately, is awash with incompetent people. For example, people who have worked for over 5 years as a Java developer, who are unable to write a Hello World program in Java from scratch in a plain text editor, and compile it and run it from the command line.
That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers.
As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad. I did learn C# from the command line compiler and a book early on, I didn't have VS to hold my hand. I later did learn VS etc, and that was nicer still.
Getting the pieces together with node/js has been difficult, and painful and a slow process even keeping up with node since it was first announced in 2009. It's taken effort. But anything more than a quick demo, I'd rather have it. I'll leave TypeScript/flow and similar alone though, I don't think they bring more than they take most of the time.
I realize I'm outside the mainstream schools of thought. My approach to developing software absolutely depends on having a rare and special kind of developer doing the work. The emphasis is on deep expertise in the core technologies - JS, HTML and CSS -- that will stay around while fads come and go. And quite frankly, my approach does not scale well. It's not that I couldn't keep 40 developers of the caliber I require productive, it's just nigh on impossible for a non-Google-class company to hire that many in one place. (Considering all you've heard about Google's hiring process, imagine how much it costs them to hire a single developer -- even before the first paycheck is cut.)
>As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad.
Maybe you're reversing cause and effect. Maybe your exposure has been so bad because you've never made the effort to learn it from scratch.
When I adopt a technology for use, I go really deep. I'll get a book, start on page 1, and work through it to the end. (Sometimes I might deem the last few chapters skippable.) After a few months I'll re-read parts of it as a refresher. (That has proven super-helpful.)
That's why I think Reactjs and its like are a lot of fuss and bother to do something that I can already do easily with a lot fewer moving parts. And also, if I decide to use React, I, and (perhaps to a slightly lesser extent) my developers, will go deep into it, and that takes a lot of time and effort. So I have to be very judicious in what new shiny thing I go chasing after. I need to see an obvious, significant return on that type of investment. (I don't care about my resume having the latest buzzwords.) And I just don't see it with any of these frameworks.
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.
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 = $(<div></div>).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.
Debugging async code isn't like debugging other code. Once you cross that async barrier, all stack traces disappear (I understand Google's doing some work on making that better).
In this particular case, debugging is harder because the UI is also holding all the data, so in order to reset to known good data, you have to reset the page itself. One of the biggest benefits to moving to React (or similar) is that you start keeping all that data in a central place.
Not me. I call it "writing software."
[0]: https://github.com/modern-project/modern-ruby
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.
> 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 ‘celebrity’. I’ve no problem with people being incentivised for good content, but increasingly I feel I see dishonest tactics: self-citation; invented, proprietary terminology (so searching takes you back to the author’s materials), and name-squatting (e.g. ‘Standard.js’)
This is becoming a big problem in JS world, particularly over the last 3 to 4 years. Like the author, I have no problem with people taking credit and being respected, but we as a community are becoming much too centered around people/personality than technology. I've been guilty of this in the past too (love you Pete Hunt ;-) but it's not healthy IMHO.
Aside: This has made me reconsider being a career programmer.
People started getting paid more for doing this because managers have no idea what programming actually is.
I'm not a tyrant, and I avoid setting hard deadlines as much as reasonably possible, but I do expect concrete evidence of output that delivers customer and/or business value.
Still, in many organisations I think you're right. So much energy is expended on marketing to/currying favour with managers that not much is actually delivered. It's how you end up with 100+ people taking more than 6 months to deliver two pages that allow customers to register for a service (names omitted to protect the guilty).
(I am not usually this cynical before lunchtime, honestly.)
NDAs are there for a reason.
The writing process itself acts as a check if I understand something. Then when people have similar questions/problems in the future I can just link.
The personal value of the blog makes it worth trying at least.
I find it quite time consuming writing in a way that makes it clear to others what I am doing. I'll come over to your computer and explain the same concepts in ten minutes that would take me an hour or two to write up and format in a manner that I would want to display publicly.
(I find answering questions on Stack Overflow a lot less time consuming to get a useful point across).
I agree it's silly to expect every developer to have a blog. I strongly disagree with the only motivation for it being self marketing, or it being a somehow unreasonable question if you have one.
That’s right, but multiplied by the number of people who read it…?
I sure hope that wasn't your answer. Writing a technical blog can also be about sharing what you know or participating in a greater community.
Even a non-technical blog can give an interviewer a better sense of who you are and how well you write.
I think it's a reasonable question. Writing is an important skill for a software person.
In some roles perhaps, but relatively few roles require it. I am currently working in Spanish and my written Spanish is probably like that of a child.
Furhtermore, I don't see what makes self marketing a bad thing given it is of the honest kind. The CV you send to them in order to get the interview is self marketing too, and so are thw clean clothes you wore to that occasion.
I cant count how many times a random blog post has saved me blinking weeks. 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
Do I?
Maybe that should be put in the terms and conditions if that is the case.
I have a decent score on Stack Overflow from answering questions (~379k people reached apparently), is that good enough for you?
Any why don't you want to answer the second part?
Because I think the answer is obvious. BTW I did not see the Stack Owerflow part, that is the exact kind of compensation for tge greater community I was talking about. Thank you for that.
For the other paragraph, well, that's how I read you comment in its context, and I maintain my interpretation. Maybe I'm misunderstanding.
Also because it annoys me seeing things done poorly having worked in enough maintenance programming jobs and worked with crap that could have been done so much better (this is probably a bigger motivation with certain topics).
I don't do it because I feel I owe anyone anything.
It does feel good to contribute somewhat, but that is far from my primary motivation.
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.
I don't know if this is your intention, but your streaming platforms title may be sending different signals than you think: https://www.urbandictionary.com/define.php?term=Spooge
FreshSpooge and iSpooge sound like awesome product names if you're working for MindGeek, tho ;)
As I've gotten older, I've learned that there's often an inverse correlation between how good a programmer is and how likely you are to have heard of them, because the folks who get good at programming are actually programming and not writing blog articles about programming. Most of the latter are really content marketing, trying to drum up business for consultancies, and so you should treat them as advertisement rather than advice.
[1] http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...
not driven by selling anything.
People that are actually doing stuff have no time to talk about it, and people that are talking about it are wasting time by not doing it.
So beware of gurus. No one gets that popular without spending a large proportion of their time promoting. In the decade I’ve been programming I’ve never had time to write even one damn article.
Yep. I second this. The best programmers on my radar are terrible at self-promotion, and are quite content to be terrible at it.
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.
For example: https://github.com/pypa/pipenv/issues/2228
"Made with <3 and (coffee emoji) by Linus Torvalds"
How is it a bad thing that a piece of software that no one uses is abandoned by its developers? Or should i put it like this: how is it bad that no one uses a piece of software that has been abandoned by its developers? Whichever way you prefer to put it.
> Or even worse - abandoned, low quality projects that half the Internet relies on.
It's not my responsibility to make sure that my software is used for things that it is useful for. In fact, I typically use a license where I deny responsibility for fitness for a particular purpose, like MIT or GPL, exactly because it isn't and shouldn't be my problem.
I think this should be accounted for when deciding whether to use open source software in your project. Of course, with Javascript projects I often end up looking at shitty dependencies because some popular library depends on some slightly less popular library which depends on a brain fart someone put on github 10 years ago and never touched since despite stale, open issues. This is a problem with the community's attitude towards dependencies, not with what software I make available for others to use.
Besides, a low quality project that half of the internet relies on doesn't really need any additional promotion or advertisement, does it?
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 shutdown. I also heard stories about how ExtJS 4 wasn't backwards compatible. I'm not sure I buy into the author's thesis about the reason for front-end fatigue.
Additionally, there was no initial update path between Angular 1 and Angular 2 until the community cried foul. It's been a while, but after they finally released an Angular 1 to Angular 2 bridge, I read several tutorials and books that discussed the upgrade path but said to absolutely not use it in production. It would kill the performance of your app. That sort of made the value of an Angular 1 to Angular 2 bridge pretty weak. If one were to migrate to Angular 2, it would seem more time efficient to just to start fresh rather than spend time on a wonky bridge between the two frameworks.
Also: angular.js isn't dead, it is just stabilized. Yes, no more features (from Google) but it should be safe to use and also I think they signalled quite clearly that they would be happy to let the community pick it up.
I really loved Angular 1 precisely because it had everything you needed, more or less, built-in.
> 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 decisions unassisted. The "senior" developer who is "caught in the avalanche" isn't senior by any reasonable definition of the word.
Development in general, and, it seems, front end web development in particular, is both easy and hard. Somewhere between batteries-included frameworks, blogs, YouTube channels and MOOCs, it's very easy to get from zero to something good looking and more or less functional pretty quickly. 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".
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.
the other reason is that vue hasn't be around very long ;)
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. There is no standardized way to solve these yet.
When you tie this increasing complexity with the free-form structure of the web (there is no recommended way to build a web app unlike mobile apps or to a lesser extent desktop apps), and then add the growth of JavaScript from a toy language to a full-blown complex ecosystem, you get even fewer established practices.
This is not to say that there will never be best practices but rather that what you're seeing is a language scaling with its needs without having a central dictatorial entity at its helm. You're seeing unprecedented growth and that can easily be confused with chaos and instability.
Can you explain what you mean by that? Is it related to mobile apps supporting notifications, as one point?
Can you explain what you mean by that? Is it related to mobile apps supporting notifications, as one point. maybe?
The big secret is that for most of us this is "works as intended". We like to program. Imagine being a mountain climber who loves climbing and gets paid (well!) to climb mountains. With real mountains, eventually you get to the top and you have to stop. With programming, the act of climbing the mountain creates more mountain above you. As long as you can find people to pay for it, you can keep climbing.
If you like programming please shoosh so the marks don't get wise.
If you just want to get shit done use Elm-lang and get on with your life.
> If you just want to get shit done use Elm-lang and get on with your life.
If this was sarcasm it would make sense but there's little else in the post to suggest that.
Elm is one of the hippest languages right now. It also depends on a single maintainer AFAIK, and also has a limited community.
I'd also like to program Elm but suggesting to move to that from React or Angular? I'll leave that to my 10 years younger self.
A better description might be: use whatever you know and try to keep code on the server side as long as possible.
My point about Elm isn't that it's the silver bullet, rather that it's a tool that makes the meta-game easier.
Sigh.
I've been using Knockout 3.* for the past five years, no issue here.
Edit: Looks like some Angular and React devs have started downvoting :)
The biggest reason for this, I believe, separate to any technical benefits/advantages, is that the "big" and "in" frameworks have a gigantic knowledge-base hosted on the entire internet. Because of the sheer amount of people on that ship, they've all collectively encountered and tried/solved/figured-out a large amount of usages and combinations of the library. What that means is that mediocre and/or "shallow"-knowledged developers can easily leverage that to solve problems they might encounter by copy-pasting solutions. Rather than solving it for themselves.
Now, that doesn't necessarily mean they're not capable of doing it, it simply means that they have to spend more time figuring out the problem and/or learning the framework in order to be able to do so. Most people would rather opt out to doing a quick search, copy-pasting, adapting to their specific context, and moving along to the next problem. So, when they have to deal with something like KO, they know what it's going to entail: Hours of learning, or digging into internals and figuring out the quirks of the framework.
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.
> "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.
I know a lot of "developers" that are learning frameworks and not javascript. When you start in a black box then you look for other black boxes to fill in the gaps you need.
I am not even opposed to that. I strongly believe in never re-inventing (unless its academic) what can be used and has been tested, but when the developers are not javascript developers but react, vue, angular developers. Then you get this gap where the inexperienced are afraid to outside of what others have built.
Aspiring artists will paint nude figures and flower arrangements and white cubes on draperies, even though these subjects were done to death centuries ago. Junior programmers should feel the same way about doing things that have already been done: someone probably has done it better, but I still have to do it for myself, maybe a few times over to get the hang of what's the point.
Because job postings don't say "Wanted: Junior developer with standard stuff JavaScript experience."
“Forking” vs “renaming a project and creating a new repo” sounds an awful lot like the same thing to me anyways.
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 can be incrementally introduced into a codebase without radical rewrites.
These lessons are largely ignored in the open source community, where everyone will gladly tell you how your tech is all wrong. This is actually really easy to avoid. Just focus on solving the problems you have and only adopt technology that is relevant to you.
I much prefer the more holistic approach to development that Vue.js provides over React.
And we did spend a year working with React, so it's not just something we did off the cuff.
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
Why did React take the limelight while Angular fell out of favor? What caused that shift in what is popular?
1) Needed to rewrite their code
2) Distrusted Angular to be stable
React had a philosophy of small reusable components and incremental upgrade. This is a particularly attractive idea for people experiencing the above. I think this is probably part of the shift in popularity.
https://www.reddit.com/r/programming/comments/8n00k2/why_is_...
I think this is the same as the HN user 'jerf', but am not certain.
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. As JSON, accessed via many HTTP endpoints with a limited set of verbs (GET/PUT/POST/DELETE)
4. As Javascript objects, accessed via (a different set of) method calls and attributes
5. As HTML tags, accessed via the DOM API
6. As pixels, styled by CSS.
--
Each time you translate from one layer to the next, there's a nasty impedance mismatch. This, in turn, attracts "magic": ORMs (DB<->Object); Angular Resources (REST<->JS Object); templating engines (JS Object<->DOM); etc. Each of these translation layers shares two characteristics:
(A) It is "magic": It abuses the semantics of one layer (eg DB model objects) in an attempt to interface with another (eg SQL).
(B) It's a terribly leaky abstraction.
This means that (a) every translation layer is prone to unintuitive failures, and (b) every advanced user of it needs to know enough to build one themselves. So when the impedance mismatch bites you on the ass, some fraction of users are going to flip the table, swear they could do better, and write their own. Which, of course, can't solve the underlying mismatch, and therefore won't be satisfactory...and so the cycle continues.
Of these nasty transitions, 4/5 are associated with the front end, so the front end gets the rap.
(I gave a lightning talk at PyCon two weeks ago, about exactly this - stacking this up against the "Zen of Python" and talking about some of the ways we avoid this in Anvil: https://anvil.works/blog/pycon18-making-the-web-more-pythoni...)
If you were writing a desktop application, you would still have at least three of the layers (serialized data on disk, in-memory data, and the rendering of the objects), but without the dramatic impedance mismatch that the web platform introduces everywhere.
You can get the same bits in your JS objects as you have in the DB. If not, that means your system is shit.
The problem with frameworks is not the hardship of funneling data up and down the stack.
The problem is that they are optimizing for different things. React optimizes for simplicity of making components. Angular optimizes for providing a full toolkit. And new versions then focus on different things. Server Side Rendering was hot, but now that Google just executes some JS and penalizes large downloads, it's the quest for less bytes on the wire. And tree-shake-ability. And faster time to first paint.
And as browsers and the web changes, so do frameworks. And frameworks try to target, at the same time, both the future, and the very present problems, they try to provide instant gratification, yet try to optimize for the future.
So they usually look half-assed useless pieces of autogenerated-by-MS-Word code all the time. But they work, nevertheless, and power a lot of sites.
He's talking about different services each having their own preferred way to structure the data. When the layout differs, it cannot simply be a memcpy, and so you get tools to try to ease the tedium of translating one structure's layout into to another. They get the job done most of the time, but run into edge cases that return the developer back to manual tedium. Since developers do not like tedious work, some set out to find a new solution that solves for those edge cases, but they end up leaving many more on the table for the next intrepid developer.
Absolutely. But user/business data? That doesn't matter. When you design the system/stack you pick the right components/tools (right data structures) that can losslessly represent the input/output of the neighboring/adjacent layers. If you want to store 500 byte long fields, then make your DB column 500 byte wide, make sure the backend accepts 500 byte long input, but rejects longer ones, make sure your HTML input has a maxlen=500 (and account for Unicode code point surrogate / multibyte fuckery if applicable)
There's mismatch, of course, but as I've detailed in a sibling comment [0], it's because of difference in purpose and function. A DB is different from a HTML/CSS layout rendering engine, because they have a very (set) of purpose(s), hence different interfaces, and so on. And frameworks are glue between these functions (and the layers as we allocate them to).
> Since developers do not like tedious work, some set out to find a new solution that solves for those edge cases [...]
Yes, perfectly agreed. And since we concentrate on different edge-cases each time, we move from trade-off to trade-off with each new framework, and browsing trend/fad (mobile, tablet, SSR, ultra-tree-shakable-gzip-able, "native" [mobile] compilable, etc).
[0] https://news.ycombinator.com/item?id=17209305
I'm not sure what exactly you mean by that. But one thing is absolutely clear. You cannot automatically derive a logical layer from the layer above or below. If you could, there would be no reason to have seperate (logical) layers in the first place.
That's why you get an "impedance mismatch" that has to be bridged by providing some additional information, which often has consequences for performance, debuggabilty and clarity.
Maybe I misunderstand the gist of your comment though.
The problems are about development trade offs (TypeScript vs JS, small library - few features, complexity - code modularization + chunked lazy loading, optimization - script load time vs development time, and throw in cross browser compatibility; supported features vs complexity - HTTP/2 is nice, and fast, but it's more complex plus you need HTTP1.1 too for old clients, and maybe your API somewhere doesn't support prefetch, or you can't hint your backend to push that to the client, or you can't access the raw request after the framework extracted the request attributes, blablabla), visual communication (current/modern components vs old jQuery sprinkled DOM result in different sites; mobile first, mobile browsers, React Native and Ionic). And these trade offs are different over time. So we get different frameworks over time. And since the change in browsing is very fast, and the effort to start a new framework is small, we get a lot of new unstable frameworks. (And since those frameworks rarely mature really, we get a lot of new ones, because there's not really a "sunk cost" for developers when abandoning the old ones. And it's easy and hip to pick up new skills, and try them out on a new project, etc.)
Also, you can put the "business logic" into one place, and represent it and then push that representation to the client. (GWT, Scala.js, or crude autogenerated forms, point and click website/workflow builders, and so on). Of course, if you want to change the system, then it might be a big pain in the ass to represent something very different than what it was designed for, so these kinds of entombed vertical complexity barriers lead to a metastable state - when you hack something quick on the layer most accessible for you with respect to the task, instead of properly implement it in the whole vertical stack, and these hacks grow and the elegant single source representation of business logic goes out of the window. (Or if you implement everything in one place, you are destined to implement a very powerful - or verbose - DSL to describe the "front end logic" - which should be CSS, and the DB optimization logic - which should be SQL, and so on.)
https://anvil.works
I'd guess that a large portion of new frameworks start simply because everyone who spent enough time with the old one gets sick of the bad or non-existent documentation for edge cases, etc.
Rinse and repeat.
Vue is no better, after reading the rest of the comments. In many ways worse.
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.
Every tool you introduce is hours of troubleshooting just waiting to happen.
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 standard foundations with minimal dependencies in between and usually a relatively small but high-value set of libraries.
The benefits of quickly fetching many tiny packages with a package manager or of building on top of all-encompassing frameworks or automation tools are mostly found in two situations, in my experience: getting started quickly (including rapid prototyping exercises) and ongoing development if (and only if) you are staying almost entirely within the bounds of what your chosen technologies already do well.
However, if your requirements start to evolve and diversify in a longer-lasting project, it’s all too easy for those numerous tiny dependencies to become a liability or for that framework or tool you built everything around to become a straitjacket. The relatively short lifetimes of many of these technologies can also become an expensive problem if the community drifts away and the security and compatibility work slows down or stops entirely but your project still depends on them as much as ever.
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.
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. Even then, it's only a mild syntax adjustment, not a full on abstraction. React is more of an abstraction, but that comes with functional paradigms that aid in testing, and predictive behaviors.
It really depends though. One can always do just JS/HTML/CSS, and there's something to be said for that. There are lighter tools that are similar to JQuery to smooth over a few of the rough edges. There's really an ala cart of available options.
The problem is that people assume that the PFM (pure fucking magic) will solve it all for them. You can use the cleanest or simplest abstractions, and then still write layers of incomprehensible spaghetti in between.
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 change. For the joy of a quicker startup the entire project moves slower.
ORMs have their place, but in the majority of the systems I've seen they were unnecessary, and in broad terms don't provide any particular productivity advantage over using "dumb" SQL-based mapping solutions (a la Dapper [https://github.com/StackExchange/Dapper]), that preserve the power of SQL.
To this day, I haven't found anything (including ORMs, Spring support, etc.) easier to use, more flexible, or more sensible.
If I were to write it today, I'd be more conscious of limiting dependencies and generally designing with open-sourcing in mind.
Works great with no ORM abstraction and it was fun to write.
So, I expanded into supporting raw SQL SELECT queries that can include joins, which I parse and combine with DB metadata. I then generate the DTOs from there. So, a single DTO can have properties mapped to different tables, which I found much less redundant/limiting than entity-per-table designs.
In addition to the SELECT code, I can use simple checkboxes to also generate INSERT/DELETE/UPDATE/UPSERT code, which map the DTOs back to the underlying tables. It recognizes keys and includes multiple-table writes in a single transaction, etc. In addition to the DTOs and the DAO layer, it can also optionally generate a service interface.
Of the utilities I've written over the years, it is the one that most stands out as having paid me back incalculably.
For more complicated queries, a pattern I have become quite fond of is making database views and then using them as the backing table for an ORM model. In Rails, at least, this gives you the best of both worlds.
It implies an architecture model where you put the business logic and type safety in the RDBMS.
It reduces the number of layers for a lot of functionalities.
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.
I've recently started my Clojure journey (< 1 month in!), after stumbling across aphyr's very interesting work, and it is being driven entirely by this line of thought. It's taken me a long time, at least a decade, of moving deeper and deeper in to web development to start to really appreciate this perspective but it _feels_ like The Right Way at this point in my career. I'm hoping to, at the very least, be able to take those lessons from Clojure and apply them to the areas of my professional life.
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.
It worked pretty well, of course I actually started doing it because getting schema changes at my workplace was a painful endeavor.
I agree that a lot of the disconnect is induced by developers. It's also part of why I'm a pretty big proponent of a JS UI talking to a service written in JS. It allows for a lot less cognitive adjustment. I remember doing HTML/CSS/JS with Flash/Flex, with .Net, T-SQL, and VB6 in one workplace regularly. I swear every time I had to change from one to another, I was typing the wrong way for a good 15-20 minutes... answering questions at times took 2 minutes just to shake my brain out of whatever I was working in.
I started using less stored procedure code and the DB more as dumb storage, and embraced node pretty early on. Even if it is a "lesser" language, there's something to be said for one language to rule them all. (I do like modern JS though.)
I am getting into frontend for a hobby project after spending a few years doing ML and applied stats, and I am currently asking myself this question. If your db interaction is simple, a query is almost as easy to write and maintain as an interaction with an ORM, and is significantly more flexible. If it is something more sophisticated, then your ORM quickly becomes more of a hindrance than a help. What am I missing here? Where is the virtue of an ORM beyond not having to use SQL?
Some tooling that generates it for you helps a lot in some cases. I can see the appeal, but not in a dynamic language environment where there is less disconnect.
I've written about these issues many times before.
Regarding the problem with objects, I wrote "Object Oriented Programming Is An Expensive Disaster Which Must End":
http://www.smashcompany.com/technology/object-oriented-progr...
Regarding the problems of HTML, I wrote "The problem with HTML":
http://www.smashcompany.com/technology/the-problem-with-html
To answer the question "Why Is Front-End Development So Unstable?" the answer is surely, in part, the fact that we refuse to build technologies that are designed to be great front-end technologies.
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.
The component/event model a la Swing et. al. is a far more elegant match for modern Web development, which is now essentially the same as building window-based native applications.
OTOH, HTML was designed for static content delivery. Even if a framework must generate some HTML to remain compatible with browsers, there's no reason we have to work or think in HTML as our central interface model.
Give me a canvas, let me lay out (and style) components, then let me respond to events.
I always see people saying this, but why does it matter? Electricity was originally piped into homes for lighting, but we don't need an alternate way to power all the electric devices in our home. Unix was designed for computers that are quite different from the ones we use today. And so on.
http://www.smashcompany.com/technology/the-problem-with-html
HTML is a good compromise between procedural / event-based UI frameworks (such Java Swing or Apache Wicket) and visual UI design tools (such as RAD Studio, Apple's Interface Builder or Adobe Dreamweaver) that allow you to implement the most common patterns fairly easily while often making the design of more custom UIs much more difficult.
Even with all the improvement is web technologies in recent past, the browser is still not close to native widget.
And finally the users themselves. No matter how neat you managed to be in the underlying layers, the UI is messy. It can change fast, meaning either massive cost rebuilding an entire application, or breaking those neat layer.
Users also wants everything connected to everything. It does not matter if those connections are explicitely done via ugly spagetthi code or implicitely through clever abstractions, they effectively exist and that's how the requirements, user experience feedback, bugs and testing will be based on.
Today we have https://caniuse.com but this sort of tool in one form or another has existed for a long time - I think that mobile, and native mobile have only compounded the problem.
Frameworks, and ecosystems (Node, and what it spawned) are practically a requirement to get things done. But abstracting issues away from front end developers, hiding them behind hacks and fixes only serves to make things worse, and harder.
The foundation of the front end isn't just broken, it is a fuckstorm... and we keep piling more stuff on top of that foundation trying to make it make sense, make it rational. With each layer we add creating new sets of issues that only get worse over time. Then someone "smart" enough to build something a bit better does just that, and we get this: https://xkcd.com/927/
The reality is that the fish stinks from the head and in this case, blame google, apple, MS, and Firefox - https://medium.com/@dmitriid/ok-w3c-and-whatwg-dont-die-but-...
Javascript isn't much better https://ariya.io/2014/05/the-curious-case-of-javascript-nan ---
(Note the above links are just my favorite "examples" of these issues not even a good indicator of the real problems therein, everyone has their own grievances)
And this IS the heart of the issue. Any one sane, any one with a high level of skill isn't going to want to work in an environment where they aren't in control where someone can yank the carpet out from under them at any given moment. No one is going to stay long when new browsers and missing packages create more work, or work that has to be re-done to deal with some edge case or issue that literally came out of nowhere. Front end people see those of us working on server side code where we have a HIGH degree of control (orders of magnitude) and realize how bad it is for themselves. Simply put any one who is good invests the time and energy to get OUT of that line of work. Tallent will quickly migrate away from the broken foundation of the front end. This only serves to exacerbate the situation, as a new "smart" person onboards thinking "I can do this better" and being right to some degree.