[HN Gopher] I can only think that modern front end development h...
___________________________________________________________________
I can only think that modern front end development has failed
Author : gls2ro
Score : 410 points
Date : 2021-04-04 13:28 UTC (9 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| zerubeus wrote:
| Thank god I quit frontEnd, the story was like this:
|
| - 2010: dude look this new thing "angularjs" a
| model/controller(vue?)/STAR*, the $scope dude it's crazy,
| something dynamically changes in the $scope and HOPP it appears
| instantly in the page :D
|
| Few years fast-forward, have a watcher in a model that changes
| something in another model, unpredictable changes down/up, random
| mutations...duhh da heck?? We were good sending HTML from the
| server missing those days...
|
| - 2014: dude look this new thing, it is called "React" and you
| know what?, forget about the state up/down, down/up and allover
| the place, the state is ONE DIRECTION with React, and it is
| backed by Facebook bro.
|
| -(me) Oh yeah? Ok what about the 3 years I spent battling with
| AngularJS?
|
| - Don't bother bro Google is dropping active development and
| maintenance of AngularJS, it is either you switch or use their
| beta Angular 2.
|
| -(me) No, thanks I'll go for React.
|
| - Dudeeee look it is Redux, you dispatch an action, and it takes
| care of updating the state, and you know what, you can combine it
| with Redux-thunk to avoid race conditions.
|
| -(me) Wait wuuuut? Race conditions in the front? Feels like it is
| becoming a game engine bro da heeeeck...
|
| - Brooowww, look dat new baby, VueJs :D
|
| -(me) wait wuuuut? Don't tell me Facebook is letting down active
| development of React.
|
| - No bro it's just another cool front lib it is really dope, and
| it's only the V(vue) part of the front taking care of reactively
| updating the DOM.
|
| -(me) ok but what's new?
|
| - Now you can have a DSL addition in HTML cool stuff like 'v-for'
| to dynamically hide/show a DOM element without writing any code.
|
| -(me) wait, wuuuuut, this reminds me of something I've seen
| before, the ng-if AngularJS is coming back with another name? I'm
| loosing my mind broooo.
|
| - Dudee look its Gatsbyjs, generates a cool static site, but you
| have to write React and graphql for it
|
| -(me) ok.
|
| - Dudeeeee look svelte is killing them all.
|
| -(me) ok.
|
| - Dudeeeee this one is an absolute killer, nextjs everything is
| server side rendered, you write your React component you describe
| the data and the server takes care of building the static html
| and send it to the client.
|
| -(me) wuuuut? But that's what we were doing back in 2009?
|
| - 2019 duuuuudeeeeee ...
|
| -(me) STFU I quit.
|
| (and since then, I'm happy cloud solution architect)
| ryanSrich wrote:
| And yet, "performance improvements" are often the excuse for
| making every single site and web app look the exact same. Dull,
| flat, ugly, homogeneous design has sucked all the life out of the
| web. Remember flash? Remember when websites were cool? Where it
| was fun and exciting to go to certain sites simply because of how
| they were designed? Remember the early days of CSS 3
| experimentation?
|
| But but but! Skeuomorphism is slow! We need fast sites. We need
| accessibility! We need to improve our performance!
|
| Now look. The web is both ugly AND slow.
|
| The big question is why? To me, it's all about commoditization
| and making money.
|
| Why spend money on expensive artists, designers and engineers to
| make sites look good If we can band together (big tech) and make
| flat design the norm? Everyone will forget that the web didn't
| used to suck as bad. Instead, we'll absolutely decimate
| performance with loads and loads of ads and nonsense JavaScript.
| We'll hire product managers to track every single interaction
| imaginable so user's experience sucks and we can invade their
| privacy!
|
| Basically big tech ruined the web. They ruined design and
| everyone pretends like this never happened.
| stevenicr wrote:
| I concur with most of the sentiment here- and am happy to push
| much blame to big google, pointing out that if you are not in
| google you basically don't exist on the web - (and for many on
| the planet if you are not in fbook than you are not on the
| internet) - when google says google web vitals, speed all that
| ranks you in the top or you are not in the top and you become
| invisible - it's a thing.
|
| However I think the global move away from desktop computing to
| phones, ipads and cheap chromebooks are the real fun killer for
| great art and design.
|
| I used to love making sites pixel perfect at 1024 - and today
| if we spend a lot of time making fancy desgins - most people
| will never see it, since they are checking it out via phone
| surfing.
|
| This is what I point to for people inquiring about design today
| - basically it's up to the client to provide the design - what
| pictures and text do you want to put on the small screen?
| that's your design.
|
| Even if you put a note on the small screen telling people to
| visit our Hd/Desktop version for more cool effects they would
| enjoy - many (most?) people don't even have a way to access a
| large screen for computing.
|
| Maybe there will be a shift with people casting to TVs and
| 'smart tvs' browsing better and turn the tide - then we'll need
| some kind of 'report back framework' to tell us people can see
| and navigate via the larger view - then we could try to remake
| flash coolness via html video for the big screen - but then we
| wouldn't know how close they are to the TV - so how large would
| navi buttons and pop up text need to be.. meh - back to basic
| plain stuff.
|
| Personally I think we need better zoom-in controls for browsers
| that people can easily use and understand - this could give us
| more flexibility as designers, like the hamburger menu - if you
| can expect people to know how to use it - not holding my breath
| though.
| mitchdoogle wrote:
| This diagnosis needs more precision. What/who, exactly, has
| failed? What needs to be changed, specifically? You look at the
| comments here and you see many different people are taking this
| different ways.
| mathgladiator wrote:
| Yes and no. I both agree and disagree.
|
| For a lot of it, yes, it is a giant mess.
|
| I'll posit the reason modern front-ends are a giant mess has to
| do with the fact that everyone tries to hack, slash, and
| transform the document model into an application model. This
| means they don't want to reload the page, and they then have the
| burden of manipulating the DOM in a very crude way.
|
| This creates a predictable empire building game of building a
| framework to make it easier, and every framework succeed to a
| certain degree. Now, they succeed in a number of great ways, but
| then they run in the abstraction leakage which causes them to
| bend in strange ways. For many applications, that's fine, but as
| the number of applications grow this creates problems for the
| common case. So, quality gets harder to achieve.
|
| Now, the philosophy that I believe is that we just don't think
| simple enough. Most people don't think deeply about this stuff
| (and good thing because we would never get anywhere without
| people running forward making messes), so what do we do?
|
| Well, I think the real answer may not be to fix front-end
| development. Instead, I'm coming to the conclusion that we should
| fix back-end development. Instead of using the tried and true
| work-horse of request response (i.e. HTTP), we need streams (i.e.
| WebSocket). Streams let you pair-bond state, and this is
| exceptionally important.
|
| Ignore the complications of WebSocket for a moment (I don't deny
| there are problems, but they are solvable; just no good common
| solution yet).
|
| What a stream lets you do is pair-bond/entangle objects, and this
| lets you simplify the development model to a great degree such
| that the front-end object is a proxy to the back-end model. This
| entanglement then forces you to contend with two things: (1) how
| do I change the object, (2) how to respond to object changes.
|
| Once you address those two concerns, you can build applications
| fairly easily. Using this framework, we can then see work towards
| understanding why modern web development is so painful.
|
| Since objects don't tell you how they change, you have to
| reconcile that change. This is why things like react have a
| shadow-dom, but you still have to read state from server then
| shred it into components for that to work. It's easy to miss an
| important data point since there is no direct entanglement.
| Ultimately, you have to take an entire object and then mangle it
| into a form that is pretty to the user without disruption because
| the DOM has hidden state (i.e. scroll bars or text selection).
| Classic web avoids so many problems because that disruption is
| built in.
|
| Since failures of the request will happen, you further have to
| deal with partial failures of state changes which is why you
| generally need a thing like Redux to be an immutable state
| container so you can rollback state changes. OR, you need GraphQL
| such that the client only deals with atomic failures. However,
| most people fuck up GraphQL, so you have to have both GraphQL and
| Redux.
|
| Things like svelte are better because it uses language techniques
| to help you shred your data into DOM, but it still suffers.
|
| My claim is that you can simplify front-end development BUT you
| must also simplify the back-end, and I'm doing this over at
| http://www.adama-lang.org/ where I'm solving the problem for
| board games. I claim that board games are a limit point of
| technical complexity for transactional interactions between
| people, and partial failures are catastrophic for the experience.
|
| The way that I'm building a game right now is that I have a
| client which I can connect a giant JavaScript object to the
| server. There is no proxy, just an object. The server will then
| get an update, then update the object and tell you about it via a
| change callback. These change callbacks allow you to synchronize
| the DOM to the object without an intermediary. The DOM callbacks
| can safely read the object.
|
| This lets me use vanillaJS without fear.
|
| When some DOM callback wishes to change the object, then all it
| does is send a message via the stream to the back-end which will
| (1) authenticate it, (2) validate the change, (3) incorporate the
| change, and (4) spit out a data change. Much like a database, the
| UI is a tailer of the log.
|
| The JavaScript library I have is in its infancy since I'm
| balancing my time between the language, the devkit, the client
| library, the distributed system design, the game tools, the
| canvas renderer, and ultimately the first game to launch.... And
| I'm only working on this 2 hours every evening until I retire,
| so... it's going to take time.
| dranka wrote:
| I miss the passive nature of the web. A page got loaded and then
| it was idle. Now I can stare at a page of text with my cpu
| spinning at 100% in the background, it adds nothing extra to my
| experience except for a quiet hum from the CPU fans
| mro_name wrote:
| Not to mention animations. Adding a second's hand to
| https://mro.name/o/testbild.svg makes 25% CPU load on modern
| hardware. Ridiculous. But even more so, that it's often enough
| done anyway.
| iambateman wrote:
| Not so fast. Front end development is in fantastic shape for an
| industry that's 25 years old.
|
| In a quarter century, we've participated in reshaping how
| billions of people spend their free time and get their work done,
| seen the rise of social giants, endured the creation of millions
| of mediocre small business sites, learned to build apps, and
| taught millions to code in the process.
|
| Now, some of our current development paradigms are either
| underdeveloped or outright broken. News websites are a cultural
| disaster. Web app development changes weekly.
|
| This is the natural result of many people trying many things. But
| the web mostly works most of the time. Eventually we will have
| fully baked standards with supervisory committees and enforcement
| and professional certifications and insurance and all the other
| trappings of a fully grown industry. But right now we get to
| enjoy the growth of one of the most exciting industries in
| history, despite it's problems.
|
| Front end development isn't broken, it's teething.
| pnt12 wrote:
| It's an industry with established UX guidelines defined 20
| years ago which are mostly ignored today. Slow, inconsistent
| and confusing interfaces seem to be the norm, not the
| exception.
|
| There were some revolutions, like responsive design, but all
| the rest feels very shallow compared to the bad UX experienced
| in so many applications and websites.
| viburnum wrote:
| It's mostly just ad tech. Sites without ads are usually pretty
| good.
| poisonborz wrote:
| I think every discussion in this topic is just a collection of of
| every commenter's inner question "am I satisfied with the project
| I'm currently working on?".
| scrose wrote:
| I started out working primarily on the front end when React was
| still in its v0 days, and it still amazes me how many options
| there are to build a simple form, how often it's done wrong, and
| how often what could be a 2 hour MVP turns into sprints worth of
| bike-shedding on the tools to use.
|
| I now work pretty much exclusively on backend systems and I've
| never felt better.
| pjmlp wrote:
| That is why I am so happy to have mostly focused on Java and
| .NET and their SSR stacks.
| baron816 wrote:
| If I were to just look at the bookmarks in my browser, I'd get
| the impression too that frameworks are useless. They're all a
| bunch of sites that render pretty static content.
|
| But the app that I work on in my day job (that I don't personally
| use) could not possibly be built without a framework.
|
| td;dr: a lot of things don't need a framework, but they are still
| very necessary in many cases. Likely not ones that regular
| consumers are exposed to though.
| stcredzero wrote:
| I know game developers who lament the passing of Flash. Though
| the runtime had issues with efficiency and power use, the
| programming environment was great for games, in terms of being
| truly write once, run everywhere. Even networking had serious
| quality of life benefits for both devs and users.
|
| The equivalent in Javascript is an order of magnitude worse in
| those regards. It's ridden with compatibility problems,
| everywhere.
| noxer wrote:
| You cant even find a website that passes html validation these
| days.
| 542458 wrote:
| I like valid HTML as much as the next guy and try to always
| write valid HTML myself, but it's not the be-all-end-all: if
| Safari, Chrome and Firefox can parse your site 99% of users are
| happy. No end-user cares if you have charset set on a script
| that doesn't have a src attribute, or that you're technically
| not supposed to put style tags inside noscript tags.
| noxer wrote:
| I know that its not functionally required but after who knows
| haw many years of "html isn't written by humans" why is it
| still not following the rules. I get that humans make errors,
| I get that they are lazy and dont add alt text and all that
| stuff. But software that exists to generate html should
| clearly generate valid html.
| simion314 wrote:
| The problem is that nobody can create anew browser engine
| because you not only need to implement all the standards you
| also need to make your browser work with broken html and work
| in the same way Chrome and Firefox work.
|
| IMO we would need 2 split the document part from the
| application part. Have a set of elements and a document
| format just for blogs and news websites , and more complex
| components and APIs for application websites. Then you could
| have a browser that would be more simple that will be enough
| to browse blogs,forums and news sites and a more complex
| browser for SPA applications.
| BlueTemplar wrote:
| That first part is the Web, while the second part are
| native programs with Internet connection.
| simion314 wrote:
| I think you could have web rich documents with basic
| interactivity and as an option web application that are
| "native app like" , with tons of APIs for
| camera/microphone , bluetooth, canvas, 3d , complex sound
| APIs.
|
| We have to admit that rich web application can be very
| usefull, even during Java or Flash days we known that
| sometimes you need an animation or a simulation on a page
| to better present some content.
|
| Though it makes you think if we had an 100% open source
| Flash, then you could have used it for complex SPA like
| Figma while keeping all the bloat into an optional plugin
| , if the plugin was optional developers would not be
| tempted to use it unless is needed and it it was needed
| they would have use something like Flex (a Flash GUI
| tookit) and not reinvent the wheel constantly.
| BlueTemplar wrote:
| Sure, canvas is appropriate for basic
| animations/simulations.
| Touche wrote:
| Validation has been unimportant for about 20 years. That has
| nothing to do with why websites are bad nowadays.
| noxer wrote:
| No one said its the reason, its just sign of how bad stuff
| is.
| Touche wrote:
| No it's not, validators are extremely outdated. It's not
| "bad" to forget to close the body tag, it actually doesn't
| matter at all.
| noxer wrote:
| "Validators are extremely outdated therefore not
| following HTML specification doesn't matter" :facepalm:
| fctorial wrote:
| Accessibility?
| dvfjsdhgfv wrote:
| If you share the feeling, join the small Internet movement:
| https://cheapskatesguide.org/articles/small-internet.html/
| guscost wrote:
| Counterexample: Figma.
| dxdm wrote:
| Could you elaborate?
|
| I don't like Figma very much, but I think that's because I
| prefer typing code into text files. So, probably not for
| reasons pertinent to this discussions. Anyway, I'm interested
| in why you would consider it good.
| guscost wrote:
| It is efficient enough to make you rethink the limitations of
| JS apps, it is basically glitch-free, and it works remarkably
| well as a full-featured tool for designing screens
| collaboratively and/or working with SVG.
|
| That said, Figma sort of exists in an "app-like" vertical
| when it comes to web frontends. The other big vertical, and
| the one probably being alluded to in this tweet, is
| "magazine-like". Those frontends have a much different goal,
| one that prioritizes responsive design, accessibility,
| progressive enhancement, and so forth. NY Times has been
| among the best in that vertical for a long time.
| meritt wrote:
| Figma is written in C++ and compiled to wasm, and it's amazing,
| you're right.
|
| But that approach represents maybe 0.001% of modern front end
| development. The curent popular path is React/Vue and the
| endless JS toolchains to compile these horrible bloated broken
| apps.
| secondcoming wrote:
| It still surprises me that twitter, one of those high-flying SV
| companies that overpays massively for talent, still has a truly
| terrible UX on low-end hardware. Opening a link brings my
| (admittedly old) iPad to a halt.
| AltruisticGapHN wrote:
| What about advertising on websites has failed us all?
|
| Anyways, ViteJs and Tailwind jit recently are making development
| fun again. Too bad TypeScript still ruins the party.
| alpaca128 wrote:
| I would go a step further and say this often also applies to GUIs
| in general and not just websites. Because too often the problem
| is not the framework, it's the little amount of thought that goes
| into the UI. If someone spent time on it usually it's so it looks
| a bit nicer, actual considerations about workflows and
| expectations of real users seem to be ignored completely.
|
| And then there are user interfaces where the developers actually
| tried to make a difference but stopped somewhere in the middle,
| like with current Firefox versions. Don't get me wrong, I think
| the UI customization feature is fantastic and I love that it now
| supports a large zoom indicator/control in addition to larger
| address bars and tabs - as the first line of support for my
| relatives I appreciate that this is now more visible. But then
| there's that tiny download button/indicator which, for less tech-
| savvy people, is often simply invisible. As much as I dislike the
| huge bar at the bottom that was introduced with Chrome, I have to
| admit it is better out of the box than a tiny blue arrow that
| desperately tries to be more visible than all kinds of website
| animations and ads.
| csbartus wrote:
| I'm designing and developing web sites and apps since 2005.
|
| First with PHP (Wordpress, Laravel, Yii), then with Ruby (Rails,
| Sinatra), now with Javascript (Gulp, Gatsby, Next, React, Lodash,
| Immer, Typescript). I also do / did static sites with Jekyll, or
| my own framework.
|
| Among all Javascript is far the worst experience. In all areas
| like the language, the types, the state, the hooks, blogging
| engine, toolbelt, hosting, packaging, publishing, documenting,
| the community.
|
| The situation is so bad that I quit. It eats my nerves. Instead
| of creating I'm patching and fixing bugs all day.
|
| That's why the web is what is it today. It's Javascript driven,
| and Javascript is totally flawed.
| rabuse wrote:
| It's just so easy to write horribly structured code in JS. It's
| where PHP was years ago, where everything was just slapped
| together, and you just pray for no errors.
| leephillips wrote:
| I am not an expert chef. I can cook pretty well, and my guests
| enjoy my food. But it doesn't compare to what a professional chef
| can do.
|
| I am not an expert abdominal surgeon. If we are in Antarctica and
| your appendix becomes inflamed, I will try to save you by cutting
| it out. But you will probably die.
|
| I am not an expert front-end developer. I make sites for myself,
| for others, and have even been paid for it a few times. But I
| know I am basically an amateur. However, my sites are far, far
| better than almost all sites in the wild, created by teams of
| full-time, professional front-end developers. They work
| identically in all browsers, are fast, easy to navigate, and
| people say they look good. They validate, too, except for a few
| nonstandard htmx attributes.
|
| There is something very strange in the WWW, when a self-taught
| amateur like me can make a site that is better than the New York
| Times'.
| gherkinnn wrote:
| > I make sites for myself, for others, and have even been paid
| for it a few times.
|
| Here you go. You make sites for yourself. My own stuff is
| fucking fast as well.
|
| It gets slow when you have to ward of a thousand idiotic
| requests and implement maybe 10 of those to shut people up.
|
| While in my own world I'd leave it as it is.
|
| Shitty product is primarily the result of shitty culture. It's
| just that FE is visible and atrocious DB calls are not.
| jasonlotito wrote:
| > There is something very strange in the WWW, when a self-
| taught amateur like me can make a site that is better than the
| New York Times
|
| Would love to see something that does everything the NYTimes
| does that is clearly and obviously "better."
| leephillips wrote:
| Easy: take the front page and remove every headline and
| introductory paragraph that, for some reason that boggles my
| mind, is repeated, sometimes more than once, sometimes more
| than twice, on various areas of the enormous page. Now you
| have a page with the same information that is lighter and
| easier to find things on. And less stupid.
|
| Another example: sometimes there is a stock ticker near the
| top of the front page, and the number of digits it displays
| changes as the ticks go by. But they did it wrong, and when
| this happens the entire layout jumps. I learned how not to
| make this kind of mistake near the beginning of my self-
| education in amateur web design.
| mcrittenden wrote:
| I think the core mismatch here is that you are optimizing
| for experience and NYT, as a business, is optimizing for
| revenue. Those two things often do not overlap.
|
| I can virtually guarantee you that NYT has spent thousands
| upon thousands of hours optimizing and multi-variant
| testing their headline display to maximize conversion. In
| other words, if they followed your advice, they would be
| leaving money on the table.
|
| As for your stock ticker display bug, keep in mind that NYT
| likely employs hundreds of developers and dozens of teams
| each owning various pieces of the website. Bugs will make
| it to production, so it's a matter of prioritization. I'd
| be shocked if they weren't already aware of that bug. It's
| probably lower on some specific team's backlog than a bunch
| of stuff that will be more valuable for the company in
| terms of revenue.
| leephillips wrote:
| You are making my point for me: "you are optimizing for
| experience and NYT, as a business, is optimizing for
| revenue." That is simply an attempt to explain away the
| bad experience of reading the _Times_. The explanation is
| probably correct. But by offering explanations for why
| the site is bad, you are implicitly agreeing that it is
| bad.
| mcrittenden wrote:
| I wouldn't call it "bad". I'd say it's not perfect, and
| rightly so, because perfection would be lower ROI than
| some other things their developers could be doing.
| ickelbawd wrote:
| The measure of what is better in all these companies is
| determined internally and generally by the business. So it
| ultimately serves the business and only serves the user
| indirectly---if at all. Obviously you optimize for different
| things---performance, reliability, simplicity perhaps. And the
| business has more stakeholders who want different things, more
| metrics, more integrations with their third-party tools, etc.
| That's not to say your measure of better is wrong. It's
| probably not and I probably agree with you! But it's coming
| from a different place I think.
| leephillips wrote:
| I appreciate your comment. But isn't my conception of quality
| the only one that matters? If a doctor saves money for her
| employer by skipping some expensive test, and my health
| outcome is worse, her employer may be happy, but we don't say
| that she is a good doctor.
| slt2021 wrote:
| here is proper doctor comparison: imagine you are a plastic
| surgeon and patients comes in with stack of cash and
| demands you make a surgery that is not medically necessary
| and is high risk for him - and you do it anyways and then
| the patient leaves happy. if you refuse, the patient would
| just go to the doctor next door and pay him.
| leephillips wrote:
| This is clearly a terrible doctor. Am I wrong? Isn't this
| doctor violating the Hippocratic oath?
| slt2021 wrote:
| plastic surgeons usually perform procedures that are not
| medically necessary, but only improve appearance to boost
| patient's self-esteem (boob job, facelift, butt job, etc)
| leephillips wrote:
| You moved the goalpost. You stipulated high risk in the
| comment I was replying to. And who cares what plastic
| surgeons "usually" do? A doctor who gives boob jobs to
| women who are already "normal" (not to reconstruct after
| a mastectomy, for example) is a scourge who is exploiting
| society's bad attitudes and exploiting his patients. Not
| a good doctor. Or are you suggesting that if a lot of
| people do it, that makes it good?
| rantwasp wrote:
| not saying that you're wrong, but do you have the same
| constraints as the "crappy" websites?
|
| there is definitely an explosion of tooling, frameworks, etc,
| but past some obvious things, IMHO most websites are crippled
| by business people (that will likely not be using the website)
| make all sorts of technical decisions what must go in and how
| it's supposed to work (ads and tracking crap is one of the
| things that jumps up).
| leephillips wrote:
| No, I don't have all the same constraints. For example, I
| would walk away if any of the organizations that I work with
| insisted on tracking visitors. I stopped taking paying
| customers years ago for this and similar reasons. But if a
| site is bad for the reader, it's bad. The developer has
| failed, even if the customer got what it wanted.
| rantwasp wrote:
| i get it and i am in the same boat as you (ie make it
| awesome for the reader), but unfortunately this is not what
| happens in the real world :(
| johnfn wrote:
| It's kind of like saying that you as an amateur chef can out-
| cook the line cook at a cafeteria who prepares a thousand meals
| because your best-prepared meal is better than their offering.
| That actually may be true for that specific case. And sure,
| your site works great when a couple of people look at it. But
| what happens when you direct the entirety of the NYT's traffic
| to it to see how it does?
| leephillips wrote:
| No, not at all. It is more like saying that I make better
| food than almost all restaurants in town. Which of course is
| not true, and that's the point. Because I do make better
| websites than almost any I come across in the wild.
|
| Your question about handling traffic is orthogonal to the
| topic of design. The answer is that any of my sites would do
| better, given the same server architecture, because I
| deliberately limit the amount that needs to be transferred
| for any particular page.
| xyzelement wrote:
| I think their analogy may still hold.
|
| My mom claims her cooking is better than the restaurants
| (arguable) but she's not operating under the constraints of
| cooking at the variety, consistency and speed that my local
| diner does. The diner needs to be able to provide hundreds
| of dishes on short order including on days when the main
| chef is out. So maybe my mom's once-in-a-while pot of
| chilly is great but she couldn't run scale to run a
| profitable diner.
|
| Similarly, sounds like you are hand crafting awesome
| websites on your own whim and schedule. That's awesome - me
| too - and I've done amazing handcrafted HTML/js/css for
| fun.
|
| And then I go to work and manage an organization whose
| front-end experiences are decidedly not hand crafted and I
| feel great about that. Our product helps people navigate
| one of the most important decisions of their life and and
| sacrificing our ability to iterate quickly at the expense
| of hand crafted front-end code would be the wrong call.
| Like my mom's chilly it wouldn't scale.
|
| You'd look at my work product and say "ugh what a badly
| crafted website" and I'll take the criticism but I wouldn't
| change it.
| leephillips wrote:
| I'm not talking about sites that aren't beautiful. I'm
| talking about sites that are user-hostile, annoying, and
| a pain to navigate. And that seems to have become most of
| them.
| [deleted]
| pessimizer wrote:
| Why do you think your mom's chili wouldn't scale? Do you
| have any material reason to think that?
| xyzelement wrote:
| I think non scalability is the default assumption. Why do
| you think it WOULD?
|
| If I stumble into the diner at 3am drink and want a bowl
| of chilly, guarantee positive outcome. At my mom's, not
| so.
| davemp wrote:
| I'm an amateur builder but the work I've done on my house is
| better than most of the work I've seen done by various trades
| on my friend's/family's places.
|
| Quality you get from strangers correlates with how easily the
| average customer can judge the work (food is easy to judge).
| Sometimes things are important enough to be regulated
| (healthcare) otherwise most markets are for lemons.
| ergot_vacation wrote:
| Your sites are better at being tools ordinary human beings can
| use to their own benefit. They are (probably) terrible at
| generating money via ad revenue and tricking people into buying
| subscriptions that are then nearly impossible to cancel.
|
| Making a site to share info and have fun is easy. Nearly anyone
| can do it. Making a site to actively exploit people in the most
| intense way possible while still being legal(ish) takes highly-
| trained experts.
| leephillips wrote:
| Exactly. But I am using the measure of quality that I think
| is relevant. We call a chef good when we like the food, not
| when he finds a way to enrich a fast food chain.
| hyperman1 wrote:
| There is something very apt in your first line: A lot of sites
| suffer from too many cooks in the kitchen.
|
| If every department proves its worth by claiming space on the
| front page, customer experience will be the last concern.
| That's before someone notices how giving content away is not a
| monetization strategy. Then add the siren song of 'only one
| more script' for marketing data,even if nobody has a clue about
| what to do with that data.
| paulryanrogers wrote:
| It's like Million Dollar Homepage in a sense. Every
| stakeholder in the business wants their stuff in there
| somehow. Except we're gravitating toward the million Kilabyte
| Homepage.
| hyperpape wrote:
| I'm bothered by a lot of contemporary web development. Many
| things are implemented using far too much heavy JS code, and user
| experience suffers. I also think a lot of people drastically
| underestimate how much we get out of modern tools.
|
| In a followup tweet[1] and in this thread, antirez says that we
| haven't improved interaction in 20 years.
|
| Let's consider gmail, which is close enough to 20 years old. But
| at the time, it was an example of a very rare and complex app
| build on top of ajax. I don't personally quite remember this, but
| it apparently didn't have rich text editing for a year after it
| was released.
|
| Ask yourself: how long would a competent front-end developer need
| to make a decent 2004 gmail clone using modern front-end tools?
|
| The ideal would be to build more lightweight websites, but
| exploit modern tools where they pay for themselves. While we're
| at it, we can write fast software without premature optimization.
|
| [1] (https://twitter.com/antirez/status/1378274076859502593)
|
| [2] https://en.wikipedia.org/wiki/Gmail_interface#cite_ref-
| RichT...
| simonw wrote:
| From defining the entire approach when it launched, Gmail has
| somehow turned into the single best argument /against/ SPAs. I
| dread opening it, because I know it's going to be slow to load
| and slow to use.
|
| I don't know how it went so wrong. Original Gmail was a
| revelation. Today it's sludge.
| simonw wrote:
| ... I just loaded Gmail on an empty cache and watched the
| Firefox Network pane: it made 304 requests and loaded 29.65MB
| of stuff (9.8MB compressed) - taking 8s to get to "loaded"
| (on a very fast connection) and over two minutes before it
| stopped loading extra pieces.
| rover0 wrote:
| We fail at manual state-management, and the mostly used patterns
| we are using are complex leaky abstractions.
| jevgeni wrote:
| I started going to Awwwards to find what to avoid doing.
| mitchdoogle wrote:
| Interesting take.. I love going to that site because I want to
| see new things that push the limits of the browser. I would
| love the opportunity to build some of the sites that are
| showcased there, just to try new things. I don't think these
| types of sites are "broken" at all. Most of them work very
| nicely in my experience and use clever ways to hide load time
| or other negatives. I wouldn't ever use most of the cutting
| edge ideas in sites I build commercially because the sites I
| build are for a more mainstream audience that probably isn't
| tech savvy, so I keep it to the basics, but the awwwards stuff
| is still very cool to me.
|
| I think the broken stuff the tweet refers to is all the online
| publishers with floating video ads, 50 tracking scripts,
| bloated pages, zero accessibility, etc on a page for a 500 word
| article
| anhanhanh wrote:
| These type of comments always come from people who have zero real
| life experience working in the intersection of code and business.
| pacifika wrote:
| It's been the same problem since the web design should be pixel
| perfect days, instead of print design the web is now in love with
| app design.
|
| The difference now is that there is less good practice. But look
| at gov.uk and you see the difference between good web design that
| doesn't need to be an app or have carousels.
|
| Web development now has the Sharepoint problem: it can do
| everything given enough effort. It's not about what is possible
| but it's about what you want from it.
|
| Before it was flash intro movies now it's a shop front with
| modals and carousels.
| beidve wrote:
| The tweet is too vague so I don't really know what they are
| referring to.
|
| Reddit is slow now because they made what should just be static
| HTML that is updated occasionally into a web app for whatever
| reason.
|
| React is much better than any alternative. I tried using native
| js but you really need all of the things react brings. Now you
| could go back to server-side, but it isn't suitable for web
| applications. There are just too many interactive elements that
| don't work with a HTML push to client and reload on every change
| approach. Server side plus client side is a lot more work and
| hard to maintain.
|
| Still, I really hate front end development.
| CyberRabbi wrote:
| I want to say this is hyperbole but it's actually correct. I
| don't even have JavaScript enabled anymore.
| softwaredoug wrote:
| Has it failed? Or is the current state that people prefer
| "native" apps to this kind of rich interactivity with long lived
| state? And instead the browser is a place that feels like it's
| going to load a somewhat interactive document. The front end work
| here is often seen as grunt work on top of backend services and
| not a discipline in its own right.
|
| So instead the awesome front end dev has switched from making
| something like Slack or VS Code work great in Chrome to building
| it in something like Electron for native experiences.
| defanor wrote:
| It's hard to argue with that short textual message after it took
| me 3 attempts to finally load it. The quote for those who still
| struggle to access it:
|
| > I look at the web today. Not as a programmer, but as a user of
| broken sites that are unable to obey the most basic rules of
| navigation and usability, terribly slow despite the hardware
| progresses. And I can only think that modern frontend development
| has failed.
|
| Though it's probably not exactly a failure if usability,
| accessibility, and/or speed are not primary objectives for most,
| and discussing just that once again probably won't be very useful
| for fixing it.
| taeric wrote:
| I want to agree with this, but I do have reservations.
|
| The competing priorities of anything are hard to balance. Try
| building a physical store sometime. Even a simple garage sale.
| Layout for navigation and perusal is not a trivial problem.
| Especially if you don't have the space to make comfort a
| priority.
|
| To that end, how much is actually broken, versus you notice the
| maintenance costs? Ever looked at public restrooms? Are they
| broken, it just under funded?
| inamiyar wrote:
| This sentiment of "modern web has failed" is echoed often but it
| is always a generalization. Do I want to stab my eyes out every
| time I go to a news site? Probably. But there are good websites
| out there, many of which are "modern." It's not about web as a
| technology or frameworks or even "webdev culture." Some companies
| just decide having a good website isnt worth it.
|
| Sidenote: I also think there might be too many websites in
| general. I always kind of think between Wikipedia and archive.org
| and other information Freedom projects that's all we need. Maybe
| a little IRC as a treat :)
| abetusk wrote:
| In my opinion, it's a question of what you want to optimize for,
| speed of execution/accessibility/responsiveness or speed of
| software development.
|
| The modern web is a stack of abstractions that separates the code
| in what the site is written in from the underlying machine that
| renders it. This stack of abstractions makes it many orders of
| magnitude slower than it theoretically could be to render, but
| makes it many orders of magnitude easier to program. In other
| words, this seems like the age old debate of "interpreted vs.
| compiled" [0].
|
| While the front end ecosystem is sprawling and modern web pages
| are slow and clunky, the barrier to entry, for most people, is at
| an all time low. It's easier now to create a web page that works
| consistently for the vast majority web browsers with minimum
| effort. The render speed and accessibility might suffer, but this
| is always the price of abstraction.
|
| Jonathan Blow has a talk specifically lamenting this point [0].
|
| [0] http://blog.gmarceau.qc.ca/2009/05/speed-size-and-
| dependabil...
|
| [1] https://www.youtube.com/watch?v=oJ4GcZs7y6g
| https://www.youtube.com/watch?v=FvBySbGueww
| https://www.youtube.com/watch?v=URSOH4F3vbU
| https://www.youtube.com/watch?v=MlIZ2Q3Rvc8
| https://www.youtube.com/watch?v=jpk9Q5gCyIY
| https://www.youtube.com/watch?v=xK6YZ3NFjuE
| bit_logic wrote:
| What upsets and concerns me the most is when I see poorly
| developed SPA on really important sites. For example, government
| service application websites. If reddit or nytimes has a bloated,
| intermittently failing SPA site, that's an annoyance. When it's a
| form to apply for unemployment, ACA health care, DMV, or other
| critical services, it's a critical failure. Especially since
| these services are most often used by exactly the population most
| impacted by bloated SPA (they tend to have slow or unreliable
| internet and slow computers, maybe even a cheap android phone is
| all they have).
|
| Such sites should be using minimal or no JS. These aren't meant
| to be pretty interactive sites, they need to be solid bulletproof
| sites so people can get critical services. And I haven't even
| mentioned how SPA sites often lack any accessibility features
| (which is so much easier to implement if sticking to standard
| HTML+CSS and no/minimal JS).
| rabuse wrote:
| I honestly hate SPA's. They're not necessary in almost every
| single use-case, yet everybody is shifting their shit into one.
| slowmovintarget wrote:
| Why SPAs? They're good when you develop capabilities API-
| first. When we build features, we follow an approach of
| making the feature possible (customer support can exercise
| the feature with PostMan or cURL) then making it friendly
| with a UI.
|
| There will be some tweaks and changes to the API to support
| the UI, but it's rarely drastic, and it ensures that every
| single capability we build out can be exercised by some other
| kind of program somewhere.
|
| If you're building components of a larger system (which we
| do), SPAs and web components atop back-end APIs make sense.
| If you're building a one-off fill-out form kind of
| application... No those don't make sense. You don't even need
| JavaScript for those, if you degrade into just HTML + CSS for
| users that have shut off JS.
| renlo wrote:
| It's because frontend devs are taught to use react, so
| suddenly every website unnecessarily becomes a react app. If
| every tutorial and class out there teaches people to use
| hammers (react) then people start using hammers to screw in a
| lightbulb or perform surgery.
| estaseuropano wrote:
| Completely agree. And yet, were there ever better days? In the
| past simply fewer websites were online. I think a bad website
| is better than none.
|
| At the same time the real question is why lots of governments
| wouldn't need to reinvent everything. That is maybe the
| original sin.
| tomc1985 wrote:
| Why do these things even need to be an SPA? What function does
| that serve when the standardized and infinitely more compatible
| form-with-a-bit-of-javascript approach works just as well if
| not better?
|
| I work on one such project and it absolutely drives me nuts --
| it's a rails app, but the customer front-end (which is
| literally just a form to fill out) is a React SPA. There is
| nothing there that couldn't be done with Turbolinks and some
| light JS for validations/popups.
| murm wrote:
| When the only tool you know is a hammer you tend to just go
| around smashing things
| pas wrote:
| Because that's the mainstream, that's what's easy to procure,
| hire for, negotiate with vendors, that's the default, the
| preferred, the future proof, the supported.
|
| And the tech doesn't really matter. I hate React with a
| passion, because Angular is so much more sane - in my
| experience. But it's fine. It's mature, it can be made to
| perform completely well.
|
| The tech doesn't really matter. The people doesn't matter
| either. Even the costs doesn't matter as much as people
| think. What matters is political will, procurement culture,
| so systems and structures. This will influence (and bring)
| all the others in line.
| JohnBooty wrote:
| Depressingly correct.
|
| Variations of "nobody ever got fired for buying IBM",
| repeated forever.
| DaiPlusPlus wrote:
| No-one got fired for writing an SPA, but we did decide
| not to renew the contract for the next major update.
| throwawayboise wrote:
| > the future proof
|
| No, not that.
| polynomial wrote:
| How can a government contractor reasonably justify a price
| tag that's on par with fancy bloated non-government sites,
| for an no nonsense form + js approach?
| toast0 wrote:
| Costs the same as what you would otherwise pay, plus it
| actually works?
| davemp wrote:
| > plus it actually works
|
| That's the problem. Maintenance is big money for
| government contractors.
| vram22 wrote:
| >plus it actually works?
|
| Heh. "That was the most unkindest cut of all."
|
| https://www.google.com/search?q=unkindest+cut+of+all+quot
| e
|
| Also, "the emperor's new clothes".
|
| Both relevant.
| clairity wrote:
| what concerns me more than that is how government sites require
| google and the like (captcha and analytics at the very least),
| giving them opportunity to hoover up all of our sensitive data
| in one convenient place.
| mattwad wrote:
| this isn't just a problem with SPAs. The quickly-built vaccine
| registration site I was using kept giving me 500 errors from
| Heroku.
| chubot wrote:
| Yeah what's weird is that there's is an entire generation of
| developers who think of SPA as the default.
|
| They think that server side is slower because you have to send
| down more data, or you have to wait for the server to generate
| HTML.
|
| Quite the contrary, it's slower to send down 1 MB or 10 MB of
| JavaScript to render a page, than to simply send down a 100 KB
| HTML page. Even if you need some JS also, browsers know how to
| render concurrently with downloads, as long as you provide
| enough HTML.
|
| Rendering HTML on a server side Intel/AMD/whatever CPU is way
| faster than rendering it on a mobile device (and probably more
| efficient too).
|
| Even if it weren't faster and more efficient, it would save
| battery power on the client.
|
| And there is a ton of latency on the client side these days,
| ignoring network issues. There are ways of using the DOM that
| are expensive, and a lot of apps and frameworks seem to tickle
| those pathological cases. These 20-year-old browser codebases
| don't seem to be great workloads for even modern Android or
| iPhone devices.
|
| ---
|
| edit: To be fair, I think what's driving this is that many
| sites have mobile apps and web apps now, and mobile apps are
| prioritized because they have more permissions on the device.
| (This is obvious when you look at what happened to Reddit,
| etc.)
|
| It's indeed a more consistent architecture to do state
| management all on the client. Doing a mix of state on the
| server and state on the client is a recipe for confusion -- now
| you have to synchronize it.
|
| Still there are plenty of apps that are website-only, like the
| government sites people are talking about. Those people appear
| to be copying the slow architecture of the dual mobile+web
| clients and getting a result that's worse.
| ralusek wrote:
| This is the exact opposite of my experience.
|
| When I click on a link, or click to submit something, and I
| realize that it's NOT an SPA, my immediate thought is "this is
| going to be a nightmare."
|
| When I click a button, and it has to make a request to load the
| next set of html, fully replace the page contents, and probably
| submitted a post request that will have issues restoring the
| state of my form if I go back, etc, I feel like I'm on a DMV
| site from the 90s. Navigating something that is meant to
| operate as a cohesive application by instead using a series of
| markup displays is only ever going to be hacky at best. I love
| using SPAs, because they're actually applications, rather than
| snapshotted frames of an application running on a remote
| server.
| shadowgovt wrote:
| At least regarding the US federal government, it was a known
| issue that (a) the government wasn't willing to spend enough to
| hire quality software developers and (b) the government
| bureaucracy lacked a process to determine whether web software
| was "good." Specifically, no effective methods of software
| validation based on modern best practices (the processes they
| used were descended from the validation processes for material
| acquisition, which look extremely different from software
| engineering).
|
| I'm not sure if the problems have been fixed, but they were
| both recognized and a process was put in place to address them
| after the healthcare.gov debacle.
| mmcnl wrote:
| This is a very simplistic characterization of what's happening.
|
| First of all, for all the broken websites there are also a lot
| of websites that are not broken at all. It's also very easy to
| make a broken website using a completely server-side rendered
| website, and that actually happens often enough.
|
| Second, SPA's decouple frontend and backend in a very strict
| way, which can bring enormous organizational benefits. Time-to-
| market is greatly improved, etc.
|
| This whole "frontend vs backend" dialogue is basically white
| noise that completely misses the point. Use SPA or not,
| whatever, in the end it's just a tool to get the job done. Both
| are prone to errors when handled improperly.
|
| A website that got it completely right is the Dutch corona
| dashboard called "Coronadashboard" created by the Dutch
| government: https://coronadashboard.rijksoverheid.nl. It's
| blazingly fast, extremely well-designed, looks great and the
| code is of exceptional quality. Also it's open-source, have a
| look at the code: https://github.com/minvws/nl-covid19-data-
| dashboard/.
|
| The dashboard is completely written in Javascript. I truly
| believe a website with of such high quality would not be
| possible without frameworks such as React or Next.js (or
| whatever other framework and their respective tooling has to
| offer).
|
| Closing note: let's try learn more from the websites that got
| it right than the ones that have failed. It's so easy to be
| critical, it's much harder to give some praise.
| ilaksh wrote:
| It kind of freezes up on my phone. Not intolerable but
| definitely slow.
| mmcnl wrote:
| It loads instantly on my Xr.
| p1mrx wrote:
| SPA = single-page application
| lifeisstillgood wrote:
| I am going to :+1: the UK census site - built on code developed
| by the gov.UK digital service, it has been apparently
| bulletproof at taking 20 million plus individual households
| through a moderately complex survey.
|
| sometimes it can be done right.
|
| And it uses a framework :-)
| JNRowe wrote:
| Yeah, I was impressed enough to fill out the feedback form at
| the end. It is probably the first time I've used a feedback
| form for compliments in my life.
| jonplackett wrote:
| Yeah I was pretty impressed with it too. One thing I liked,
| it does lots of error checking along the way to pick up
| accidental screw ups.
|
| Eg. It says 'what is your date of birth?' And then on the
| next page it says. 'You are X years old. Is that correct?'
| devit wrote:
| Which framework?
| WickyNilliams wrote:
| If my memory serves me right, it's Python/Django. I
| contracted in that department a few years ago.
|
| Edit: Just remembered it's all open source too! Look here
| and search for repos beginning "eq-". Survey runner is the
| app I believe. When I was there the plan was to use that,
| though perhaps they eventually wrote a fresh app. Anyway
| the code should all be there
| https://github.com/ONSdigital?q=Eq&type=&language=&sort=
| uncledave wrote:
| That was notably one of the best web experiences I've
| used recently. Gov.uk is exceptionally good.
| wilsonfiifi wrote:
| Wagtail
| uncledave wrote:
| Yes definitely.
|
| I was surprised recently as I had to fill in a massive form
| based site for UK NHS mental health survey stuff. The site
| appeared as a flat background old style early 2000's sort of
| thing with bits of comic sans in it. I nearly died when I first
| saw it expecting a shit show.
|
| But it turned out to be responsive and fast. It worked
| perfectly from end to end and had little to no JavaScript. It
| was by far the best thing I've used for years. There were over
| 100 page transitions in total. It wasn't an SPA but a classic
| web site with little or no intelligence. Seemed to be backed by
| python.
|
| I want this back.
| the_dice_wizard wrote:
| I've been working over a year as front end dev and my main
| complain is that I feel the whole thing is a bit unstable. How do
| you choose the right tool when it comes to JS? You can go
| vanilla, use jQuery, Angular, React, Vue, Svelte... and that's
| just talking about the big ones. CSS seems a bit more stable with
| BootStrap still having the biggest share and Tailwind coming as a
| strong contender. I'm pretty sure we all thought about JS
| frameworks first when we read 'front end development has failed'.
| But how about UI/UX? We had 4 designers so far at work. One of
| them was really good and left. The others were good designers,
| but not good web designers. Modern design is bloated, sometimes
| not intuitive because we all want good looking things, who cares
| if they aren't as functional. And after all, when you visit a
| website, not as a programmer or a designer, as a consumer, what
| do you want? Speed, usability and content. You don't care about
| animations, parallax effects or if the company used jQuery or
| React. My opinion is that there are use cases for certain
| technologies but sometimes we overdo things.
| tazjin wrote:
| HN seems to be pretty split on this issue. I concur with the
| linked tweet. Using the web beyond very simple pages like HN
| feels like wading through garbage.
|
| Everything is slow, laggy, loads ridiculous amounts of stuff (I
| live in a country where traffic is very expensive at the moment,
| so this becomes more noticeable). Things are also flaky and need
| reloading whenever they get into broken states. The only way I
| use the web now is with uMatrix blocking everything, and then
| whitelisting stuff that pages want to run piecemeal. It's still
| terrible.
|
| The larger a company is, the less usable its web stuff is also.
| Google Chat for example is unusable in very active rooms.
|
| I hope that frameworks like Hotwire make server-side rendering
| "cool" again and that we can get out of this tar pit.
| tffgg wrote:
| Why would you want server side rendering? As a user it's
| painful if you have to wait after each click
| slt2021 wrote:
| is it painful for you to click on HN? I find this website
| rapid fast. Also because you dont have long running JS
| processes the RAM consumption is low and everything feels
| very quick, unlike most SPA garbage
| tffgg wrote:
| Yeah, I kinda wish clicks would respond instantly
| goostavos wrote:
| Your comment made me legit chuckle. Rather than "waiting"
| after each click, we get an instant 'page load', half of
| which can't be interacted with (looking at you, Amazon.com),
| and then a sea of loading spinners -- all under the guise of
| 'not waiting'. I'm not sure which of those I prefer, tbh.
|
| I'm partial to good ol' fashion SSR sites these days, as I do
| most of my casual couch browsing on an old chromebook running
| Ubuntu. The number of heavy-weight SPAs that I just can't run
| on the hardware anymore seemingly climbs by the day. :(
| tazjin wrote:
| There is - by definition - more overhead in client-side
| rendering. Think of it this way: The server needs to first
| serialise data, the client needs to deserialise it, then it
| needs to construct the DOM to update.
|
| The server can just do the first step and things like Hotwire
| can add the dynamic bits you need - all overhead and extra
| processing is now gone.
|
| I can list a lot of websites that don't render client-side
| that are fast, but very few that do which are.
| christophilus wrote:
| To be honest, I think it's browser-specific. I use Brave, and
| everything is snappy. Occasionally, I use someone else's
| computer w/ stock Chrome or stock Safari, and it's a total
| shitshow. Decent ad / tracker blocking makes a massive
| difference. I don't think it's frameworks as much as it's all
| of the other analytics and bloat.
| tazjin wrote:
| Nope, that's not it - I block all of that.
| danjac wrote:
| I built a side project recently using Django/Hotwire. There's
| some JS, sure, but it's used where appropriate (media API stuff
| basically). Lighthouse gives 100% accessibility and best
| practices scores and performance comes in at over 90% on a good
| day, with performance issues mostly fixed with some database
| indexing and caching here and there (it runs on a single
| shoestring Digital Ocean droplet, so it's never going to be
| super fast or scalable without a bigger budget, but for the
| small traffic it gets it's fine). I feel I can reason about how
| it all works in my head, and fix bugs and add features quite
| easily. It was fun to build, and I was able to focus on
| interesting problems.
|
| At the back of my mind is the feeling that somehow I'm doing it
| all wrong, and it should use a proper JS frontend framework
| like React or Vue that communicates with the backend with a
| proper REST API or better yet, GraphQL. I realize it's probably
| not the kind of project I should use to show off on my resume
| and that many will just consider it old school. At the same
| time though it does feel that maybe the industry took a wrong
| turn when it went all-in on SPAs.
| tomwojcik wrote:
| I was thinking about starting Django + Hotwire project myself
| but I'd like to see some examples first. Is your side project
| open sourced?
| danjac wrote:
| Yes: https://github.com/danjac/audiotrails
| mrweasel wrote:
| The reason I'm interested in Hotwire is because the Javascript
| frameworks are confusing. Every new Javascript framework I've
| looked into has been impossible to figure out. There are simply
| to many moving parts for me to be able to figure out where to
| start.
|
| It may be a bad example, but it the latest I've attempted to
| use. It took me maybe an hour to get an Angular project
| started. It somehow managed to install 1000+ dependecies (a few
| of which seems deprecated) and I have no idea what I'm suppose
| to do next.
|
| You get the feeling that frontend development is a stack of
| tools three levels deep and you're not expected to understand
| how or why. It feels unstable. At this point I just avoid
| anything that requires npm.
|
| That being said, I do see very nice project built using these
| tools.
| runawaybottle wrote:
| It's happening for a very particular reason imho. Frameworks
| like React create infinite ways one can structure and compose
| components. What once used to be a <Select> can now become
|
| <DropDown>
|
| And or
|
| <EnhancedDropdown disableEnhance={isEnhanced}>
|
| And or
|
| <MultiSelectWithAutocompleteAndSearchBar
| onlySingleSelectionAllowed={true}>.
|
| Then you can compose all of those together into:
|
| <ThisComponentMakesSenseToOnlyMeDropDown show={isDropdown &&
| !Carousel && showCarousel}
| totallyDifferentData={totallyDifferentData}
| enhanceWith={<EnhancedDropdown>}
| replaceWith={<CarouselWithNoDropDown> >
|
| ^ That's where all the complexity is coming from. I will not
| even attempt to demonstrate my point by adding context and
| global stores into this.
|
| Small bit of bitterness:
|
| Then you make a nice little storybook component, and a jest
| snapshot to show that this is a nice 'testable' component,
| you know, like really dot your I's and cross your T's.
|
| Back to my point:
|
| This is powerful in the purest sense, as it's super flexible,
| but also powerful in a way that can create insane amounts of
| complexity with different mindsets contributing. Not everyone
| sees a regular <DropDown>, some see all kinds of things.
|
| I think a lot of the fragility (perhaps the better word is
| instability) comes from this power (chaotic, out of control
| power). I hope web components at the very least creates a
| standard list of UI components (the browser doesn't even have
| a default modal yet, still rolling with alert(), and if you
| leave it to the wider community to make it, we will end up
| with <AbstractModal>).
| tazjin wrote:
| My honest take is that the frontend development stack focuses
| almost entirely on the developer experience (mostly oriented
| towards shiny things), and the user experience is only a
| secondary effect of that.
|
| That the developer experience also doesn't work is just an
| effect of the real-world, where people will end up using
| stuff outside of the small designated bucket of things that
| somebody attempts to keep compatible with each other.
| ergot_vacation wrote:
| Nothing has "failed" on a technical level. I'm sure if a company
| hired a bunch of highly experienced devs and said "build us the
| fastest, most user-friendly site ever, everything else is
| secondary!" you'd get an amazing site.
|
| You get what you optimize for. User experience is not being
| optimized for. The ability to prey on users via ads, dark
| patterns, info harvesting, tracking and even malware is. This in
| turn happened because people discovered that, mostly, there are
| only two ways to make significant money online: 1. Be the first
| to deliver a revolutionary service everyone loves in just the
| right form for it to catch on. 2. Gather a bunch of users via
| some shiny object and then exploit the hell out of them.
|
| For obvious reasons, #2 caught on, dominated the web, and will
| continue to do so until various regulations slow it down.
| lame88 wrote:
| Plenty of discussion has been had around incentives and I agree
| with all that, but also there's another angle here: aside from
| dark patterns, I think the problems of terrible front-end
| experiences are most prevalent in the middle of the bell curve -
| the front-end products developed by rather mediocre skill levels
| and budgets. Which is usually a pejorative, but thinking of it as
| literally in the middle, not great but not terrible, a wide range
| of skill levels where people are more or less competent at their
| jobs. These are where I start to notice the worst effects of the
| median trying to adopt the technologies and practices that high
| skilled developers at good companies with huge budgets are able
| to utilize effectively, or outright make themselves, especially
| when there is so much churn that being "up to date" with
| technology is like a pipe dream to most people. These median
| teams inherit all the complexity, but due to budget or time
| pressures, etc. aren't able to overcome it effectively to produce
| a product with high quality, and users feel the sluggish
| experience and bloat that comes as a result. This pertains to
| more than UI of course but eventually manifests to users that
| way.
|
| Something feels wrong. The median should be able to inherit the
| benefits of technology produced at the high end without such
| inheriting massive costs.
| runawaybottle wrote:
| The implication is rough, but it is part of the truth (not all
| of the truth). However, I will add that the anointed 'high-
| end', your lifelong long backend devs, devops, data engineers,
| etc are adding to the problem. Backend people taking up the
| frontend hat under the fullstack guise create tons of awful end
| results, and this is even more common because they already
| exist at the company and are given a blanket 'competent' rating
| (in other words, they get a chance to mess with the curve
| before anyone else).
|
| All of this is part of the pervasive problem that your post is
| slightly tainted by (my attitudes are tainted by it as well),
| which is a general disrespect for frontend. No matter, the
| truth of these attitudes will show up in all of our products.
| It's always obvious to me which teams take frontend seriously
| and which don't (the quality is always literally visible).
| gumby wrote:
| I had hoped the end of Flash would have brought this nonsense to
| an end but it seems the bozos just moved on to continue doing
| damage.
| coldtea wrote:
| > _I can only think that modern front end development has failed_
|
| Well, one can just as well say "in-memory stores have failed"
| based on some impossible to meet criteria of their own device...
| vbezhenar wrote:
| I don't think that web is slow, unless you're running seriously
| underpowered computer. That's not the case for me. Web is not as
| fast as it could be. And that's because customer does not want to
| pay for fastest website in the world. It should be fast enough
| and then features matter. You can spend year making your website
| load in 0.1 second while your competitor will implement important
| features and his 2-second loading website will win.
|
| And that's not really about web. It's about software in general.
| Discord launches in 8 seconds. Ventrillo launches in 1 second.
| But people will use Discord, because 8 seconds is not that bad
| and then features matter.
|
| And that's not really about modern software, as old software was
| slow as well. Also it was very buggy. Windows 98 used to BSOD
| here and there, so you had a routine to press "Save" button every
| few minutes and keep few copies just in case. Emacs was expanded
| to "Eight Megabytes And Constantly Swapping".
|
| There's some old software which survived till today and it's now
| wicked fast, because it was made for old hardware. But people
| still prefer to move on to new software, because of features or
| just shiny new design.
| runawaybottle wrote:
| All of that is true until it isn't. Ask all the stock trading
| apps how Robinhood out-UXed them. When the out-user-
| experienceing happens, you pretty much will lose your entire
| business if you don't undertake a paradigm shift. Stay ahead of
| the curve a bit.
| reader_mode wrote:
| I thought robinhood got popular because they marketed the
| shit out of _comission free_ trading for the little guy.
| daniellarusso wrote:
| I think it was more like 'here is a free margin account with
| options enabled and no commission fees' went alot further
| than the UI.
|
| Also, the UX was implicated as the cause of a suicide, so
| that is not good.
| jackson1442 wrote:
| I think it could be argued that Robinhood's UX is a sort of
| feature on its own. Stock trading isn't simple by any means,
| and Robinhood found a way to make it really approachable for
| everyone and that's almost admirable. Everything else about
| their business sucks, but that one piece was truly
| impressive.
| runawaybottle wrote:
| I've echoed this point a few times too. There's a lot of
| apps that can barely figure out a todo-list (every
| glorified note take app/PM software), and here's a company
| that boiled down Derivatives (with a capital D) trading in
| about two or three screens.
|
| It's an absolute masterclass.
| jackson1442 wrote:
| I'm personally impressed by how terrible the other
| trading apps are comparatively. Obviously they have more
| features etc but you'd think Vanguard & co. would try to
| follow in their footsteps.
|
| Vanguard's beta app, Beacon, is a step in the right
| direction, but I can already tell it won't even compete
| with Robinhood's design.
| Retric wrote:
| Most software I use wasn't written from scratch in the last 10
| years. It's _new_ only in that of people are still maintaining
| it, but I don't get to decide what features I want it's an all
| or nothing buffet.
|
| On a new an powerful computer most of the web is dog slow.
| There is no reason most websites should take more than 1/10th
| of a second from click to fully rendered. Anything past that is
| simply wasting my time.
| flohofwoe wrote:
| reddit.com is a slow and flickering mess even on my gaming PC.
| It's the worst example that comes to mind though. But if that
| same PC can run incredibly complex open world games while
| simulating (for instance) an aircraft complete with the cockpit
| and displays driven by emulated onboard computers at 60+ fps,
| it's not too much to ask the same from a webpage that "just"
| needs to do text layout and display a couple of images.
|
| Also: it's considerably faster and cheaper to build a fast
| webpage than to build a slow webpage. I'm quite sure the "new
| Reddit" was _a lot_ more expensive to build than the "old
| Reddit".
| daniellarusso wrote:
| I am curious what the traffic breakdown for reddit is via the
| 'old' subdomain compared to the 'www' subdomain?
|
| Personally I will navigate away from the new site and only
| use the old domain.
| hypermachine wrote:
| The hardest thing is making things pretty and flexible while
| maintaining ease of development. Newer UI kits like Flutter are
| basically architected like game engines. This is a challenge
| that UI framework designers will have to confront if they want
| more native alternatives to electron. Whatever replaces
| electron must at the very least be similarly easy to use,
| accessible to many languages and runtimes, and trivial to style
| with non-copyleft usage license.
| peanut_worm wrote:
| It makes me really angry when a simple informative site is a
| bloated SPA app for no good reason.
| softwarebouwer wrote:
| Me too. Recently I was visiting what should have been a
| "simple" site, but for some reason maxing out my cpu because of
| some refresh loop. Maybe a bug, but the whole site could have
| been static html.
| tjpnz wrote:
| In many of the cases I've seen the company would've been better
| off with server rendered markup and perhaps some light client
| side validation (vanilla JS or jQuery). I'm at a loss as to how
| they ended up with this instead.
| scruple wrote:
| Where I work it's because we have all of these frontend
| developers and they need work to do. We keep sticking with
| ReactJS as the default because we have these folks and theres
| a snowballs chance in hell that they'd go, from their
| perspective, backwards in terms of the technology they use to
| do their jobs.
| verisimilidude wrote:
| It's not just simple content sites.
|
| The other day, I placed an online order for curbside pickup
| (with a national brick-and-mortar chain). When the time came, I
| drove up to their curb. But I couldn't access their "I'm at the
| curb, bring out my stuff" page. It just kept loading and
| loading. I had to go into the store to get my order.
|
| When I got back to my PC, I discovered a massive webpack bundle
| on that page, along with an absurd level of tracking software.
| The page had transferred 50MB before I could even use it.
|
| They knew their curbside page would be used exclusively by
| people on their phones, in their cars. They knew some of those
| people would pull up to stores with poor cell reception. That
| page should've been as light as possible. The page was
| ultimately just a simple form, so it should've been possible.
| joduplessis wrote:
| It has?
|
| I can think of very few areas in software development where there
| is this much innovation & diversity in frameworks & approaches to
| building something. Maybe our approach to usability has failed
| with all our "necessary" popups & cookie dialogues - there I
| agree. But to say "front end development" has failed simply
| because its evolved is a bit myopic IMO.
| barry27 wrote:
| I thought Antirez was too mature to jump on this boring
| bandwagon.
| xwdv wrote:
| Modern front end development cannot fail, it can only _be_
| failed.
| ilaksh wrote:
| I have a feeling that I am supposed to keep this a secret, but if
| you are tired of broken and slow websites, check out the Gemini
| protocol as a break from the BS.
|
| It's not going to fix the web or replace it in a lot of cases,
| but it's nice to have an alternative for some things.
| azmodean_kvkv wrote:
| This infantile false dichotomy again. We get it; BE engineering
| is far superior to JS/FE engineering so therefore anyone
| belonging to the BE/non-JS tribe is a far superior intellect and
| person. We're glad you feel better about yourself.
|
| I challenge you to be the change you want to see: 1) build
| something better 2) get wide adoption of it.
| okareaman wrote:
| I recently lost my internet provider, so while I wait for a new
| one I'm tethering from my phone. The Verizon unlimited data plan
| actually throttles me to modem speed, about 56k, so it's actually
| not unlimited. Anyway, it's been interesting to judge various
| websites by how fast they load at that speed. Hacker News comes
| right up. Twitter is acceptable. Facebook is terrible and often
| does not even load at all. The same for any site that uses React.
| I'm not sure why Facebook uses such a bloated system when they
| are trying to expand their user base into much of the world that
| does not have high speed internet.
| jasonpeacock wrote:
| Search for "Facebook Lite", it's their lightweight frontend for
| lower-bandwidth connections.
| okareaman wrote:
| It appears to be an app for a phone? I have no throttling
| problem on the phone in case that wasn't clear, but I don't
| care to look at the small screen and want to use my desktop.
| michaelt wrote:
| I think they mean https://m.facebook.com - a lightweight
| web version.
| okareaman wrote:
| I tried it. It's very ugly and featureless on desktop but
| it does load fast.
| lostcolony wrote:
| It actually used to have -more- features. I use it on my
| phone exclusively; once upon a time I could use messenger
| from within it. They removed that feature and now try to
| foist the Messenger app on me. So I don't use FB
| Messenger from my phone.
| cardamomo wrote:
| There's also https://mbasic.facebook.com, which is even
| more lightweight and still allows you to send and receive
| messages.
| jkelleyrtp wrote:
| Easier to start an ISP and give away free internet than to
| rewrite Facebook.com to be more performant
| daniellarusso wrote:
| This came up with my remote team recently.
|
| A coworker and myself had the worst internet speeds in the
| company, but he recently got FTTH.
|
| I went to replicate a bug, by clicking on a button quickly and
| excessively, and was able to add 5 duplicate entries into the
| DB.
|
| The frontend dev could not replicate it until I suggested using
| the Chrome dev tools to simulate a slower connection.
|
| I have Frontier DSL.
| lolc wrote:
| I remember tracking down corrupt entries in our DB. It was
| mostly one user introducing the inconsistencies. Turns out he
| would double-click on every button, and the browser would
| happily send-abort-send two requests every time. Sometimes
| these would race on the server.
|
| We implemented disable-on-submit after that, and the
| inconsistencies went away. Other people would click again
| when the response didn't come fast enough, but that was rare
| to lead to corruption. Probably when their connection was
| lagging, they would click multiple times in frustration. But
| that one guy provoked enough destruction to make us notice
| and fix it for everybody!
| withinboredom wrote:
| I'm living overseas and this happens with my phone from the US.
| It's unbelievable how many apps time out. Why an app has
| implemented a timeout is instead of relying on the network
| stack is beyond me.
| robertoandred wrote:
| React is not inherently slow. The sites you use are slow
| because they're bad sites, not because they use React.
| csmiller wrote:
| I believe Twitter uses React? Although it's possible that
| Twitter successfully served you Twitter-Lite while FB may have
| mistakenly sent the full version.
| okareaman wrote:
| I just checked. You're right. So maybe it isn't React but
| something else Facebook is doing.
| j-krieger wrote:
| How about editing your above comment that was badmouthing
| react then?
| okareaman wrote:
| Because I don't know it's not React. Twitter could be
| using a stripped down minimal version of React with
| limited functionality. Standard React could still be a
| bloated mess.
| Drew_ wrote:
| > Standard React could still be a bloated mess.
|
| React is ~6KB (even less g-zipped). React is very
| performant and its performance was one of it's original
| claims to fame over previous frontend frameworks like
| Angular.
| jiofih wrote:
| React never claimed performance, and the virtual DOM is
| quite wasteful. Any direct manipulation library will
| perform better.
|
| Plus, it's dishonest to look at react core size. react-
| dom, which is absolutely required, is 40KB minified AND
| compressed. Plus the usual plugins to handle icons, SVG,
| animations, and on on. A base React application easily
| crosses the 200KB gzipped mark.
| Drew_ wrote:
| > React never claimed performance, and the virtual DOM is
| quite wasteful. Any direct manipulation library will
| perform better.
|
| React's performance (in large part because of it's
| virtual DOM) over Angular was a common benefit cited in
| it's rise to fame. Indeed no one ever claimed React was
| somehow faster than the document API (or even JQuery) and
| that isn't what I'm saying either. Whether or not you
| think the virtual DOM is wasteful in 2021 is a separate
| opinion and even Svelte devs admit the virtual DOM
| approach is usually fast enough.
|
| > A base React application easily crosses the 200KB
| gzipped mark.
|
| I didn't bootstrap a CRA app to check its full size, but
| considering a hero image alone can easily be larger than
| this, it still stands that React is certainly not
| "bloated".
| thrower123 wrote:
| Being faster and smaller than Angular isn't much of a
| feat...
| jiofih wrote:
| The mating call of all react devs - "but what about the
| images". Who said a 100KB hero image was a good idea
| either? It doesn't excuse dropping a 1MB (when executed)
| bomb of JavaScript to deliver a blog post and making
| mobile and low speed users suffer.
|
| It's also established that byte per byte, JS is way more
| costly to download, parse and execute than images, the
| comparison itself is dumb.
| okareaman wrote:
| As I said, it's not the size of the React library that's
| the problem:
| https://news.ycombinator.com/item?id=26691150
| Drew_ wrote:
| There is no additional overhead in nesting React
| components vs normal HTML elements. React-rendered and
| normally rendered HTML are identical.
| okareaman wrote:
| Dan Ambramov has stated the reason hooks was created was
| to avoid nesting hell that was used to manage state. I
| may be misunderstanding him. I am not s React expert.
| Drew_ wrote:
| React hooks are just Javascript functions. The layout of
| your application is unaffected by the shape of your
| application state. Instead the shape of your
| application's state is typically governed by its layout.
| cjbconnor wrote:
| You can bypass the speed restrictions by decreasing the TTL on
| your machine by 1 [0], I tested it and it worked perfectly.
|
| [0] https://android.stackexchange.com/questions/226580/how-is-
| ve...
| okareaman wrote:
| Hah! This is awesome, I'll give it a try. Thanks.
| gpanders wrote:
| Funny, I just went through a similar experience and had to
| tether off a Verizon connection for almost two weeks.
|
| I certainly felt the pain of a slow connection too and felt
| frustrated at how badly this affected the experience on so many
| sites.
|
| Here's an idea: web developers should test their sites on the
| slowest connection speed still commonly available (ie 3G) and
| make sure the experience is still acceptable. I know that
| webpagetest [1] allows you to do this and the results are
| illuminating.
|
| [1]: https://www.webpagetest.org/
| wlesieutre wrote:
| No idea if they're still doing this, but Facebook has done
| "2G Tuesdays" for just that reason
|
| https://engineering.fb.com/2015/10/27/networking-
| traffic/bui...
| quonn wrote:
| After minification and compression, React is about 100kb and
| can be cached for a long time.
|
| With all the images, videos on social media etc. it seems
| rather small in terms of bandwidth.
| okareaman wrote:
| I'm not counting images and videos because all sites have
| that problem, but things like clicking on the notifications
| icon and then waiting for it too load and it never does so I
| have to give up and go back to my phone.
| Trasmatta wrote:
| I thought it was actually around 30kb, after being minified
| and gzipped?
| okareaman wrote:
| It's not the size of the React library that is the problem,
| it's the nesting of components with components within
| components that is the problem. If you've ever shown source
| and seen divs 20 to 30 deep, you're most likely looking at
| html that React produces.
| tpict wrote:
| A React component has no obligation to add a div or any
| other element to the DOM tree.
| okareaman wrote:
| Dan Ambramov has stated the reason hooks was created was
| to avoid nesting hell that was used to manage state. I
| may be misunderstanding him. I am not s React expert.
| tpict wrote:
| I believe "nesting hell" was in reference to obtuse state
| management architecture rather than DOM structure. It
| seems like a common misconception based off other
| comments on this post. Angular inserts a new custom
| element for every component so it's definitely a problem
| elsewhere, if not with React.
| pshc wrote:
| React needs to borrow the idea of 'zero-cost
| abstractions' from Rust. Too often I've seen five divs
| used to add five layers of behavior where one (or zero)
| divs could have had the same effect.
| nlh wrote:
| I travel a lot and have gotten quite used to browsing on
| airplane WiFi, so a similar low-bandwidth experience (at
| times).
|
| I'll add a huge culprit to the list: Medium. They have their
| own "clever" code to progressively load images and I find it
| absurdly frustrating (because in most scenarios, the images
| just don't ever load), so I end up with lots of design articles
| with blurry blobs of color instead of images.
|
| There are so many ways to natively progressively load images
| that I'm not sure why they've chosen the most user-hostile one.
| You see blurry blobs of color in no particular order, no
| indication of which ones are loading, no way to force a
| particular image, etc. I find myself frustrated often and I end
| up abandoning most of the stories (or avoiding Medium
| altogether).
| davidkell wrote:
| Has anyone found a frontend JS framework + backend combination
| with the developer ergonomics of say Rails, Django or Phoenix?
| Would love to hear.
| pyotr55 wrote:
| i'm currently trying out https://turbo.hotwire.dev/ which is a
| new library from the basecamp guys, which makes it really easy
| to create SPA feeling sites with rails, using little to no
| javascript, and in a very unobtrusive, intuitive way. i'm
| guessing it's going to be an integral part of the upcoming
| rails 7 release.
| glued wrote:
| Modern frontend development hasn't failed, the industry has.
| Frontend development is looked down on as "not real programming"
| or "simplistic" but it takes years to master and requires skills
| of both an engineer and designer. Leetcode and bootcamps will not
| prepare you for architecting a high performance, scalable,
| accessible, SEO optimized, visually appealing, usable experience.
| [deleted]
| jariel wrote:
| Some things that have changed:
|
| 1) We've gone from function to content mostly.
|
| 'Apps' used to mostly deal with files, like Word, otherwise, hey
| were standalone. Now we deal with an incredibly variety of
| content.
|
| 2) We've traded consistency and reliability for speed to market,
| and rapid evolution.
|
| App releases were once a year, web releases can be daily.
|
| In other words 'the web' is not 'about apps', it's about
| something slightly different.
| throwaway4233 wrote:
| The advancement of what is possible on the FE has not given ample
| time for FE developers to scale accordingly. That I believe is
| because of lack of standardization across the WWW and the
| reliance on existing libraries like Babel to accommodate this
| gap. The variation of how code behaves underneath now changes
| depending on what library you use and that tends to libraries or
| developers overcompensating for their code to run anywhere. IMO,
| we need to stop inventing the new, ensure browsers behave the
| same across 90% of users and then start innovating again. Sure,
| we might have to do this every few years or so, but the gap would
| keep increasing and thus have longer periods of stability.
| avl999 wrote:
| Hacker News and the old reddit is the pinnacle of user experience
| for a site of its "genre". The new reddit perfectly exemplifies
| what @antirez is saying. It's amazing to me that hundreds
| (thousands?) of people who work at Reddit thought that that user
| experience was an "improvement" over the old reddit.
| [deleted]
| danjac wrote:
| If it forces us to download a native app because the website is
| unusable, that's a "win" in their eyes.
| thekyle wrote:
| It really amazes me how bad new Reddit is. I have a Windows
| computer from about 5 years ago that I sometimes use. It takes
| about 10 seconds after clicking on a story for the first
| comments to load, and there is about a 5-second delay between
| pressing a key and the character showing up in any of the text
| input forms.
|
| Even on my new M1 MacBook Air it takes 2/3 seconds for every
| page to load.
| root_axis wrote:
| I don't find the argument convincing. I've used the web all day
| for decades, it's fine. Some sites are slow, some sites are
| buggy, some sites don't meet contemporary design standards...
| this is nothing new, it's the same as it ever was.
|
| The one quality that truly differentiates the new web from the
| old web is the Cambrian explosion of ad tech, but this isn't a
| "front-end" problem, it's a cultural problem rooted in the
| shifting expectation that everything on the web should be
| monetized. There isn't really a solution to this, ads are the
| opposite side of the coin for people producing goods and services
| that are ostensibly providing value to the economy in the
| abstract sense... this is the web we all wanted.
| runawaybottle wrote:
| There are good examples of ad integration and bad examples.
| People spend a whole lot more time talking about app
| architecture versus how to elegantly load, render/position and
| refresh ads.
| root_axis wrote:
| Agreed, but the people complaining don't really register the
| "good" examples, understandably.
| shadowgovt wrote:
| There have always been bad developers. Unless he means that he
| expects that by now, someone would have developed a completely
| idiot-proof infrastructure for making UIs, we can always assume
| that there will be people making websites who do not have the
| time or inclination to learn the tools and technology and make
| the wrong decision at every turn.
|
| ... And even though some idiot-proof frameworks exist, they still
| require somebody to put enough effort in to discover and use
| them.
|
| I mean, we can apply the same criticism to the giant pile of
| crapware in the mobile stores. Some software is good, some ain't.
| vikingcaffiene wrote:
| People trot this one out every now and again and what they mean
| is "front end used to be the easy part of the stack". If you
| lived in the bad old days of jquery spaghetti and in-line php
| templates you'd realize what a bad take this is. Yes it used to
| be that anyone could jump into the front end. And the front end
| _sucked_ because _anyone could jump into the front end_ and so
| they did. There was no organization. No architecture. Nothing.
| Just a bunch of files that got harder and harder to maintain as
| the app increased in functionality and scope.
|
| Modern FE is a discipline every bit as complex as anything that
| we face in the backend. It requires that we actually apply an
| architecture. Design our code so that we can respond to changes
| in our business requirements etc. Serious engineering rigor in
| other words. Hell I could make the argument that in some ways
| backend dev is much more straightforward.
|
| I think it's fair to say that we often put too much business
| logic into the front end. Fat clients are not something I agree
| with. But to say things used to be better is just flat out
| incorrect.
| withinboredom wrote:
| > I think it's fair to say that we often put too much business
| logic into the front end.
|
| As a back-end dev, this reminds me of the time I used our own
| product and saw a read-only field on the UI. It was some
| interesting bit of data that only existed in the database (we
| didn't expose it in the API) and I brought it up how cool it
| was that we were doing that now. The front end dev said, "oh,
| it's not from the database, we make several API calls to get
| the bits we need and then calculate it the same way we do on
| the backend"
|
| I facepalmed. Like, just ask to expose that data, it's a single
| line of code! Instead we made 7 API calls... :sigh:
| vikingcaffiene wrote:
| Yeah I generally think the UI should only manage stuff like
| that cosmetically. Stuff like form validation etc. The real
| work should happen on the backend and not care about UI
| stuff. So it just throws if the user tries to get cute. IMO
| that is a nice separation of concerns and keeps the client
| thin and presentational in nature.
| jasonlotito wrote:
| > I facepalmed. Like, just ask to expose that data, it's a
| single line of code! Instead we made 7 API calls... :sigh:
|
| The reality here is that this person who worked in your
| company, along with everyone else who saw that code and
| deployed it, all thought it was easier to do what they did
| then ask you to expose that data with one line of code.
| y2bd wrote:
| Man I'd love it if our backend teams were that willing to
| make changes for us. So often I stumble across bizarre,
| complicated business logic in our various client code bases
| and ask the devs "why is this here? surely this is better put
| on the backend/already exists on the backed" and am greeted
| with "we agree, but when we asked the backend teams to make a
| change on their end they told us it would be done in the next
| year or two".
| vikingcaffiene wrote:
| That's aggravating. I do full stack dev and work at
| startups so that particular scenario hasn't come up but I
| could see how that disconnect could create some tech debt.
| That said, I think it's a planning process problem. You
| really should have someone on your project capable of
| making those changes. People really are the hardest
| problem.
| yummypaint wrote:
| Obligatory:
| https://www.youtube.com/watch?app=desktop&v=Yx6k6WR8GRs
| tootie wrote:
| This isn't a development failure. Content businesses have been
| struggling to turn a profit online for years and we're at an
| inflection point now. Some sites are opting for squeezing revenue
| from every spare pixel and bombarding social media with
| clickbait. The rest are going to start pushing subscriptions
| really hard. And there's going to be a widening gulf between the
| two.
| wonnage wrote:
| You try writing a UI that:
|
| 1. works visually at all screen widths and resolutions
|
| 2. returned from a server with zero knowledge of said screen
| widths and resolutions
|
| 3. without shipping redundant assets
|
| 4. responds immediately to user input
|
| 5. but all visual updates go through this slow and crappy DOM API
|
| 6. oh, and it's all single-threaded
|
| 7. and there's no standard library for stuff like virtualized
| lists, modals, etc. so have fun picking your own and shipping it
| down
|
| 8. and your options for navigation are either losing all local
| state at each navigation, or writing a SPA that some neckbeards
| on HN hate for esoteric purity reasons
| ta20210403 wrote:
| This is what happens when you let sociology majors with dyed hair
| who take a two month "coding boot camp" become "full stack
| engineers".
| bitwarrior wrote:
| I'd say we're likely comparing apples to oranges here. It's a
| common complaint on HN that frontend development is a mess and
| evolves too quickly, that it isn't "what it used to be". Static
| pages, small downloads, very little coding overall. What we miss
| is those kind of sites still exist, but they're not the sites
| we're complaining about.
|
| Back in the late 90's and early 00's, most websites were largely
| "brochure" websites. Companies were getting online because they
| heard about this whole internet thing and they knew they just
| needed to "get on the internet". You largely saw companies
| uploading whatever brochure they had basically into a digital one
| online. Those websites were insanely straightforward. Render a
| page, static content, the end. Maybe it's a little more dynamic
| than that, perhaps you're running a basic LAMP stack listing,
| say, real estate. Query the database, render the page, we're done
| here. Very little interactivity.
|
| Those websites still exist, but they're likely not the ones we're
| complaining about. Site's like boeing.com are those traditional
| brochure sites which deliver very little interactivity.
| Relatively quick and nimble, the hero image is larger than all
| the JS they load (and, honestly, they could probably remove most
| of their JS now - they're using jQuery, modernizer, underscore,
| stickyMenu, require.js and a bunch of probably unnecessary jquery
| plugins we can eschew today, but we're here to complain about
| today, not praise it amirite?).
|
| What we're actually complaining about are usually the interactive
| sites. Your Twitters, Facebooks, even sites like Reddit that
| dynamically load content as you scroll, click posts and download
| more content, comment - all manner of interactivity. Typescript?
| React? Functional components? Hooks now? Learn Redux? Unlearn
| Redux? CSS flexbox? CSS grids? My website now has a build
| process? I used to just edit the PHP file and upload it via FTP.
| What the hell?
|
| These are not simple "brochure" websites, so yeah, they're more
| complex. They're applications. And being that they're
| applications, we shouldn't be comparing them to brochure
| websites, since they're delivering a completely different
| experience and have a completely different goal. We should be
| comparing them to desktop applications and the desktop
| application development environment, and therefore, comparing
| their stacks against the likes of C# and WPF, Swift and Cocoa,
| C++ and Qt or C and GTK.
|
| And compared to those tools, how does the modern web development
| tool chain stand up? I have no idea, I don't write desktop
| applications! But what I do know is companies like Slack and
| Discord have elected to use electron rather than create their
| products in whatever desktop application framework. VS Code is
| electron-based and being a Microsoft product they had all the
| reason in the world not to do that - and it's dominating it is
| space today. Offerings like Figma, which by all rights one would
| imagine should have been desktop software elected to be an online
| tool and has completely shut out the competition.
|
| So if you're going to complain about online applications, don't
| compare it against an old programming paradigm that would never
| apply to these products. Compare them against the modern desktop
| application development experience and let's start the
| conversation there.
| watwut wrote:
| In what way are current websites not usable?
| minitech wrote:
| A lot of websites:
|
| - reimplement browser features and do a bad job of it
|
| - are unnecessarily slow
|
| - try to stop being slow by breaking even more stuff
|
| Some examples I've come across within the last week:
|
| - Twitter pages randomly failing to load until the next hard
| refresh, probably because of service workers somehow (which are
| unnecessary for user experience improvement since HTTP cache
| exists and I don't have notifications enabled)
|
| - Twitter's offscreen tweets not being searchable with browser
| find because they were optimized out of existence - and I want
| to do this in the first place because it decided to refresh
| itself while I was in the middle of reading
|
| - YouTube application state getting out of sync with browser
| history that it overrides when I navigate Back too fast for it
| - the URL stops matching what's playing and the navigation
| doesn't take place
|
| - GitHub's reimplementation of browser navigation
| reimplementing a loading indicator but not the stop button (I
| think I've also gotten it out of sync before)
|
| - Form state not being restorable across history navigation
| because the fields didn't exist when the page loaded
|
| - Reddit's redesign is so unusably sluggish that I don't stay
| on it long enough to run into any other problems
| napsterbr wrote:
| > Reddit's redesign is so unusably sluggish that I don't stay
| on it long enough to run into any other problems
|
| I agree with everything you said, but allow me to reiterate
| this point. Reddit's redesign is the most hostile thing I've
| ever seen. It explicitly blocks me from reading the
| discussion. What's the point, then? It's absolutely unusable.
| If they ever remove old.reddit.com, I'm not following a
| Reddit link ever again.
| sdfhbdf wrote:
| I started reading your list looking for something to argue
| with but I'm sadly agreeing with all your points which I
| encountered myself.
|
| I didn't even realize they're reimplementing browser features
| and that's a really cool observation.
|
| I think it's paramount to understand that this is not a list
| of bugs to fix, it's a list to convince us that we should
| consider Server Side Rendering more often and avoid client
| side navigation, history API with all its possible race
| conditions...
| mrkramer wrote:
| "I can only think that modern front end development has failed"
|
| I think web devs have no real incentive to improve their front
| end since search engines don't stimulate and reward them to do
| so.
|
| Ranking algorithms are blackbox but you can notice that
| popularity is more important than quality of content so
| eventually web gets bloated and you end up in information
| overload.
| ta20210404 wrote:
| This is what happens when you let sociology majors with dyed hair
| that have a two month "coding boot camp" in their resume become
| "front end engineers".
| dmje wrote:
| It's the same as it's ever been. The same mistakes, the same
| things done right, just all in different shaped packages.
|
| Fundamentally it comes down to the same thing: use appropriate
| tech. Use it because you should and not because you can. Don't
| build a SPA if you can do it in a simpler way with plain HTML and
| CSS. Don't build an app if you need a website. Don't bother with
| some enormous backend horror if your site is never going to need
| to scale to that size.
|
| It was the same way back with Flash, dhtml, html5, early
| JavaScript, CSS, Dreamweaver, whatever - if you need something,
| use it, if you don't, don't.
| marvel_boy wrote:
| So true.
| segmondy wrote:
| The worst is the dynamic DOM manipulation, where what you print
| isn't what's rendered on display.
| TruthWillHurt wrote:
| For me it failed mostly because the complexity involved. Even a
| rather simple interactive website requires weeks/months of coding
| & testing. WYSIWYG editors don't cut it, and we need to implement
| same things over and over again (i.e login).
| wideareanetwork wrote:
| That's a really negative, glass is half full viewpoint. How can
| anyone not see the incredible wealth of unbelievable awesome that
| is the modern web?
|
| How can anyone use 200 popular websites and see shit instead of
| being astounded by how awesome it all is?
|
| I look at the same thing and see unbelievably powerful web
| applications, the web browser as the most sophisticated fabulous
| software ever built (alongside Linux), a constant drive amongst
| front end developers/libraries/tools for new and better ways of
| doing things.
|
| And I see so many websites that it's impossible to make sweeping
| generalizations about front end development.
|
| The world contains certain people who want to see the bad... this
| is what's happening here.
| mLuby wrote:
| What we're missing in front-end development is more _abstracting
| away solved problems_ so you don 't have to think about them ever
| again.
|
| Shared frameworks and libraries do help significantly with this
| but the fact that they still undergo substantial churn tells me
| they haven't completely solved the problems they address. When's
| the last time you needed to drop down into Assembly to fix your
| JavaScript? Probably never--you can operate at that higher level,
| which lowers barriers to entry and increases productivity for
| developers. (Put your hand down, you wonderful machine code
| hobbyist, you.) In contrast, we still "drop down" from web app
| components into JS/HTML/CSS all the time.
| franklyt wrote:
| The tools exist the solve these problems: blame developers.
|
| TypeScript and modern frameworks with contemporary understanding
| of app design kills nearly every historical pain point of web
| development, but many are stuck writing jQuery and using
| WordPress.
| fctorial wrote:
| Javascript being enabled by default motivates developers to
| include javascript in their site by default. It was a mistake.
| neonological wrote:
| Given that a lot of people have the title "front end web
| developer" of course there's going to be backlash. Most people
| aren't unbiased enough to hate on the thing they've spent years
| mastering.
|
| Frankly front end web development is a huge mess if you look at
| it from an unbiased perspective. HTML wasn't designed for
| multimedia, JavaScript was designed in a week. Now the entire
| modern industry of web development are a series of endless hacks
| built on top of the old framework. React, typescript, css are all
| skin grafts on top of technology that was designed for something
| else. Of course the end result is going to be inefficient. The
| entire web is new tech patching up old tech. It's like the 737
| max, all of modern web development is an MCAS on top of html.
| It's not even a single thing. It's like hundreds and hundreds of
| MCAS's with some MCAS's built to patch up other MCAS's.
|
| The fix of course is to start from scratch. Given all of our
| knowledge of Modern web GUIs design a singular native api that
| can achieve what we need with significantly less complexity and
| better performance.
|
| Of course some front end engineer with 10 years of experience
| isn't going to openly embrace a new api that is not only better
| but can possibly mastered in a month by any average dev. If
| you're primarily a front end developer I have to say that I
| cannot trust your opinion. I do not believe any person has the
| impartialness to deride the very thing that defines their career
| and expertise. Literally front end developers are just experts at
| navigating a universe of patches and hacks and no such dev wants
| to admit it.
|
| I'm interested in peoples opinions though, it's just in a thread
| like this it's impossible to get an unbiased opinion.
| BlueTemplar wrote:
| As a recent example : Substack is worse than Wordpress. And it's
| probably related that you can read Wordpress comments with
| JavaScript disabled, while not Substack comments.
| SilurianWenlock wrote:
| I only have experience with backend non web development, so my
| experience may not be worth much, but...
|
| Setting up a frontend web app with React (or Angular) is insanely
| hard to self teach and I would consider myself very good at self
| learning. Its hard to workout how to integrate React with
| Bootstrap and you often start to get problems you are not even
| sure how to fix. When you look at tutorials online, they all have
| slightly different tech stacks which complicates this further.
| Second to this working out how and where you get your graphics
| from is impossible for me.
|
| Frontend blows my mind! (And this comes from a guy who has done
| +1000 leetcode problems for fun)
|
| Also, in this thread people say this or that is bad without
| specifying examples of websites and a problem which could be
| fixed. Is anyone able to name 2 to 3 concrete websites and
| examples from which others can look at and learn what is wrong?
| m_j_g wrote:
| I think that this branch of engineering is still in its infancy
| (like electrical engineering int the times of edison). I am
| courius how front end development will look when dust will
| settle, maybe in 50 years?
|
| Maybe todays, heated disucions will be setted for good? Or
| something new, better will be invented?
| pictur wrote:
| modern front end development is very prone to producing shit. and
| it can happen in a very short time, not in years. If user
| experience and performance are still important to you, you can do
| good things. But if your only concern is to try new things and
| mess with your application, the end will be producing shit.
| CM30 wrote:
| This topic seems to come up on Hacker News every few months or
| so. Not saying the post is necessarily wrong there, but it's
| certainly something people here love discussing nonetheless.
|
| As for why front end development may be a bit of a mess here?
| Well, it's really a problem that doesn't have just one cause.
|
| On the one hand, business pressures likely have a huge impact
| here. Companies love analytics, tracking, ads, etc, all of which
| contribute greatly to the issue of slow loading, broken sites. If
| you include everything and the kitchen sink, then things will
| clash or time out or break.
|
| There's also an issue with businesses focusing on speed and
| working getting done quickly rather than well. If you're given
| unrealistic deadlines, and the feature set is changed midway
| through development because some manager/sales team thought of a
| shiny new idea that needs implementing... well it seems like
| optimisation, usability, etc often end up on the cutting room
| floor.
|
| And yes there's a bit of envy from developers towards
| Facebook/Google/Apple/whatever there too, and a need to 'test out
| the shiny new toys' so they can potentially get hired there in
| future. I suspect CV padding is definitely why SPAs are way more
| common than they used to be, and why simple static or server
| rendered sites seem nearly nonexistent now.
| [deleted]
| [deleted]
| crazygringo wrote:
| > _sites that are unable to obey the most basic rules of
| navigation and usability, terribly slow despite the hardware
| progresses. And I can only think that modern frontend development
| has failed._
|
| We have more information and services available than ever before.
| And it's never been cheaper or easier to start something new.
|
| I don't know what "basic rules of navigation and usability" the
| author is referring to, but I virtually never come across a site
| that can't be navigated or isn't usable. And _all_ software gets
| "slower" as hardware grows faster [1], it's not anything specific
| to the web.
|
| The web is _amazing_ , nothing has _failed_ , sheesh. Yes there's
| _always_ going to be room for improvements both in speed and
| usability -- developers are human, nothing will ever be perfect
| -- but the idea that the most popular digital interface
| technology of all time has "failed" is ludicrous.
|
| [1] https://en.wikipedia.org/wiki/Wirth%27s_law
| fctorial wrote:
| > And all software gets "slower" as hardware grows faster
|
| Quoting a statement doesn't make it good. It's bad.
| crazygringo wrote:
| I'm just saying it's not specific to the web. It's not some
| specific _failure_ of front-end technology compared to
| others. It 's not a failure at all, nor is it amazing, it's
| just par for the course.
| cryptica wrote:
| All software development has failed. Everyone is mindlessly
| copying megacorps with terrible development practices. Then when
| their crappy systems fail constantly, they blame the tools and
| demand even more complicated tools from their corporate
| masters... Which make their code even less reliable.
|
| Tooling is not the problem, the problem is you and your selfish
| subconscious urge to create more complexity to create more work
| and more income for yourself.
| swader999 wrote:
| I don't think greed has much to do with the complexity.
| Insecurity seems to cause a lot. Devs feel if they don't go
| with all the latest stuff to all the nines they aren't worthy.
| futureproofd wrote:
| I have to agree with this, but I think insecurity may affect
| junior developers more so than their seniors. Most of the
| new, in-demand tech that companies require of their
| applicants can be learned within a week or two, to be able to
| successfully contribute. That is, if you're already
| experienced with a number of complex frameworks or libraries.
| Then, It's simply a matter of reading the manual to figure
| out how to move the data from one place to another.
|
| On the other hand, for a junior dev trying to break into the
| workplace, selecting the correct technology could be
| considered an important investment of their time, and
| ultimately their livelihood.
| rantwasp wrote:
| you are probably right that there is a lot of complexity for
| complexity sake. it's sad actually. also solving problems that
| you don't have and you'll never going to have (k8s I'm looking
| at you)
| caseymarquis wrote:
| I'd like to add a bit more nuance. Modern frontend development
| provides many opportunities for failure. These failures often
| make their way into production. I, personally, get great results
| with modern FE development. My users are happy. I am happy. It's
| all very successful. All the defenders of modern FE development
| will likely chime in with the same sentiment. I also get great
| results with C, which arguably provides even more catastrophic
| opportunities for failure. I wouldn't say "C is a failure", but I
| absolutely hate working in C, and I'm glad we've made
| improvements to systems programming. I think the point I'm moving
| toward is that we absolutely should strive to make better tools
| for delivering web content, but the reasons for failure are far
| more complex than the tooling itself. So, let's not frame things
| in black and white and call something that's been used with large
| amounts of success a failure. That's not very productive and is
| just flame bait. The real question is, "What's next?", how are we
| going to improve the current situation?
| bjornjajeja wrote:
| I think a lot of it had to do more with business requirements
| than art or science. The business folks stroll in and make
| these generic one-click deploy type things to get sites up and
| running quickly, at the expense of being vetted by good artists
| and scientists.
|
| A good analogy I think is any person using MS publisher to
| create a book layout. Sure it can be done quickly because the
| software does the thinking; but should it? Good books have
| skilled typographers designing the proportions of the pages
| relative to text block, the fonts, et cetera. The end result is
| a book that one scarcely notices but feels very pleasant to
| hold and experience.
|
| We need websites that are subservient to their content; sites
| we scarcely notice but thoroughly enjoy.
|
| EDIT: one last point: I think part of the problem is also that
| browsers have an identity issue. E.G. they started as a static
| publishing platform, but now they are a full blown operating
| system with web assembly etc. As we know, anything that does
| too many things is inherently complex, and hence "bloated."
| darkhorse13 wrote:
| >Modern frontend development provides many opportunities for
| failure
|
| I think this is the important thing here. Everything feels less
| stable, and more prone to breaking, on the modern web. You
| write some simple HTML, style it with CSS, and write vanilla JS
| for the parts that need it, and everything feels solid. You
| start a new project with a framework, and it seems like there
| is this whole area of your project that is essentially a black
| box, ready to break (or misbehave) any time.
| martinald wrote:
| This is a really rose tinted view of the world. Writing
| JavaScript works ok now the language and browser support has
| matured. 10 years ago it was a complete nightmare.
|
| Regardless without a framework it ends up with you
| reinventing core framework features anyway. Yes, a framework
| driven app is more complex if the page/app is extremely
| simple. But if it is of any complexity a framework driven app
| is going to be far easier to maintain and reason about in 99%
| of situations.
| goatinaboat wrote:
| _You write some simple HTML, style it with CSS, and write
| vanilla JS for the parts that need it, and everything feels
| solid._
|
| Bootstrap + jQuery on the front end, Flask or similar with
| CherryPy on the backend. SQLite or Postgres if you need it.
| That will handle 99.9% of websites, it will be cheap and easy
| to develop and host, and deliver a great experience to the
| end user.
| mmcnl wrote:
| This is partly true, but I would also like to state things
| have much improved. I can vividly recall the 2000s where
| practically every website would look and behave differently
| in different browsers. I recall a lot of debugging client-
| state using poorly scripted PHP websites. Tooling so much
| more advanced and things "breaking" have moved from the user
| to the developer. In the jQuery days (or even before that) it
| was very hard to find out if everything was working as it
| should. Early feedback is a good thing. Understanding a
| framework is part of understand what you are shipping to the
| customer or user. Sure, it might seem more complex, but at
| least complexity isn't pushed down to the browsers and users.
| Drew_ wrote:
| > You start a new project with a framework, and it seems like
| there is this whole area of your project that is essentially
| a black box, ready to break (or misbehave) any time.
|
| Any framework you're not familiar with will feel like this.
| This isn't something unique to frontend frameworks.
| q-big wrote:
| > Any framework you're not familiar with will feel like
| this. This isn't something unique to frontend frameworks.
|
| But the frameworks get out of fashion faster than you can
| obtain deep knowledge of them.
| vsareto wrote:
| This is starting to no longer be true. We've held
| Angular/React in the top spots for a while now. Vue is
| probably next in line.
|
| However, both front-end and back-end are substantial
| enough now and have enough frameworks and environments
| that it's really hard to do well at both. I'd much prefer
| more specialization, which would hopefully lead to higher
| quality.
| Drew_ wrote:
| Being concerned with a technology "falling out of
| fashion" is a personal problem not a problem with any
| framework. In any case, this is not a concern when using
| mature technologies which are the ones you should be
| using.
| rdel wrote:
| What framework was popular 4 years ago and is now
| unmaintained? This is a common remark that was true maybe
| 10 years ago but hasn't been in quite a while. React,
| Angular, and Vue all have dedicated maintainers and
| millions of users, and have for several years now.
| selimnairb wrote:
| At some point, there is an irreducible amount of complexity.
| At that point, adding things like over-wrought frameworks to
| "make things easier" for the developer ends up pushing the
| complexity around, like an air bubble trapped under a screen
| protector.
| toast0 wrote:
| There's necessary complexity, and then there's extra
| complexity.
|
| IMHO, a lot of frameworks just add extra complexity. Now
| that we're in the twenties, you don't need nearly the level
| of browser compatability shims like at the turn of the
| century. Sure, bleeding edge features need that, but most
| sites don't need any of that. Certainly news and shopping
| fit well enough with turn of the century browsers, so
| everything else is fluff (and retargetting, ugh).
|
| It's the same with a lot of server side frameworks;
| especially PHP frameworks. I've never been able to grasp
| what a PHP framework can do that PHP can't, other than burn
| 50ms of cpu before outputting anything.
| postalrat wrote:
| Whats the business case for less JS? Recently the company I
| worked for started a project where it seemed pretty clear to me
| would be possible to develop with very little JS running on the
| frontend. But I couldn't convince anyone of it because no one
| saw enough benefit from doing it that way.
| j-krieger wrote:
| I love modern frontend development. I can build apps that scale
| easily to hundreds of thousands of users. They are fast where
| they need to be fast, and building components means complexity
| lives only where it's needed. Static parts are rendered
| statically, dynamic parts are rendered dynamically. I can write
| all code for the entire stack in Javascript. The entire
| workflow is streamlined in a simple way (webpack really isn't
| that hard to grok). There are templates for every project
| imaginable. I don't need an entire VPS for my web-apps, just a
| simple static hosting service. My apps run on every system and
| any browser back to IE9 without any issues whatsoever. No
| complex build tools or linking process or debugging weird
| architectures needed. Compatibility issues are solved
| automatically in any modern build pipeline by adding vendor
| prefixes. New code is transpiled to old code for older
| browsers. Debugging modern front-end code is a breeze, there
| are an infinite amount of tools both for styling and the code
| itself. My modern frontend app takes seconds to build; QT apps
| I built in the past needed up to twenty minutes, just to check
| a simple change. No need for that with hot reloading. My users
| are happy too: They don't have to download an app which might
| not work on their specific system. Linux, Windows and Mac users
| alike can use it on their computers, laptops, tablets and
| phones without any issue. They can use the default environment
| a browser provides for an even better user experience (zooming,
| Screenreaders, upscaling fonts, copying images and text,
| preferences for dark mode, theming their browsers, saving
| credentials and auto filling them, sharing stuff, etc.).
| Integrating stuff from other companies has never been easier:
| Paypal, Stripe, Apple Products all provide a well tested and
| documented library for every framework out there. There are
| open source packages for anything, it's a FOSS dream. Building
| prototypes for anything is insanely fast, thanks to modern
| debugging tools in Chrome and FireFox.
|
| It's much better than people make it out to be.
| xcambar wrote:
| > build apps that scale easily to hundreds of thousands of
| users
|
| I don't understand this.
|
| Frontend dev is about writing a portable software to run on
| as many runtimes as there are users. There is literally
| nothing to prevent any frontend software, good or bad, to
| "scale", because scaling in terms of users is nonsical for
| frontend dev (unless you consider browser compatibility as
| scaling, to which statement I'm orthogonal).
|
| Note: meanwhile, back end dev is about writing a program that
| accepts as many users as possible, which make front and back
| nicely yin-yang together. But maybe I'm overstating things
| here :shrug:
| jefftk wrote:
| Doing most of the work on the client instead of the server
| can often make scaling much easier.
|
| I read your comment as assuming that the division between
| the server's job and the client's job is fixed, but as the
| browser has become more powerful many things have moved to
| the client.
| JMTQp8lwXL wrote:
| Doing the work on the client can sometimes be the right
| choice, but I'll share a converse point. I was tasked
| with implementing a bulk record upload feature. The UI
| was to accept up a CSV file with up to 1 million records.
| The API provided by the backend team accept max 1,000
| records in JSON.
|
| So now I have to convert CSV, for which there's no
| official specification, to JSON, and then make (up to)
| 1,000 HTTP requests via HTTP 1.1 -- and a different back
| end team owns rate limiting for all ingress. I end up
| using a package called 'promise-limit' to ensure only N
| number of requests are open at a time; firing 1,000
| simultaneous XMLHttpRequests is a bad idea. I end up
| fielding bug reports concerning the translation to JSON
| for edge cases. And collating the 1,000 network responses
| for any individual record that failed to persist was
| something we didn't get to building. So users were
| uploading 1M records, had some proportion fail, and had 0
| visibility into what data the system had, and what data
| didn't make it.
|
| Eventually, we gutted all of that and the backend team
| added a file upload endpoint. But explaining why this
| shouldn't be a front end feature, to folks who primarily
| or exclusively do backend work, it's tough to communicate
| (1) all the pain points of dealing with the complexity in
| the front end and (2) the scalability issues. "Can't you
| just do it on the front end" is such a frequent retort I
| receive, for things we truthfully should do on the
| backend.
| Chiron1991 wrote:
| That's interesting. From my experience, the backend guys
| are usually more down-to-earth and often save the
| frontend guys from doing overcomplicated/bad stuff. Not
| wanting to implement a file upload endpoint for that task
| sounds suspiciously like some unmotivated guy that
| doesn't give a sheit about the app.
| josephg wrote:
| The argument to make to the backend team is a bit nuanced
| but it's this: Generally each PUT/POST sent to the
| backend should have atomic semantics. If there's some
| user action (like uploading a CSV) that should entirely
| succeed or entirely fail, you want to send it in a single
| HTTP request. If it matters that it happens exactly once
| (like submitting a forum post), then adding a nonce of
| some sort is a good idea too - just in case the request
| succeeds but the response gets dropped and the user
| retries the action.
|
| It's often tempting to model URLs like database entries
| and send multiple requests to the server to model
| updating many records based on one action. That's a
| mistake - have the client name the action, send one http
| request, and execute it in a single database transaction
| in the backend if you need to. This approach is way more
| reliable, debuggable and consistent. This sort of thing
| is absolutely the backend's responsibility.
| sitkack wrote:
| Your backend devs are shirking responsibility, the front
| end shouldn't prep data, it should handle input and do
| rendering.
| u801e wrote:
| > Doing most of the work on the client instead of the
| server can often make scaling much easier.
|
| I've also found that it results in a non responsive
| webpage. For instance, text taking multiple seconds to
| render in an input box (Slack, Facebook, amongst others)
| and times where the browser tab process ends up
| allocating a signficant percentage of system resident
| memory and/or CPU resources, which makes the computer
| itself slow to respond.
| pjmlp wrote:
| Aka 3 tier architectures back in the day....
| ubertoop wrote:
| xamber's point remains valid though -
|
| while code may move to the frontend, the notion of
| scaling isn't a function of the number of users (as the
| original op erroneously states).
|
| maybe they meant their front end code scales as
| complexity is moved from server to client? that would
| make sense.
| [deleted]
| findjashua wrote:
| I think gp meant that you don't have to send a server
| request to handle every user interaction. The server has to
| handle much fewer user requests, and only return data
| (instead of generating the template as well).
| jayd16 wrote:
| Frontend dev usually includes dev of backend components
| that serve the frontend. Even serving static html files has
| to scale to every user.
| Matrixik wrote:
| They are fast only on fast and expensive user equipment:
|
| https://infrequently.org/2021/03/the-performance-
| inequality-...
|
| More context in older post:
|
| https://infrequently.org/2017/10/can-you-afford-it-real-
| worl...
|
| > Partner meetings are illuminating. We get a strong sense
| for how bad site performance is going to be based on the
| percentage of engineering leads, PMs, and decision makers
| carrying high-end phones which they primarily use in urban
| areas.
| Drew_ wrote:
| Got to agree with everything but
|
| > Debugging modern front-end code is a breeze
|
| Is still hit or miss every once and while depending on the
| use case. For example debugging service workers is still a
| bit of a nightmare. And I've also had some issues debugging a
| chrome extension written with Vue CLI + the browser extension
| plugin.
| pfraze wrote:
| This is sadly true, but service workers are themselves hard
| to get right, and they tend to create subtle cache issues
| that are hard to notice until the deployment after their
| deployment to production.
| j-krieger wrote:
| I'd argue service workers are a pretty rare thing to debug
| toss1 wrote:
| This entire read seems to be that things are much better for
| YOU, the front-end developer.
|
| And yes, that makes a difference, you can deliver more
| features, faster, more reliably.
|
| But, if those sites just bog down and take double-digit
| seconds to load, even when properly deployed on scaleable
| delivery architectures, with fiber-optic speeds, and
| CAD/gamer-level power machines, they are junk.
|
| And I increasingly see exactly this junk been over the last
| few years. Even (and often especially) the major sites are
| worse than ever. For example, on the above setup, I've
| reverted Gmail to the HTML-only version to get some semblance
| of performance.
|
| Sure, some of this could be related to Firefox' developments
| to isolate tabs and not reuse code across local containers
| and sessions, but expecting to get away with shipping
| steaming piles of cruft because you expect most of it will be
| pre-cached is no excuse.
|
| Your site might have the look and features of a Ferrari, but
| if it has the weight of a loaded dump truck, it will still
| suck. If you are not testing and requiring good performance
| on a rural DSL line and mid-level laptop (or similar example
| of constrained performance), you are doing it wrong.
| vagrantJin wrote:
| I cant agree more. I could cry. Ive been on a crusade for
| over a year to scale back diddly js frameworks because
| 'scale'. Ive heard many bullshit excuses before but
| sacrificing performance and reliability for being
| "scalabable" is beyond mind boggling. It gives me a panic
| attack when medium articles are the chief architect and
| purveyors of software development truths. I live and work
| in developing countries and could never understand why
| sites keep getting slower around 2017 before I stumbled
| into medium with their React and K8s articles ad nauseum. I
| realised the juniors and intermediate devs are reading
| these things as truth and applying it as gospel.
|
| My head hurts just thinking about react.
| darkwater wrote:
| I guess you are a talented developer working in the right
| environment. But the vast majority of sites outside there
| (not controlled by some tech behemoth) are usually not
| optimized, work on Chrome, usable only by abled people and a
| long etc etc
| alerighi wrote:
| There are many reasons why having SPA and rendering your site
| on the client is a bad idea.
|
| First, you are basically breaking the concept of the web, a
| collection of documents, not a collection of code that must
| be executed to get a document. That has many bad effects.
|
| Browsing is slower, you have to download the code of the
| whole application and wait for it to execute other API calls
| to the server before the page is usable. That can take a
| couple of seconds, or even more on slower connections. With
| the old pages rendered server side not only you didn't have
| this effect, but also the browser could start to render the
| page even it was not fully received (since HTML can be parsed
| streamed). Not everyone has a fast connection available at
| all time, and it's frustrating when you have only a 2G
| network available and you cannot do basically anything on the
| modern internet.
|
| It's less secure, since you are forcing the user to execute
| some code on its machine just to look at an article in a
| blog. And JavaScript engines in browsers are one of the most
| common source of exploits, given their complexity. Also
| JavaScript can access information that can fingerprint your
| browser to track you, without particular permissions. Ideally
| in a sane world most of the websites don't require
| JavaScript, and the browser would show you a popup to allow
| the website to execute code (just like they as you access to
| the camera).
|
| It breaks any other tools that are not a browser. In the old
| days you could download with wget entire sites on your hard
| driver to consult them offline, with "modern" SPA is
| impossible. Of course that implies that it breaks things like
| the Wayback machine and thus history is not preserved. And
| serach engines penalizes sites that are not a clean static
| HTML.
|
| It's also less accessible, since most SPA don't respect the
| semantic of HTML, everything is a div in a div in a div. And
| of course you still need a browser, while with HTML documents
| you could process them with any software (why a blind person
| need to render the page in a browser? While a screen reader
| could have simply parsed the HTML of the page without
| rendering it on screen...). It breaks navigation in browser,
| the back button no longer works as you expect, reloading a
| page could have strange effects, and so on. I can't reliably
| look at the address bar to know the page I'm in.
|
| Finally it's less robust. SPA are a single point of failure.
| If anything goes wrong the whole site stops working. While a
| bug on a page on a classical server side rendered website
| breaks only that particular page. Also error handling is not
| present on most SPA, for example what happens if an HTTP
| request fails? Who knows. Look at submitting a form, most of
| the time there is no feedback. On a classical server side
| rendered application if I submit a form I either get a
| response from the server, or the browser informs me that
| request had failed and I can submit the form again.
| stevenicr wrote:
| Interesting take that I more agree with than disagree -
| However I think " there are an infinite amount of tools both
| for styling and the code itself."
|
| Is actually one of the symptoms of the issue at large I
| think.
|
| I understand some sites depend on more complex APIs and such
| - certainly fbook uses the complex stuff that these
| frameworks do..
|
| However many people are using wordpress and similar tools
| simply to have a basic static few bits of info from a few
| pages display decently on various devices. I too am guilty of
| such a thing on more than one occasion.
|
| For these cases I am moving towards converting the designs to
| static html and using a php based script from coffeecup to
| handle the contact form part that in the past I've lazily
| just added a two click plugin from wordpress to handle.
|
| I feel that the CSS standards group really dropped the ball
| with not having better responsive menus 'built in' as a part
| of the problem that can be solved in the future. Now that
| grids are built in - the menus that bootstrap does auto-
| magically for most devices is the missing piece that keeps
| many sites from being just html/css.
|
| I'd love to go back to netobjects fusion for design, but it
| has not kept up with the responsive needs of the web. I tried
| coffeecups site designer in beta and it wasn't for me. I've
| built dozens of sites using notepad++ and occasionally load
| up sublimetext for find/replace - but still feel that more
| visual / wysiwyg type stuff is greatly desired by much of the
| world.
|
| Wordpress is going more in that design direction as the
| gutenburg blocks start to work with full site design and not
| just page content. And I still keep meaning to take the time
| to try out pinegrow site builder - as that might be the
| replacement for netobjects that I've longed for.
|
| But it's not just me - there are plenty of people who could /
| would make a site and find things too complex today - about 7
| years ago I found someone in the top 3 search results for a
| home service - and inquired about their designer / seo .. The
| guy who was there doing the work told me he made the page in
| microsoft publisher.
|
| While I'm not advocating for the bloat that Msoft's frontpage
| pushed into the world, and I know the time of clearpixel
| alignment is a distant memory, even though we have an
| infinite amount of tools - it still seems the front end world
| is more complex than it needs to be.
|
| It is better in some ways and worse in others. I hope CSS
| gets better menu options so there can be less pieces needed
| for a decent puzzle. I like non-js sites just fine, and
| building with less tools is okay too.
| martinald wrote:
| I agree entirely. The worst sites are imo the ones not using
| modern frontend technologies.
|
| I think people are forgetting how bad it used to be. Loads of
| jquery spaghetti code everywhere rerendering the page 1000
| times with a nested for loop.
|
| Also, web applications have became so much more complex than
| they were (but still work!). Things like Figma would be
| unthinkable even a few years ago. And - even though it's
| running in a browser Figma feels far more responsive than
| Illustrator or Fireworks (RIP), plus it has a load of
| collaboration tools which these desktop apps don't have.
| onli wrote:
| What aspect of Figma do you mean? Placing elements on a
| canvas has been possible almost forever...
| have_faith wrote:
| Figma makes heavy use of WASM, WebGL and Web Workers it's
| much more complicated than just rendering some shapes on
| a canvas with a scene graph.
| alerighi wrote:
| We have to distinguish websites from web applications.
|
| Websites have no reason to use JavaScript. They should be
| a collection of documents, possibly generate dynamically
| on the server side, but to the user HTML+CSS that can be
| viewed in a browser, downloaded with curl, viewed as
| source code, etc.
|
| Web applications have no reason to exist. Basically we
| are turning the browser into a JVM, a way to run code
| portably. But this have nothing to do with the web! It's
| just bytecode loaded from a remote server. What Figma, or
| GMail, or Google Docs has to do with a website? Nothing.
|
| These things shouldn't be implemented in a browser, it's
| not the right place. These problem should have been
| solved at the operating system level, but it was too
| difficult for Microsoft to agree with Apple and the open
| source world on a portable operating system interface to
| made possible universal binaries among platforms, with
| maybe a bytecode, maybe a way to load code from an URL.
|
| No they couldn't agree, so they took the only really open
| standard, the web, and bloated it, basically making it an
| operating system (well, Google even made it really one!),
| what's the point? That now most people run Windows or
| macOS with on top a browser (probably Chrome) into which
| they run 95% of the software that they use. Does this
| make sense? To me is a huge inefficiency, that only makes
| things slower, slower than they were in the 90s to me
| (even if we have order of magnitude more powerful
| hardware using the GMail web interface feels slower than
| what it was using Outlook on Windows 98).
| onli wrote:
| That might change the limit on how big the UI can be, but
| it changes nothing fundamental. As far as I'm aware of
| what Figma can do (we use it at work but I use it seldom
| directly), you could implement the same thing with DOM
| elements or simply with SVG. It's not fundamentally
| different to the Pipes UI I did implement with Raphael.
| bilater wrote:
| This. People see one shitty implementation of SPA and put
| every new tech stack in the same bucket. We live in a golden
| age of tooling and the front end is right at the front (pun
| intended).
| macintux wrote:
| > My users are happy.
|
| Are they? I'm skeptical we can know that for any given website;
| specifically, accessibility is a huge pain point for so many
| sites, and it would seem difficult to know how many people are
| turned away from a site because it isn't set up to serve them.
| pytlicek wrote:
| Can't agree more on this...
| davedx wrote:
| Personally I think most of the "failures" out there are caused
| by organisational issues not technology issues. Namely,
| marketing departments given all the power over what the website
| does and what's bundled with it (trackers, a bunch of
| heavy/intrusive marketing tools), and optimisation that values
| increasing revenue above increasing actual usability.
| (Sometimes these align; often they don't).
|
| You can make a SPA that's a joy to use and loads and runs
| extremely fast. Hardware has never been faster; browsers and
| application frameworks have never been as good as this (I'm
| talking about the web stack). It's really _nothing to do with
| the tools or technologies_ that marketing insists it needs
| mixpanel, GTM, optimizely, hotjar, FB pixel, smooch, and god
| knows whatever else in order to do its job effectively.
| 1337shadow wrote:
| I think modern FE won over is primarily because it provides
| with Decorator OO, which has been recommended for GUI
| development including by the GoF for ages, which also matches
| perfectly with a tag-based declarative language such as HTML.
| As such, ditching the "HTML templates" paradigm was a no
| brainer for OO devs to start with. For many, "templates", their
| performance, their restricted mini language and all the
| boilerplate that comes with it, just had to die.
|
| But then, with Angular/React/etc, you now not only have 1
| project on your hands but 2 different projects that must be
| compatible: the backend and the frontend. These 2 different
| projects ought to be in 2 different languages, unless you are
| developing backend in JS too - maybe there's even an ORM that
| can generate migrations these days for NodeJS ! But that wasn't
| the case last time I checked, also loosing the ability to have
| server side rendering without the additional effort of
| deploying a rendering server with all that comes with it.
|
| People ditched jQuery saying that vanilla JS was just fine, but
| it turned out not to be quite the case so there are still
| releases of jQuery, and at the same time NodeJS was released
| and npm and then Angular/React/etc which in my opinion created
| with two goals in mind 0. having OO components for GUI dev and
| 1. offer IoC to overcome the difficulty of dealing with custom
| component lifecycle like in jQuery which leaves you to monitor
| the DOM and instantiate / destroy each plugin by yourself. Idk
| if there are other reasons, but it seems to me that apart from
| that, that DHTML is still pretty much the same: you're adding
| some logic to change tags and attributes, anyway.
|
| Today we have a chance to break these silos again with the Web
| Components and ESM browser feature and W3C standard because it
| does solves elegantly the problems that React/etc seemed to be
| designed for and do no impose a frontend framework, you can
| just load the script in your page and start using <custom-tag
| your-option=...>... The browser will manage the Component
| lifecycle efficiently, and devs can use it in their templates
| without having to load a framework so everybody wins.
|
| This is also a chance to simplify our code, levitate by
| throwing away dependencies. Of course if you want to do full
| client side navigation with an API backend you still can, but
| you can make generic components that you will also be able to
| reuse in other projects that do not use a particular framework.
| You need no tool to make a web component, this is an example of
| a jquery plugin that was ported to a web component which has no
| dependency, with browser tests in Python:
| https://yourlabs.io/oss/autocomplete-light/-/blob/master/aut...
|
| Webpack does a lot, still slow for development be we're seeing
| the light with Snowpack and esbuild, allowing to have webpack
| in production only (ie. to generate a bundle in Dockerfile) and
| benefit from actually instant reload thanks to ESM.
|
| So if you go for web components and snowpack, you get an
| extremely lightweight toolkit which I love that will work for
| every page that's not an overly complicated web app. But then I
| thought I actually don't have so much frontend code, it would
| be nice to have it along with the backend code, so we went for
| a python->js transpiler to develop web components in pure
| python which also replace templates, it was surprisingly fast
| to implement: https://yourlabs.io/oss/ryzom#javascript
|
| Is this improving the situation or not depends on your POV,
| heck I'd understand if you even hold it against me, but the
| frontend development tooling is still evolving for sure, and I
| can see how the browsers are doing efforts (except Safari) to
| simplify DHTML development, because:
|
| "There are two ways of constructing a software design: One way
| is to make it so simple that there are obviously no
| deficiencies and the other way is to make it so complicated
| that there are no obvious deficiencies." - C.A.R. Hoare, The
| 1980 ACM Turing Award Lecture
| JMTQp8lwXL wrote:
| If you adopt microfrontends, you can ship your app as N
| number of smaller bundles, instead of one monolithic bundle.
| The Webpack performance in this setup brings me joy. It's not
| 10ms to bundle, but 2-3 seconds cold boot in dev mode is
| completely acceptable, with rebuilds nearly instantaneous.
|
| This setup is described in more detail in single-spa's
| documentation.
| [deleted]
| 1337shadow wrote:
| Exactly, you can see that the webcomponent I linked is
| microfrontend. Interestingly, I first ported the code to
| StencilJS, but then it seemed the framework actually got in
| my way and I removed it, I prefer the code as is now and
| there's not even a build because it's vannillajs. You just
| add the script tag in your page and start using the
| <autocomplete-light...> tags with your options. I used the
| mdn custom element documentation without any framework.
| JMTQp8lwXL wrote:
| I like what I'm seeing in Web Component technology, but
| it's not fully there for me yet.
|
| Suppose your base Design System is web components. Most
| Microfrontend (MFE) teams will still pick up an off-the-
| shelf React, Vue, Angular, etc.
|
| But VDOM and web components don't always play nicely. If
| you have Parent-Child web components, specifically 1
| parent with N-immediate children, React can't resolve
| this gracefully. Every render past the first breaks with
| Stencil. That's a pretty significant issue, because
| (very) common components like Select dropdowns are
| modeled as 1 parent with N immediate children.
|
| So you can't any longer stay in React's declarative
| model. The workaround (last comment in issue) has you
| writing imperative code to fix the problem.
|
| It has that "using D3 in React" vibe to it. It works, but
| it's not nearly as elegant as if you had, say, a React-
| based Design System (but then, of course, all your MFE
| teams must use React).
|
| https://github.com/ionic-team/stencil/issues/2259
|
| Users have also reported the same analogous issue exists
| for using Web Components in Vue too, so it's not even a
| React-specific shortcoming.
|
| https://github.com/ionic-
| team/stencil/issues/2259#issuecomme...
| 1337shadow wrote:
| I don't think it matters so much for React/Angular/Vue to
| support web components because they will be dropped in
| favor of vanilla js just like jQuery has, thanks to
| Custom Element which is recommended for MFE, and ESM
| which will likely be. Mixing different frameworks is a
| promise that I don't care about, but you got some pretty
| interesting feedback about it, seems like it might as
| well take a few years of effort.
| antonzabirko wrote:
| You are confused about your comparisons because the largest
| reason for FE failure is bloated code, an unrelated problem to
| the dangers of C.
| danlugo92 wrote:
| Most of the issues I see in front end code are repeats of
| problems that were solved decades ago, some of them even 100
| years ago! (debouncing).
|
| No separation of concerns, no layers, or if there's layers
| there's controller code in view layer or view code in controller
| layer.
|
| etc.
| neilv wrote:
| Soon after Web banner ads appeared, researchers discovered that
| users quickly learned to tune them out.
|
| Sometime after that (after clumsy false starts), what used to be
| advertising people took over the nature of the Web.
|
| HCI and human factors engineering (i.e., technology in service of
| the user's goals) was largely forgotten, and UX (i.e., technology
| in service of the developer) was born.
|
| Be skeptical of most UX you've seen, since much of what we're now
| taught, much of what tools/platforms are available, much of what
| the jobs are... are now generations away from the needs of users.
| If you want to genuinely serve the needs of users, question
| everything, including all the implicit and explicit conventions
| of your field.
|
| Product concept and design are in some ways harder than they used
| to be, since, e.g., users' conceptual models, fashion, and
| available platforms/technologies have been shaped by a
| pervasively user-hostile and manipulative environment. But, as
| designers, you still have a lot of leeway to operate creatively
| within that. Question everything.
| zapzupnz wrote:
| Loads of comments in the Twitter thread trying to pin the blame
| on someone. It's product managers; no, its frontend developers;
| no, it's backend developers; no, it's users...
|
| An organisational way of thinking is to figure out whose blame it
| is and charge them with fixing it.
|
| Me, I don't give a crap who's to blame. Just fix it.
|
| Stop collectively waiting for someone to do something about it
| and _just do something about it_.
|
| Fix your own code. Make your own code better. Be an example to
| the world.
| tmwed wrote:
| what a dramatic and ridiculous statement. i suppose you could say
| i have a vested interest in holding an opinion like that. however
| the dude that posted that tweet is in the tech space, therefore
| (imo) excludes him from being "just a user of the internet".
| furthermore, REAL USER demands and expectations increased from
| native mobile app usage, so of course the complexity of
| pages/apps on the web have followed suit.
| aiisahik wrote:
| I can only think that modern power generation systems have
| failed. There are so many advances in power generation in the
| last 100 years - from nuclear, wind, solar, hydro, and even
| biothermal. Yet when I look around all there are so many dirty
| combustion engines and coal power plants spewing greenhouse
| gasses and toxic fumes.
|
| Both statements are moronic. Taking advantage of modern design
| philosophy, modern CDNs, modern framework - all of that takes
| time, attention and MONEY. If you don't put in the investment in
| all of these, the fact that you have access to "modern frontend
| development" is meaningless. It's like asking why is not everyone
| in the world driving Teslas.
| runawaybottle wrote:
| Media websites are a bad way to judge the state of web app
| development (which sucks for its own reasons). If you manage to
| hire good developers on a media site, they will try to optimize
| how ads and the endless list of third party libraries are pulled
| in.
|
| If you didn't get some dope developers then they will just half
| ass dump all of the stuff needed onto the page (which is why most
| of the the web sucks).
|
| What's worse is that these sites sit under a publishing/media
| business, so they aren't tech companies (the devs are second
| class citizens).
|
| Everyday I run into at least one site where they couldn't figure
| out a sticky header, or a decent 'accept-cookies' box (where it
| takes up half the screen, and when you hit X (if you find it), it
| stutters away, as if css transitions is a mind blowing concept).
|
| Then after that, the page _janks_ down as a whole ad gets
| rendered. Zero effort is being put in at some of these places. I
| would consider lazy loading content in the visible viewport _the
| moon_ for these sites.
|
| This is a necessary discussion because the web is becoming a tech
| slum with these poorly designed websites. To bring it back to the
| larger web development (both app and website), it can be
| difficult to suggest to a team a very simple question - 'Do you
| not see that the end result looks and feels like shit?'. It's too
| abrasive, but all of us need to start asking these basic question
| for quality's sake.
| rini17 wrote:
| Media are on shoestring budgets, unlikely to sustain good
| developers. But it's not only media, many other services
| neglect the user-centric optimization. That case is probably
| due to proliferation of various kinds of outsourcing/seo
| consultants whose interests don't overlap much with users'.
| bob1029 wrote:
| It's never too late to consider server-side web technologies (new
| or old).
|
| We would have closed up shop a long time ago if we hadn't
| discovered Blazor and all of the productivity gains that go along
| with it.
| BrandoElFollito wrote:
| I think that front dev is fantastic today, especially for amateur
| devs such as myself.
|
| I used to do some HTML and CSS 25 years ago and it was a
| nightmare to make it look like I wanted.
|
| Today I use Vue+Quasar and everything just works.
| antirez wrote:
| Regardless of my tweet, that is a personal opinion based on my
| feelings, background and experiences, the discussions in the
| replies are interesting from the POV of understanding what
| different people think in the programming community. Some will
| say that critiques are only from old people, in the style "when I
| was young we had only zeroes! You now have ones and zeroes".
| Others say that the web is slow because of ADs and trackers and
| modern frameworks would otherwise be fast. There is who believes
| that the problem comes from big companies imposing new standards
| in order to turn the web into the new Java applets (a full
| fledged application platform), and so forth.
| Waterluvian wrote:
| I think this is more about the limitations of our perceptions
| given we live such short focused lives.
| criddell wrote:
| If ECMAScript, HTML, and the DOM didn't exist and you were
| asked to create a specification for applications where the
| client UI is remote, possibly very resource constrained with a
| connection to the back end that may be slow and only mostly
| reliable, what would you invent? Is there a better model
| already out there that isn't used because Javascript + HTML has
| sucked all of the oxygen out of the room?
| bri3d wrote:
| Even Flex and ActionScript were better in many ways than the
| DOM.
|
| My big problem with web application (in a true application
| sense - not things that are just hypertext and shouldn't be
| applications at all!) development is that the DOM+CSS model
| is not made for rich UI experiences. Basic paradigms from
| desktop applications like spreadsheet cell selection,
| draggable cards (think Vizio/UML), modals, and MDI / multi-
| document interfaces are non-standard and brutally challenging
| to construct in a reasonable way using the DOM.
|
| What I'd invent would pretty much be Silverlight without the
| Microsoft, honestly - a typed UI framework built on a widget
| and widget-binding model which would allow a smooth mixture
| between OS-level widgets (and the accessibility affordances
| they provide) and hand-controlled rendering/drawing, with a
| stripped-down runtime enabling resource constrained clients
| to execute client-side code which would hide / paper over the
| resource constrained backend connection.
|
| Anyway, I also think this is orthogonal to the argument in
| this thread, because I think that most of the conversation
| and the sentiment of the original tweet is to call out
| applications that SHOULD be hypertext, not applications. For
| applications that need to be applications, I think things
| have gotten better, not worse, although they're still pretty
| bad.
| zokier wrote:
| Java Web Start was a thing, and had some nice aspects to it.
| JVM startup time has been a problem, and the UI toolkits
| maybe had some issues? And of course the early JVMs were
| notoriously full of security holes, which is something
| browsers somehow managed to avoid.
|
| But nevertheless I think Java/JAWS got basic stuff still
| right: run applications directly from network (with auto-
| updates), have security controlled sandbox, be fully cross-
| platform and portable, and have useful stuff built-in, and
| even had the PWA-like thing that you could have desktop
| shortcuts to JAWS applications.
|
| Regarding startup time, I do wonder what would be the startup
| time of your typical Electron app on a late 90s-early 00s PC
| hardware. Somehow I'm imaging JVM might not be that bad in
| comparison...
| tpmx wrote:
| The reason it's so hard to come up with a feasible
| alternative at this point is that we have done ~15 years of
| browser wars with perhaps an average of 3k "core"
| contributors (browser company employees etc) since "we" moved
| into this direction... pretty much by chance.
|
| My understanding from working at Opera at the time (2004 and
| onwards) is that the "senior" (experienced) people were busy
| implementing stuff in the browser engines and various GUI
| platforms. We hired very young (often like 17-18) and very
| smart people who had experience actually writing HTML/CSS/JS
| to work on developing web standards. They naturally typically
| had very little commercial software development experience.
|
| After a while it kinda became a competition - which browser
| company's web standards people would be leading in terms of
| ideas/innovations. How many web APIs could browser company A
| do, vs browser company B. That's when the complexity really
| started accelerating. Then Safari and Chrome happened.
|
| I wish we had spent more time working with these web
| standards people (we had so much experience building GUIs,
| for instance). They were really friendly and approachable,
| but we were all so busy with actually building the browsers,
| during these browser war times. It feels like a missed
| opportunity, in retrospect.
| Const-me wrote:
| Depends on use case, but for general purpose apps MS XAML
| platforms are IMO better. They were designed for rich GUI
| from the start and it shows.
|
| The main downside, they only work on Windows, MS once had
| Silverlight for Mac but it wasn't particularly good.
| pjmlp wrote:
| X Windows was an option back in the 90's, and with frameworks
| like Motif++ it was kind of ok.
| criddell wrote:
| Does X scale? Can you have thousands or even millions of
| simultaneous clients hitting a server?
| toast0 wrote:
| So, X flips the nouns, and the server is the part where
| the user sits, and the client is the part where the data
| processing happens.
|
| It used to be possible (and done) to have a thin client X
| server that would have the whole desktop running
| elsewhere. You could run a computer lab with a bunch of
| thin clients and a handful of desktop servers for lack of
| a better word. That was probably hundreds, maybe
| thousands.
|
| Since then, though, X moved a lot more work from the
| Xserver to the clients; text is almost exclusively
| rendered on the client and passed as an image to the
| server to display.
|
| If you did a classical experience, it might work ok to
| millions, but the user experience would have to be pretty
| meager. There's also the issue that there's not really a
| good way to sandbox different X clients; so nobody in
| their right mind would let a random internet server
| connect to their Xserver. Connectivity issues abound as
| well.
| notjustanymike wrote:
| I read it and feel it's the same as how we perceive modern
| music. Everyone says music "used to be better" but that's just
| survival bias. Just like music, there was a LOT of trash web
| development back in the day as well. Sites built with tables in
| dreamweaver best viewed on netscape navigator at 800x600 with
| animated gifs bogging the download speed existed long ago.
|
| What we have today are the same problems with a new wrapper,
| created by a not dissimilar group of people from the past.
| barrkel wrote:
| We had functional _applications_ for forms and the like, in
| the 90s, running on machines with 8MB or 16MB of memory. They
| weren 't as pretty, but they had simple development
| paradigms, VB and Delphi, easy to get started.
|
| HTML has been the wrong place to make creating UIs (as
| opposed to marked up text) for such a long time. Things are
| getting better from multiple angles, but it's still very
| uneven.
| notjustanymike wrote:
| It's always easy to solve a problem by taking away a number
| of it's requirements. VB was good at forms but visually
| unacceptable for branding. It was difficult and unsafe to
| deliver over the internet. And again, there were a LOT of
| really bad VB applications that hurt usability and
| performance.
|
| If all you're doing is building forms for an application
| then it's acceptable, but that's an easy problem solved
| with elegant solutions today as well. HTML can immediately
| deliver the styled application without installation to
| every device regardless of OS. It can propagate changes
| without reinstallation. It is accessible for every kind of
| user. And it does this while looking miles better than any
| VB application.
| anthk wrote:
| >And it does this while looking miles better than any VB
| application.
|
| Far less usable too.
|
| > It was difficult and unsafe to deliver over the
| internet
|
| No one cared, we had physical media.
|
| > And again, there were a LOT of really bad VB
| applications that hurt usability and performance.
|
| Most of them were fast enough.
| tshaddox wrote:
| I definitely agree with the music survivor bias thing. This
| is also very noticeable in the "computer generated imagery in
| movies looks artificial" meme: you just didn't notice all the
| extremely effective and convincing CGI.
|
| But I'm curious, what are the examples of great websites
| "back in the day" that _have_ stood the test of time and
| would be considered good web development today?
| derwiki wrote:
| Craigslist
| notjustanymike wrote:
| You're on one right now. Although it'd benefit from some
| mobile compatibility...
| bombcar wrote:
| Wikipedia and Zombo.com haven't changed much.
| antirez wrote:
| I have a different opinion. When we moved from the old way to
| semantical HTML5 generated still server side but which the
| layout was defined by the finally mature CSS, with the
| dynamic parts handed by JavaScript and RPCs, everybody agreed
| it was better. Such web was faster, more compatible, simpler
| to parse, and so forth. I think that, if in the 20 years that
| followed, frontend development would progress in the same
| direction of improvements, everybody would agree again now.
|
| And indeed everybody agrees that JavaScript itself is now
| better as it is the modern web APIs. If the rest is so
| controversial there must be a reason.
| arcturus17 wrote:
| I've heard and read stories from seasoned engineers, here
| on HN and elsewhere, that say that FE dev was as prone to
| tire fires back then as it is now, so I don't think that
| point is as incontrovertible as you claim it to be.
|
| Some of those seasoned old-school engineers have, believe
| it or not, embraced modern FE frameworks and architectures
| and wouldn't go back to the old thing if you paid them to
| do so. I've seen testimonials here on HN and surely it must
| be a factor in the world moving in this direction - it was
| not the juniors who made these decisions after all.
| antirez wrote:
| My point is different: I said that true evolution from
| tables to create the layout, continuos refreshes of the
| page to update the state, to a better development
| environment was universally recognized. And if it was
| again a case of good design, everybody would see it. If
| many voices are talking about over engineering now I bet
| there is a reason.
| throwawayfire wrote:
| > Everyone says music "used to be better" but that's just
| survival bias.
|
| Not "just" survival bias.
|
| I think it's quite reasonable to take a position that there
| was more innovation and creativity in pop music in 1950-2000.
|
| As the genre has matured, popular/commercially successful
| music has depended more and more on fewer and fewer
| producers.
|
| Indeed, there are fewer commercially successful artists: the
| US Billboard Hot 100 Top 20 this week contains 3 tracks by
| Justin Bieber, 2 by the Weeknd, and 2 by Drake. That would
| have been unheard of.
| notjustanymike wrote:
| Good, and commercially successful, don't always go
| together.
|
| Amazon is commercially successful but few would argue their
| UX is good.
| mitchdoogle wrote:
| Do we know what the UX goals are for the site or what
| requirements they had? It's really difficult to gauge
| these things if we don't even know what they're going
| for.
|
| Personally, there are some things I have found difficult
| to do (getting a chat going with a customer service
| agent) and some things that are very easy (checkout
| process, making a return). It's no surprise to me that
| they would make it slightly more difficult to find a live
| person to chat with since they probably want me to
| exhaust the other automated methods of solving my problem
| before doing that. Is that bad UX? I don't think so.
| frosted-flakes wrote:
| Amazon's user experience is fantastic. Why else do you
| think they are so commercially successful?
| toast0 wrote:
| The big one that always gets me is sort by price doesn't
| actually sort by price. Or at least, not the price I care
| about (which is price for condition new, seller Amazon).
| TheOtherHobbes wrote:
| Consumer logistics - which rely on not paying drivers and
| warehouse people much, and forcing them to work insane
| hours.
|
| And AWS.
|
| The web store UX has become appallingly bad -
| unreliable/fake reviews, tens/hundreds of sellers all
| roboselling the same identical items from China, poor
| quality items, unreliable/poor product search ("10TB
| external hard drive" shows... not many 10TB external hard
| drives). And so on.
| notjustanymike wrote:
| Amazon pages are a cluttered mess, but they are a
| -familiar- cluttered mess because everyone has used
| Amazon for so long. Amazon succeeds in spite of its
| design, because everyone has become familiar with how it
| works. This approach would not work outside of Amazon,
| which Nielsen Norman discussed some 15 years ago
| (https://www.nngroup.com/articles/amazon-no-e-commerce-
| role-m...)
| mitchdoogle wrote:
| I wonder how this might read if written now, rather than
| 16 years ago.
|
| NNG often say to follow conventions and Amazon has been
| leader for so long now that I can't help but think they
| have established many conventions now that might have
| been viewed negatively 16 years ago.
| rsj_hn wrote:
| > Amazon pages are a cluttered mess
|
| Ahh, you want "clean" design where maybe there is just
| one box with beautiful font and not all these options
| "cluttering" things. You want those options buried in an
| option tree maybe 8 levels deep.
|
| Well, I'm pretty sick of this minimalist design
| philosophy that requires 10x more clicks to accomplish
| anything because a designer decided the original was just
| too easy to use and wasn't "engaging enough" to generate
| enough clicks. They have made the web a much worse place
| for getting stuff done online, and it's no wonder that
| Amazon, the home of one-click purchasing, has continued
| optimizing for having the UI get out of your way and
| accomplish the most with the least effort rather than
| building attention-seeking UI "experiences" that require
| lots of interactivity to get simple things done.
| toyg wrote:
| _> it 's quite reasonable to take a position that there was
| more innovation and creativity in pop music in 1950-2000._
|
| A lot of people said the same in 1990, except their cutoff
| was 1980. All that synth is just rubbish, man, what about
| Led Zeppelin, _that_ was new! Except they were just raiding
| blues and laying some electric guitar on top, of course, so
| really the cutoff is 1960; but to be honest them bluesmen
| were just recording stuff that had been sung in the cotton
| fields forever, so really the cutoff is the beginning of
| the slave trade; but really those melodies were just
| brought all the way from Africa, so really... etc etc etc
| throwawayfire wrote:
| I think this essentially agrees with my point (that there
| was more creativity in the broad space of 'pop music'
| when pop music was a newer phenomenon).
|
| I appreciate the reminder that a lot of pop music has a
| longer history as it developed from Black music styles.
| Thanks.
| bryanlarsen wrote:
| I think you've got that completely backwards. 2000 is about
| the time that the "long tail" exploded, where Youtube and
| Spotify made non-top 40 music a lot easier to find. In
| consequence there is a lot more really good music available
| today than there was pre-internet and it's a lot easier to
| find. It's not on the radio, but that's always been the
| case.
| BolexNOLA wrote:
| Exactly. One only has to look at the myriad of tv shows,
| video games, movies, etc. to see that we have more
| quality options than ever and are seeing even more niche,
| but commercially successful content. There's more static
| too, but there's a lot of good out there.
| pessimizer wrote:
| I don't think so at all - there's a lot of pastiche, some
| of it loving, but there's only so many ways to do a pop
| song. It's alright for forms to die. The real "long tail"
| that the internet introduced is that we now had access to
| all of the good music we missed before the internet.
| There's no reason to bitch about modern music anymore
| because there's no reason to be exposed to it other than
| aggressive fandoms and marketing.
|
| I honestly don't even understand the impulse to listen to
| new music. The quality of "newness" is not a desirable
| one for me in music; I prefer qualities relating to
| sound. To me it seems like a distorted version of the
| impulse to be cool in high school.
|
| The real problem is that commercial, recorded music
| crowds out local, live music. For local music I
| understand wanting to know what's new - you may miss out
| because bands aren't live forever.
| mycologos wrote:
| > In consequence there is a lot more really good music
| available today than there was pre-internet and it's a
| lot easier to find.
|
| Tangentially, if (like me) you find this "long tail"
| interesting but don't know where to start, I've enjoyed
| going through Ted Gioia's "100 Best Albums of [previous
| year]" [1] each year. It's obviously subjective and
| subject to whatever biases he has, but the sheer
| diversity of the list is quite cool. Listening to a few
| albums per week is a pretty easy way to sample -- most of
| the albums are on YouTube or Bandcamp for free.
|
| [1] http://tedgioia.com/bestalbumsof2020.html
| anthk wrote:
| And before, soulseek.
| brayhite wrote:
| > Indeed, there are fewer commercially successful artists
|
| Source?
|
| I reckon every decade had a handful of artists dominate the
| charts, so it wasn't unheard of at all to see multiple
| chart toppers by the same artists at any given time. In
| fact, given the gatekeepers of popular music largely were
| concentrated around radio DJs and the "industry machine" of
| record labels, I'd hypothesize there's a larger on average
| number of unique artists in the top 100 since the 2000s
| than before.
| throwawayfire wrote:
| >Source?
|
| https://www.billboard.com/charts/hot-100
|
| You can change the week yourself.
|
| If you pick a few random weeks before 2000, you likely
| won't find this pattern that I identified, with the same
| artist in the Top 20 multiple times.
|
| If that's not enough evidence then there is a Python web
| scraper: https://github.com/jocelyn-ong/data-science-
| projects/blob/ma...
| coldtea wrote:
| > _I read it and feel it 's the same as how we perceive
| modern music. Everyone says music "used to be better" but
| that's just survival bias._
|
| Well, if the top 100 tracks from, say, 1961 to 2021
| progressively get less musically diverse, with simpler
| chords, less harmonies, less timbral variety, lesser
| melodies, more repeatition, less dynamics, less genre
| variety, more infantile lyrics (something that has been
| studied and measured several time, e.g: ), etc, then it's not
| some "survival bias".
|
| https://www.researchgate.net/publication/346997561_Why_are_s.
| ..
|
| https://newatlas.com/pop-music-trends/23535/
|
| https://www.nature.com/articles/srep00521
|
| https://www.res.org.uk/resources-page/economics-of-music-
| cha...
|
| https://pudding.cool/2018/05/similarity/
| bryanlarsen wrote:
| To be fair, you have to adjust for the relevance of top
| 100. In the past the top 100 was the only thing most people
| were exposed to because that's all the radio played. Today
| Spotify and Youtube and their recommendation algorithms
| make the top 100 almost completely irrelevant.
| radicalbyte wrote:
| The size too: there are far more songs released now than
| in the 1960s. So it makes sense that the "creme" on the
| top is more homogenised.
| zepto wrote:
| Why does that make sense? More available music should
| imply a more varied range of good music to rise to the
| top.
| yazaddaruvala wrote:
| It reminds me of why Apple Pie is America's favorite pie.
|
| 50-100 years ago when parents were deciding what pie to
| make or buy, parent's favorite was X, eldest kids
| favorite was Y, youngest kid's favorite was Z.
|
| Parents instead bought Apple Pie, because it was in
| everyone's top 5 favorite pies.
|
| Top 50 is an average of all of the world wide listeners.
| No one's favorite songs are in the Top 50, but they are
| the average top 50.
| bobthepanda wrote:
| Not necessarily. That might be true if the top X you're
| tracking is also expanding along with the size of the
| catalog, but isn't true if X is fixed, like a top 100
| music chart.
|
| More common variants of more popular genres could easily
| crowd out moderately popular genres. The long tail has
| been a long noted issue at Spotify with several attempts
| at fixing.
| kragen wrote:
| It happens in some simplified models. Suppose a thousand
| tracks get released every year, and these tracks are
| evenly divided among 50 different types of music, 20
| tracks per type. Some of these types of music are very
| popular (4.95 stars), some are slightly less popular
| (4.90 stars, maybe because they offend some powerful
| group), and some are much less popular (4.00 stars). So
| the most popular 100 tracks will be the 20 tracks from
| each of the 5 most popular music types.
|
| If we increase the number of tracks to ten thousand,
| there are a couple of ways we can go. We could increase
| the number of types of music to 500, and in that case,
| we'd see better music rising to the top. (Or at least
| more popular music, which may or may not coincide with
| being better.) Or we could increase the number of tracks
| per type to 200, in which case a random half of the
| tracks of the most popular 4.95-star music type will be
| the "top 100" for the year.+ Or we could go for the
| middle of the road: maybe now we have 150 types of music
| and 67 tracks of each one. Or we could have musicians and
| record companies that respond to incentives by trying to
| produce more music of the popular types, somewhat
| handicapped by the fact that those popular types change
| every year, and however much Nickelback might try it,
| recording the same song under twenty different titles
| doesn't actually give you twenty top-ten hits.
|
| Regardless, there are a lot of ways that more published
| music could _both_ provide more variety _and_ less varied
| top hits.
|
| ______
|
| +Of course the Billboard Hot 100 is per week, not per
| year, but that's the least of the oversimplifications in
| this model!
| sdfhbdf wrote:
| The articles you're linking are proven to be
| misrepresenting.
|
| They for example look at a really small subset of music
| "Million song dataset" and only analysed basic metrics that
| could be automatically measured. To be honest I think the
| linked Spanish paper and the senationalist "Science proves
| modern music is bad" should be retracted since the
| methodology is flawed.
|
| Don't take my word for it, take Tantacrul's - composer,
| video creator, Design Lead for MuseScore [0].
|
| It's such a complex topic to study "music" - you have to
| narrow it down - genre, country of origin, purpose - it's a
| major simplification to say that "all music is worse now",
| there are a lot of types of music that didn't exist in 1961
| (synths, electronic, hip-hop) - how can you compare it?
|
| [0]: https://www.youtube.com/watch?v=VfNdps0daF8
| moron4hire wrote:
| Really love Tantacrul's video on this. I was actually
| about to look for it to reply to the grandparent post
| when I saw your post.
| anthk wrote:
| >(synths, electronic, hip-hop)
|
| Synth began in the 70's, and Moroder/Jarre is far better
| than the 90% of today's crap.
| cuddlecake wrote:
| If it's better than 90% of today's synth music, does that
| mean that 10% of today's music is better than
| Moroder/Jarre?
|
| That's a lot!
| coldtea wrote:
| No, just means it's equal but derivative...
| coldtea wrote:
| > _The articles you 're linking are proven to be
| misrepresenting._
|
| Citation needed. The articles are actual proof and
| measurements, whereas Tantacrul's take is just an
| opinion.
|
| > _They for example look at a really small subset of
| music "Million song dataset" and only analysed basic
| metrics that could be automatically measured._
|
| The "small subset of music" is the most popular music of
| any year. That is what reveals music tastes over time,
| and this is the kind of music that permeates culture.
|
| As for the "basic metrics" there's not basic as in
| trite/insignificant but basic as fundamental.
|
| It's just that some people want so much to cling to "each
| period is the same, there are no ups and downs in
| cultural production" to not be seen as backwards
| oldsters, whereas milenia of history teaches that that
| there are absolutely ups and downs in cultural production
| (periods of stagnation, etc).
|
| > _it 's a major simplification to say that "all music is
| worse now"_
|
| It's also a strawman. Nobody said that here.
| debaserab2 wrote:
| The top 100 hasn't been a relevant indicator of modern
| music since Napster. The top 100 is a record industry owned
| entity with a tremendous amount of self-interest.
|
| If you can't find more diverse modern music than the top
| 100 offers today you're not trying that hard.
| coldtea wrote:
| That's neither here, nor there.
|
| This is not about being able to find this or that niche
| musician that's great or even greater than any in the
| past, but about what the masses listen getting worse.
|
| Music isn't just a solitary experience, but also a part
| of general culture.
|
| As streamed music is getting cruder over time, the
| majority of the people are listening to increasingly
| shitty songs. That's chilling, regardless of whether
| someone can find 10000s of niche bands to listen
| themselves.
| debaserab2 wrote:
| It's reductive to suggest that the top 100 represents
| "general culture" (whatever that ambiguous term means).
| There aren't solely niche musicians outside of the top
| 100. Theres plenty of musicians with millions of
| listens/views on streaming media that don't enter
| billboard lists that have extremely prodigious careers
| that have complex lyrics, use a wide assortment of
| instruments/equipments, evolve genres, etc.
|
| Your data might be objective, but it's still a narrow
| slice of a much broader ecosystem.
| wilsonrocks wrote:
| I guess this depends on 'musically diverse' === 'better'
| though, which isn't necessarily the case when people think
| about what makes the top 100 tracks for a year.
| sosborn wrote:
| The thing about music is that "more complex chords, more
| harmonies, more timbral variety, etc..." doesn't say
| anything about whether or not the music is better. It's a
| silly pursuit anyway given that music is a subjective
| experience.
| coldtea wrote:
| That's neither here, nor there.
|
| This is not about whether or not this or that particular
| song is better, is the top (most listened/streamed/talked
| about) music in general losing variety in all these
| aspects (harmony, melody, timbre, lyrics, genres,
| dynamics, etc).
|
| That's not subjective, that's objective, and has been
| measured to get worse.
|
| The "subjective experience" could be good, the same way
| people can prefer McDonalds over a wholesome meal by the
| best chef. Doesn't mean its also good by other metrics,
| and I for one don't believe individual taste is
| everything. There are people with shit taste, loads of
| them.
| sosborn wrote:
| Again, "worse" is subjective.
|
| Even saying someone has "shit taste" is subjective.
| coldtea wrote:
| In the end, everything is subjective, even morality.
| There's no objective physical law that says killing is
| bad. Animals do it all the time and could not care less
| about it.
|
| But to the degree that we have a culture, though, we also
| have a non-100%-exact but nonetheless existing hierarchy
| of artistic works. There might be disagreements, even
| strong ones, but there's also some general agreement,
| that not everything is a fuzzy blob of equal value, left
| for the individual taste to sort or not, and this just
| for itself.
|
| Is the idea that the Beatles are better than The Monkeys
| or Oasis, that Aphex Twin is better than Skrillex, that
| Dua Lipa is better than Justin Bieber, that Michael
| Jackson is better than Milli Vanilly, in some non-
| measurable but tangible way really that difficult?
|
| That this, once a common and well accepted idea (related
| to the idea of the "canon"), appears like beyond the pale
| for the 21st century solipsistic individual, where only
| the subjective taste matters, is not really the fault of
| the idea itself.
| mitchdoogle wrote:
| I wonder how deeply tinted your rose-colored glasses need
| to be to go to these lengths to prove that things were
| better back in the day.
| krrishd wrote:
| OTOH, i think you can actually measure the quality and
| accessibility of tooling based on how abundant the long tail
| of mediocrity/low-quality output there is.
|
| in music's case, one of the replies to this comment describes
| decline in musical complexity/sophistication, which i'd
| personally attribute to _democratization_ of the tools (which
| are also much more powerful, allowing kids w computers to do
| what took whole teams and studios full of equipment before).
|
| so i think only seeing high quality UIs in the wild is more
| of a mixed bag than is intuitive to us -- a world absent of
| shitty soundcloud rap is a world with worse music tooling.
| Drew_ wrote:
| > Others say that the web is slow because of ADs
|
| This is pretty much objective truth in my mind. I might agree
| with people who hate the web if I always had to browse with ads
| enabled.
| arcturus17 wrote:
| My worst experiences in the web come from mobile media (news)
| sites where I can't block ads. They are absolute dumpster
| fires.
|
| Everything else, including the aforementioned sites when ads
| are blocked, is pretty decent in my experience.
| LandR wrote:
| I run no script, if i cant get it working allowing no or very
| minimal js, i close the tab.
|
| Life is too short for shitty slow, bloated websites and buggy
| apps. Just dont use this trash, if the devs aren't going to up
| their game and prioritize user experience over profits then fuck
| them.
|
| The only way web developers are going to improve is if they start
| losing users and money. Until then they'll keep crapping out
| garbage.
| futureproofd wrote:
| I'd argue that life is too short to use no-script. And why
| point the finger directly at web developers. Product managers
| throw a requirement over the fence and web developers figure
| out how to satisfy their wants, while squeezed into sometimes
| unrealistic time constraints.
| aristofun wrote:
| Frontend development is fine. People failed at it.
|
| Like they always do at first in important things.
|
| And it's not even developers who failed, but users and managers
| who just don't care enough.
___________________________________________________________________
(page generated 2021-04-04 23:02 UTC)