[HN Gopher] Everything Easy is Hard Again (2018)
___________________________________________________________________
Everything Easy is Hard Again (2018)
Author : todsacerdoti
Score : 201 points
Date : 2021-04-17 17:16 UTC (5 hours ago)
(HTM) web link (frankchimero.com)
(TXT) w3m dump (frankchimero.com)
| vmception wrote:
| Everything this author complains about has a purpose.
|
| They don't have to use compiled, minified and obfuscated css,
| vectorized graphics, and user-agent detected custom fonts
|
| but if you don't, then you are unoptimized for other realities
|
| websites in the past used system fonts, you can still do that.
|
| websites in the past used low quality raster images, or high
| quality raster images. those websites don't look good at higher
| resolutions. conditional logic to fix those sites is messy.
|
| you can still make sites like that.
| dmje wrote:
| Potentially controversial view: it really doesn't matter how you
| do it and it probably never did. Dya think your audience knows if
| you're using tables or grid or flexbox or php or React or Flash
| or Perl or a huge image that looks like a web layout? Nope. If it
| works in a reasonable way, they're probably happy.
| mk81 wrote:
| TLDR: there is not _one_ _right_ way to do things and IQ follows
| a normal distribution.
| hivacruz wrote:
| > _simply npm your webpack via grunt with vue babel or bower to
| react asdfjkl;lkdhgxdlciuhw_
|
| Nice summary. While I understand that yarn was a good thing to
| integrate frontend dependencies management just like we do it for
| the backend, Webpack is still a mystery to me. Just trying to add
| a simple JS library to make it work is a headache sometimes
| (DataTable with Rails for example).
| jwilber wrote:
| I encountered the same trauma after building a react site and
| told myself surely there must be something more simple.
|
| Check out parcel! Zero configuration required, just add a
| couple of commands to a package.json and you're off.
| BiteCode_dev wrote:
| I fought with webpack for years, then ViteJS came out.
|
| It works out of the box, is uber fast, support Vue + React and
| does everything webpack did for me.
|
| I stopped thinking about my tooling and could go back to spend
| those CPU brain cycle on solving my clients problems.
|
| Peace of mind.
|
| Thanks Evan You.
| 5cott0 wrote:
| ViteJS is nothing short of a revelation. Recently migrated
| all my webapps from webpack5 to vite and it took considerably
| less time and effort than migrating from webpack 4 to
| webpack5 did, just removing babeljs reduced the dependency
| footprint by orders of magnitude. I just had to change a few
| filename extensions and even though my apps all use a custom
| react-like, JSX, css-modules, postcss, tailwindcss, d3.js,
| etc it just worked, I'm still kind of in shock over it. I'm
| always the one saying "webpack isn't that bad, stop being
| lazy" but no longer having so many config files and a 1k line
| package.json polluting project root is a thing of beauty.
| rossdavidh wrote:
| I think one driver of this cycle is:
|
| 1) need for capability that old method doesn't meet, so new tool
| is made
|
| 2) dev working on both simpler and more complex sites, wants
| everything to use the same tools
|
| 3) even sites with simple needs now get done using tools powerful
| enough to satisfy needs of complex sites
|
| 4) experienced dev doesn't see a problem, because they are
| conversant with those more complex tools, and also don't often
| get assigned to do simple websites anyway, but anyone doing the
| (considerably more numerous) simpler websites now is getting
| their groceries by flying a SpaceX rocket from home to the
| grocery store.
|
| 5) now that websites can do more, and very occasionally do,
| someone thinks of something else they want a website to do, and
| the cycle repeats
| ruffianeo wrote:
| I think you forgot one driver, which IMHO is a major one:
|
| Imagine you are just getting into the business and are
| confronted with complexities, which would let you come to a
| grinding halt for the next 6 months until you have at least a
| foggy idea of what is going on. (Angular, Elm, PHP, React, ...)
| And once you worked through your initial list of "need to
| know", 5 more have popped up, like a hydra where chopping off
| heads just results in... more heads staring at you.
|
| So, in this situation, it is quite reasonable to try and "get
| ahead of the curve" instead of lagging behind the ever changing
| world. You decide to write your own framework (based on your
| current and imperfect understanding), ignore what is already
| out there and pass the ball to anyone else. They have to look
| what you did now and read your stuff and scratch their heads,
| while you can be productive. And it feels good. You feel like a
| messiah. You can publish even a book, maybe and hold some
| enlightened talks.
|
| This is the result. New generations are literally forced into
| re-inventing the wheel to even stand a chance at getting
| something done.
|
| And its not only in web design/javascript/web-assembly/call-it-
| how-you-will.
|
| The same happened e.g. in the Microsoft ecosystem (desktop
| programming). MFC -> ATL -> VB6 -> .NET WinForms -> XAML ->
| Silverlight and back to XAML -> .NET core -> however it will go
| on (I detached at that point, having run 'too many laps').
|
| And since someone mentioned Linux... what is the canonical way
| to write GUI apps in Linux these days? Tcl/Tk? xlib? xcb?,
| SDL2, wayland over X? Gtk, that huge google framework? QT?
| SDL2? Motif? Pure wayland? Also a huge mess and people
| "innovating" just to be ahead of the curve. Yes, there are
| always reasons, if you need them to be...
| dleslie wrote:
| Linux is still very much GTK, Qt, and to a lesser extent, Tk.
| There hasn't been nearly as much rotation of core libs as
| there has been on Windows or the Web.
| loa_in_ wrote:
| > And since someone mentioned Linux... what is the canonical
| way to write GUI apps in Linux these days? Tcl/Tk? xlib?
| xcb?, SDL2, wayland over X? Gtk, that huge google framework?
| QT? SDL2? Motif? Pure wayland? Also a huge mess and people
| "innovating" just to be ahead of the curve. Yes, there are
| always reasons, if you need them to be...
|
| There isn't a canonical way - Tcl/Tk, Qt, Gtk, SDL, Java,
| pure graphics backend calls all continue to work. All as long
| as there's someone out in the world with enough dedication to
| them to keep them up to date. Linux ecosystem is not at mercy
| of Microsoft or Apple, thankfully.
| smoldesu wrote:
| The delineation of this argument is what made me switch to Linux.
| On Windows, things that should have been getting easy were
| getting harder for me: software management was getting worse,
| updates were getting worse, and everything that should "just
| work", just wouldn't. My experience on MacOS was just as bad,
| with all of the 32-bit apps I used gone in the wind. Now the
| 64-bit apps are up on the chopping block, and I had to look for
| other options.
|
| The learning curve for Linux was larger than Windows or MacOS,
| but I only learned the truth. By cutting away abstraction, I can
| actually understand what my system is doing, and be a better
| citizen of my operating system. Linux is arranged masterfully,
| and makes the Windows filesystem look like a joke in comparison.
| It's also faster than any of the Macs I own, with the freedom to
| plug in a modern Nvidia GPU and play whatever games I want.
| bestinterest wrote:
| I wish wish wish I could move over to Linux but its font
| rendering situation is terrible [1] I've tried Manjaro and
| Ubuntu to no avail.
|
| I have no idea what causes it or if people on Linux are not as
| sensitive to it or its a specific hardware setup which causes
| terrible fonts but once you read Windows fonts stuff looks so
| much better to me. Apparently its a hot debated topic but its
| so obvious to some it seems.
|
| [1] https://pandasauce.org/post/linux-fonts/
| christophilus wrote:
| I have a 4K and 5k display, and I find it as pleasant as my
| 2019 MacBook. I'm not sure if it's because I'm not sensitive
| to it, or what. (I'm using Fedora with Gnome 40.)
| wildmanx wrote:
| Wow, first time I hear that as the main and apparently only
| argument to using Windows over any Linux distro.
|
| With HiDPI displays all over the place, is subpixel rendering
| really still a thing? Pixels have gotten so small, I can't
| see individual ones anymore even if I'm trying. They could
| leave out anti-aliasing altogether in fonts and I'd hardly
| notice.
|
| Or I'm just getting old.
| smoldesu wrote:
| Most desktop environments will offer subpixel AA, and with
| GNOME and KDE, I think it's enabled by default.
| II2II wrote:
| I think that people are just too fussy. I have anti-
| aliasing disabled on my 142 dpi laptop screen and it looks
| better in most applications provided that screen fonts are
| used. Yes, you can see the pixels and you get the odd
| rendering artifact. On the other hand, the fuzziness of
| anti-aliasing is a steep price for edges that appear
| smoother.
| ahartmetz wrote:
| FreeType and slight hinting + subpixel antialiasing looks
| great to me, really... Windows has strong pixel-fitting and
| at the same time softer outlines. That is after using the
| ClearType tuner to tweak it to my liking. I'm not
| particularly fond of that look. You talk about hardware. The
| gamma of your screen makes a difference - antialiasing relies
| on it. The ClearType tuner has a page or three about that. I
| guess on Linux you better set your display gamma to the
| standard value, there is no good reason (except visual
| impairment or something) to set it to anything else anyway.
|
| By the way, font rendering in Chrome for Linux used to be
| really awful (no subpixel AA or something). It was fixed a
| few years ago - it looks like any other app now.
|
| I omitted some detail that you can easily find in your
| favorite search engine.
| riskable wrote:
| Hah: I am very particular about fonts myself but what bugs me
| most isn't sub-pixel hinting (which is "good enough" with the
| latest freetype IMHO) it's the size of fonts. Windows is so
| far off the mark on 99% of computers and it drives me crazy!
|
| Repeat after me: 72pt is one inch tall!
| 72pt is one inch tall! 72pt is one inch tall!
|
| The "point" scale of fonts is actually a precise, real-world
| measurement like inches, millimeters, etc. Fonts may differ
| in how much space each glyph takes up but in general they
| should at least be close to the correct size.
|
| Test it: Open up a word processor and load some reasonably
| normal font (e.g. Arial) and make some text that's 72pt. Then
| hold a ruler up to your screen: Is it about 1 inch tall? How
| far off the mark is it?
|
| If you're using a modern, high-DPI display it's probably
| waaaaay TF off, haha. Even with regular displays it'll be off
| and there's actually no way to fix it because you can't tell
| Windows the precise DPI of your display! It tries to guess
| based on the DDC data given by your display but then averages
| the X/Y together to scale fonts. So if your X DPI is higher
| than your Y DPI it'll always get it wrong. Always!
|
| Macs cheat in this area by always having displays of a fixed
| DPI. For the longest time all Apple displays were precisely
| 96 dpi (with perfectly square pixels) but recently changed it
| to 220-ish and made adjustments in their font rendering
| engine to match. I have no idea how they're handling non-
| Apple displays these days.
|
| Linux, on the other hand does it right (at least X11 and KDE
| do) in that it scales fonts very accurately based on the DPI
| presented by your display via the DDC protocol (or if your
| monitor doesn't provide that you can set both X and Y DPI
| manually).
|
| Gnome and GTK applications have the same problem as Windows
| though in that they only take one DPI setting and if the DDC
| protocol gives separate X/Y values it'll just average them
| and the results can be... Ridiculous. You don't really notice
| the weirdly-stretched fonts until you open a KDE application
| side-by-side with a GTK one.
| rhn_mk1 wrote:
| I have never seen a display with non-square pixels, except
| maybe on cameras. Where are those typically installed?
| zozbot234 wrote:
| CRT monitors will naturally display non-square pixels,
| depending on the resolution. Sometimes LCD's are run in
| non-native resolution due to GPU or driver issues, which
| results in a stretched display where the input pixels are
| not square.
| rzzzt wrote:
| CGA displays had non-square (logical) pixels. The ratio
| for 320x200 resolution is 1.6, but it is shown on a 4:3
| (1.333) screen.
| grawprog wrote:
| I love Linux based operating systems and I've used them pretty
| much exclusively for at least a decade now, and I agree with a
| lot of your post, but
|
| >By cutting away abstraction,
|
| I don't think I agree with this take. You haven't cut away
| abstraction, you've changed to a different kind of abstraction.
| Linux's 'everything is a file' abstraction is just that, an
| abstraction.
|
| >Linux is arranged masterfully, and makes the Windows
| filesystem look like a joke in comparison
|
| It's arranged more simply and straightforward, masterfully
| though, I dunno...
|
| Every flavour of Linux uses a different layout for its root
| directories, stores configs in different places and generally
| is not consistent from distro to distro.
|
| User configs are also scattered in random places at times. They
| could be in .config they could be in .local they could be in
| .$APP_NAME they could be in the app's directory, they could be
| in /usr/ somewhere. Maybe in a couple different places at once.
| Who knows? It's a mystery until you track it down.
|
| Dependencies and libraries are a huge pain to deal with,
| especially when you start mixing and matching distro provided
| libraries with custom built ones.
|
| I'm not trying to disagree with your post or anything. I love
| the way Linux lets you have control over your computer and
| doesn't try to stop you. But, it's definitely got some issues.
| I've only touched on a few related to your comment itself.
| CharlesW wrote:
| > _Every flavour of Linux uses a different layout for its
| root directories, stores configs in different places and
| generally is not consistent from distro to distro._
|
| As a very casual Linux user (macOS is my daily driver), are
| there any efforts to solve these "death by 1,000 cuts"
| arbitrary (I assume) differences?
| grawprog wrote:
| Not really no. The differences between distros are
| essentially rooted in philosophical beliefs defended by
| near religious zealotry. Entire identies are defined around
| the differences between distros.
|
| A bit of an exaggeration, but well...pretty much that.
| smoldesu wrote:
| These differences mostly come down to package manager
| variations, which should be one of the main considerations
| when picking out a distro in the first place. My personal
| advice is to use Arch/Manjaro with pacman, and avoid all
| snaps/flatpaks. The AUR is designed for people to integrate
| these apps like Spotify and Bitwig into the proper
| locations, instead of snaps and flatpaks making their own
| folders and such.
| em-bee wrote:
| i strongly disagree with this:
|
| _Every flavour of Linux uses a different layout for its root
| directories, stores configs in different places and generally
| is not consistent from distro to distro._
|
| there are differences, but it's 90% the same in the major
| distributions.
|
| and while you do have a point about user configs, it is
| getting better. .config and .local are getting used more and
| more and are an improvement over every app dropping stuff in
| $HOME.
| abnercoimbre wrote:
| > and while you do have a point about user configs, it is
| getting better
|
| Are people finally following the XDG standard? [0]
|
| [0] https://wiki.archlinux.org/index.php/XDG_Base_Directory
| em-bee wrote:
| i have no hard data, but my impression is that more and
| more apps are
| grawprog wrote:
| >there are differences, but it's 90% the same in the major
| distributions.
|
| Yes and that 10% can cause some unexpected, sometimes hard
| to fix problems. A poorly written build script or installer
| that expects a specific distro's directory layout can cause
| some problems. Especially if it's a large convoluted build
| system that hard codes the directories in multiple places.
|
| I've actually had to deal with this, it sucks. That was as
| an end user trying to use an app, not as a developer.
|
| You run into this a lot trying to build small libraries and
| stuff. There's unfortunately a lot of poor programming
| habits out there. Directories inevitably sometimes get
| hardcoded and this causes problems because of the
| inconsistencies between distros.
|
| >and while you do have a point about user configs, it is
| getting better. .config and .local are getting used more
| and more
|
| And yet there's hundreds of apps that will never be updated
| or changed to conform to standards.
|
| >are an improvement over every app dropping stuff in $HOME.
|
| Tell that to snap. It insists its folder must sit nicely in
| my home folder and nowhere else.
| em-bee wrote:
| _And yet there 's hundreds of apps that will never be
| updated or changed to conform to standards._
|
| i suspect many of those are no longer actively
| maintained. at best they receive security patches from
| distributions.
|
| _Tell that to snap. It insists its folder must sit
| nicely in my home folder and nowhere else._
|
| my (low) opinion of snap aside, the bad here is that the
| location is not configurable. as a library of
| applications, i would want snap in $HOME. or i would put
| it in $HOME/lib or an equivalent. maybe .local would be
| appropriate too, but i understand it's for app specific
| user-data, so it doesn't look like whole apps should be
| in there. (edit: elsewhere i just read that .local is
| supposed to be like a user specific /usr/local, so snap
| should fit in there somewhere)
| grawprog wrote:
| I don't want to turn this into a snap bad mouthing
| thread, but yeah. You can't even symlink it or it causes
| problems. It really bugs me because I don't tend to
| allocate too much space to my home partition and keep
| most of my stuff on data partitions. So if I get a bunch
| of snap apps, it starts eating up all the space in home.
| em-bee wrote:
| i hear you. in fact, i do use data partitions as well,
| and if my snap directory grew to much i would want to
| move it too.
|
| as a workaround try to use a bind-mount
| smoldesu wrote:
| I don't use Snap. The only real "bloat" in my home
| directory is my Bitwig folder, which isn't that bad
| considering I use the program on a near-daily basis.
| yarcob wrote:
| My early web dev experience was mostly just figuring out
| where the hell config and log files for apache, php and mysql
| were. If the docs told you the default location of the config
| file, you could be sure that on your distro they are
| somewhere completely different.
| grawprog wrote:
| >My early web dev experience was mostly just figuring out
| where the hell config and log files for apache, php and
| mysql were
|
| Yeah but once you track it all down you feel like a
| developer superstar genius...
|
| Then you confidently sit down and proceed to repeat the
| process on another distro and immediately feel like a
| complete noob again as nothing is where it should be and
| you realize, you mastered nothing.
| II2II wrote:
| > You haven't cut away abstraction, you've changed to a
| different kind of abstraction.
|
| Yes, Linux depends upon abstractions. Everything in computing
| is an abstraction, including those 1's and 0's that tell the
| processor what to do. (Anything below that is electrical
| engineering.) The differentiators are the complexity and
| stability of that abstraction. When people talk about
| "everything being a file", they are referring to lower level
| abstractions that are relatively simple and stable. Likewise,
| when people talk about HTML/CSS/JS they are referring to
| lower level abstractions that are relatively simple and
| stable. This is less true (sometimes significantly less true)
| when people start discussing frameworks/libraries, whether
| that's in Linux or web development.
| mikepurvis wrote:
| There's also a lot of sub-ecosystem issues which are more
| prominent on Linux, like the long-standing surprise that NPM
| doesn't have a global rc file in /etc:
|
| https://github.com/npm/npm/issues/533
|
| The argument from the maintainer is reasonable that distros
| can just patch it, but realistically, everyone wants a newer
| version of things than what their distros ship--a similar
| tug-of-war ends up happening in the Python world, where
| distros like Ubuntu and Debian ship patched versions of
| pip/setuptools, and then users are encouraged to self-upgrade
| those tools to the upstream versions.
|
| Anyway, this kind of thing isn't necessarily anyone's fault,
| but it is just a pretty different experience from Mac or
| Windows where you tend to have things be more self contained,
| like "here's where my Python installation lives because it's
| the path I put in the box when I ran setup.exe."
| smoldesu wrote:
| Node is definitely a bit of a mess, it's misuse of the
| Linux system doesn't really come as a surprise.
| toomanyducks wrote:
| Re: abstractions, I think what seperates Window/MacOS
| abstractions from Linux/UNIX abstractions is obfuscation. The
| aggressively closed-source nature means that *nix
| abstractions, to a reasonable degree, anyway, reflect the
| underlying structure in a way that closed source abstractions
| can't. Of course the file abstraction is an abstraction is an
| abstraction, but it's also implemented transparently as a
| concept in the kernel --- Whereas Windows manipulates their
| interface so that the interface _is_ the implementation, as
| far as the user can see and as far the user should care. At
| least, this is my experience, and it fits well with what I'd
| expect from the operating systems' respective development
| models.
| lelanthran wrote:
| > It's arranged more simply and straightforward, masterfully
| though, I dunno...
|
| It's easy to make "complicated". It's very hard to make
| "simple and straightforward".
|
| Whether that's an indication of mastery is not a closed
| question.
| tigershark wrote:
| >> The learning curve for Linux was larger than Windows or
| MacOS, but I only learned the truth. By cutting away
| abstraction, I can actually understand what my system is doing,
| and be a better citizen of my operating system. Linux is
| arranged masterfully, and makes the Windows filesystem look
| like a joke in comparison.
|
| What windows filesystem (FAT, FAT32, exFAT, NTFS) look like a
| joke and compared to which Linux filesystem? Ext2? Ext3? Ext4?
| ReiserFS? ZFS? It's pretty clear that you never used Linux in
| the 90's from your comment. And the main problem with Linux at
| the time had nothing to do with the filesystem but mainly with
| the immaturity of the complete system. I am very curious to
| understand what great truth you understood by using Linux.
| Would you kindly teach me this great knowledge and illuminating
| experience that I somehow missed?
| smoldesu wrote:
| > What windows filesystem (FAT, FAT32, exFAT, NTFS) look like
| a joke and compared to which Linux filesystem?
|
| I was referring more to the layout of the root directory
| (oftentimes referred to as "the filesystem", but now that you
| bring it up I also hate the Windows filesystems. FAT32 needs
| to go out to the pasture, and it wouldn't even exist if exFAT
| support was so broken on lower-end systems. NTFS is fine, but
| pathetically bare-bones. I'm a BTRFS evangelist, but even
| ext3 makes NTFS look old by comparison.
|
| > It's pretty clear that you never used Linux in the 90's
| from your comment.
|
| This is true.
|
| > And the main problem with Linux at the time had nothing to
| do with the filesystem but mainly with the immaturity of the
| complete system.
|
| "at the time" meaning 2018 or the 90s? Maybe 30 years ago
| Linux was immature, but now it's the benchmark of maturity.
| Very few *nix systems have share it's pedigree.
|
| > I am very curious to understand what great truth you
| understood by using Linux. Would you kindly teach me this
| great knowledge and illuminating experience that I somehow
| missed?
|
| Nope, probably not. If using Linux wasn't an enlightening
| experience because you last used it in the 90s or because you
| have an FAT fetish, I can't really help you.
| eliasbagley wrote:
| I would love to to use Linix as my daily driver, but keep
| needing to go back to Windows for Ableton and gaming.
| smoldesu wrote:
| I switched to Bitwig, which has a native version for Linux.
| The workflow is very similar to Ableton Live, with a little
| bit of extra configuration. As for gaming, it's a case-by-
| case situation, but Valve Proton is good enough for 80% of
| the games I like.
| enriquto wrote:
| You are spot on. And now, try OpenBSD. It's the next step in
| removing useless abstractions.
| bopbeepboop wrote:
| What are the BSD options these days?
| fordsmith wrote:
| I'm an avid Linux user, completely unfamiliar with BSD. Could
| you shed some light on how it further removes abstractions? I
| don't mind trying it out by booting it from a usb
| GeorgeTirebiter wrote:
| Linux is a large ecosystem, supporting many different
| functions (embedded to some extent; desktop; server;
| supercomputer clusters, etc). For any one of these, the
| other 'stuff' represents cruft. The BSDs (I am partial to
| NetBSD) tend to give you a basic substrate of 'the system',
| and you add what you need via 'packages'. It's a different
| philosophy, but no less valid.
| enriquto wrote:
| > Could you shed some light on how it further removes
| abstractions?
|
| By not running hundreds of useless programs, I guess. If
| you launch htop inside OpenBSD, it'll fill half of your
| terminal, and the rest is empty.
|
| The easiest way to try it is to install it on a virtual
| machine. You'll see that not much is needed to get to a
| point to launch firefox from an xterm.
| horlux wrote:
| but that's the case for some linux distros too, e.g void
| anthk wrote:
| Top itself is enough, you don't need htop.
| secondcoming wrote:
| I find htop's ability to view the tree structure of a
| process quite useful. Name your threads!
| enriquto wrote:
| Totally agree. But I'm somewhat used to silly things
| about htop, like selecting a process to kill using the
| arrow keys, or a default refresh rate of less than 1
| second.
| [deleted]
| dbolgheroni wrote:
| I don't know if you are talking about Linux the kernel, Linux
| the entire distro, Linux the filesystem (out of tens of
| supported filesystems), but "arranged masterfully" is big
| statement. From 2 days ago:
|
| https://news.ycombinator.com/item?id=26821298
| [deleted]
| grishka wrote:
| > My experience on MacOS was just as bad, with all of the
| 32-bit apps I used gone in the wind.
|
| Were you forced to update to Catalina? I'm still on Mojave
| right now. My 32-bit apps still work, happily unaware of the
| fact that they're no longer supposed to.
| matheusmoreira wrote:
| Linux is also stable. The binary interface isn't going to
| change. It's possible to write Linux software that you can boot
| directly into and it will never stop working or do anything you
| don't want it to do.
| dzolob wrote:
| I have been having a terrible time staying away from conda in
| windows, but the ridiculous amount of time and spent trying to
| install some python modules using pip is just not worth it.
|
| I'd be lost without wsl.
| 5cott0 wrote:
| No, no it is not.
|
| It's somewhat amusing to see people complain about the supposedly
| increasing complexity of web development. Sorry-not-sorry it's
| not that bad or even that complex. In fact things are far easier
| and less complex then they were just a few years ago and
| improvements continue at a rapid pace (modern browser module
| support, vitejS, ESbuild). I don't even need to use babeljs
| anymore whereas just a few years ago it would have been required
| for cross browser support.
|
| Developers as a cohort love to feel themselves and ego trip about
| how smart they are until they hit something they don't understand
| immediately and suddenly it's too complex and they have to write
| 5k words bemoaning webpack configs as the worst thing ever.
|
| I think the problem is actually the opposite and things are way
| too easy now because, like anything in life, effectively simple
| web development requires self discipline and simplifying
| abstractions like React make it too easy to just throw shit at
| the wall and see if it resembles a working webapp and then I end
| up having to maintain a lot of seemingly working apps that are an
| absolute mess of tightly coupled spaghetti code with no clear
| architectural design whatsoever but product thinks it works
| because the side effects show up at the right time.
| winphone1974 wrote:
| By what standard are you saying things are easier? Certainty
| not less complexity, abstraction, volume of code, number of
| moving pieces, raTe of change or configuration.
|
| If you don't understand how the foundational technologies work
| and don't care to learn then things may indeed seem easier. If
| you have 15+ years of experience and seek to understand today's
| technology at the same level as when you first learned, things
| are definitely harder.
| TheCoelacanth wrote:
| It's easier if you want to achieve the same things. Our
| expectations have just increased even faster than things
| became easier.
| 5cott0 wrote:
| IE7
| vbsteven wrote:
| If using babeljs for cross browser support is your starting
| point, then you likely started way later then the article
| author.
|
| Go back a few more years to 2005 or even earlier. If you wanted
| a website you installed Apache on a server (or used a shared
| hosting package), FTP your files to it and you're done. That's
| it. No pipelines, no builds, no package managers. Just files in
| a folder, that you copy to the server.
|
| If you wanted to do cross browser JS you downloaded the latest
| version of jquery.min.js, FTP it to the server and reference it
| in a script tag.
|
| I wrote my first websites in notepad.exe and used something
| like FileZilla to upload.
|
| That is what I call simple web development.
|
| I agree with the author that now things are just way more
| complex than they should be.
|
| edit: looks like jQuery was first released in 2006, which is 4
| years after Firefox was released, and 2 years before Chrome. So
| take my `2005` line as rough estimate.
| 5cott0 wrote:
| I don't think you're smart enough to make any inference about
| when I started.
|
| But if you insist on this crusty bonafides peen measuring
| contest I got started serving php via cgi on apache deployed
| with scp.
| vbsteven wrote:
| I'm not insisting on anything, sorry if I might have
| offended you, that was definitely not the intent.
|
| I assumed that you might have started later than the author
| because you compared the current state to just a few years
| ago, while the article mainly talks about even further back
| in history.
|
| The tools I mentioned were not meant for bragging. I just
| wanted to indicate that back then it was all way simpler,
| which you know as you apparently started in a similar
| timeframe to myself.
|
| The main point I wanted to make was that back then things
| were so much simpler.
| ur-whale wrote:
| I'm going to get downvoted into the the ground for this, but I
| think it has to be said:
|
| Front-end infrastructure and tools design unfortunately does not
| attract the cream of the CS graduate crop (and even less so
| Front-End design work).
|
| For some reason, cream of the crop CS graduates usually veer
| towards systems, compiler, DB, back-end infra, language design,
| back-end, ML, etc ...
|
| But not front-end.
|
| The net result: the front-end ecosystem looks like the first
| BASIC program written by a 10 year-old who just got his first
| computer: it's a mess, it's unprincipled, it's grown organically,
| it's driven by fashion and immediate business needs, it's an
| unmaintainable tarpit, and it's increasingly a nightmare to build
| with.
|
| I'm just ranting, I don't know what the solution is, but I gotta
| say: the WEB in 2021 is in a very sorry state.
|
| [EDIT]: and if I try to think of a root cause for this state of
| affairs, I believe a lot of the blame can be attributed to
| Javascript, a language which sort of gave the "slapped together
| quickly because we need something now, damned be the warts" tone
| for the entire ecosystem.
| [deleted]
| zeteo wrote:
| >the front-end ecosystem looks like the first BASIC program
| written by a 10 year-old who just got his first computer: [...]
| it's driven by fashion and immediate business needs [...]
|
| I also miss the days when 10 year-olds wrote BASIC programs and
| had immediate business needs.
| mLuby wrote:
| > I'm going to get downvoted into the the ground for this, but
| I think it has to be said:
|
| Ditto! All in good fun. 0:)
|
| > it's a mess, it's unprincipled, it's grown organically, it's
| driven by fashion and immediate business needs, it's an
| unmaintainable tarpit, and it's increasingly a nightmare to
| build with
|
| Can't tell if you're talking about front-end or back-end here;
| I've certainly seen both.
|
| > For some reason, cream of the crop CS graduates usually veer
| towards [back-end]
|
| Setting aside the implication that getting good grades in
| computer _science_ is the same as being good at creating
| business value with software, I see two reasons:
|
| 1. academic inertia: old professors teach what they know (e.g.
| lisp) regardless of how useful it is in the industry. I bet a
| rockstar professor who loved front-end/UX would find the cream
| of their crop biased toward front-end work.
|
| 2. this very bias you're perpetuating: where a bright student
| looks into the world, sees front-end work derided, and so
| steers clear of it (and maybe even starts parroting this bias
| of those they respect, as youngsters so often do).
|
| I don't know what the solution is, but it's definitely not
| whining. 0:)
| yowlingcat wrote:
| I dunno, this is the kind of opinion that seems trivially easy
| enough to falsify that I have to wonder about the real
| rationale behind it.
|
| If you take a look at the labor demand for skilled front-end
| engineering (https://www.levels.fyi/), it's hard to come to any
| other conclusion than that major companies pay a lot of money
| for top talent. So if major companies pay a lot of money for
| that talent, either they're making profit from a very tricky
| coordination of skilled labor, or you're pulling an argument
| out of an opinion that is at odds with the reality of the
| industry.
|
| Why do that? It could be that you're not familiar with how
| skilled frontend practitioners operate in large companies.
| Maybe that's why you're extrapolating (incorrectly in my
| opinion) that a) the web frontend ecosystem is trash and b)
| that is evidenced by cream of the crop CS graduates (???)
| choosing backend over frontend. My question is, what does that
| have to do with the reality of frontend today?
|
| Maybe it once was useful to consider why CS graduates
| gravitating towards one end or the other, but that division
| seems a little old in the tooth now. Good CS graduates these
| days have full-stack chops, and don't have too much trouble
| crossing devops, frontend, backend -- anything necessary to get
| the job done. So with that said, it's hard to consider your
| final conclusion anything than a rant about your own
| difficulties and preconceptions about frontend web development
| than anything:
|
| > The net result: the front-end ecosystem looks like the first
| BASIC program written by a 10 year-old who just got his first
| computer: it's a mess, it's unprincipled, it's grown
| organically, it's driven by fashion and immediate business
| needs, it's an unmaintainable tarpit, and it's increasingly a
| nightmare to build with.
|
| It's true that there's a lot of the front-end ecosystem that is
| super messy. But there's a lot of it which works a lot better
| in comparison to what was available a decade ago. Moreover,
| it's intrinsically gotten more complicated as mobile compute
| has gotten more powerful. Mobile has not just become a thing
| but achieved critical mass on par with desktop. There are
| enormously lucrative challenges involved with front-end these
| days, and who knows how much headroom is left in the industry?
| The modern phone's capabilities today are so far beyond what
| was possible even four years ago, that it's hard to consider
| these kind of rants anything beyond a lack of imagination.
|
| How is it that the largest megacap companies of our time are
| using better frontend experiences it to accomplish increasingly
| more revenue efficient activities than they ever have before?
| How is it that newly fledged startups are using the leverage of
| good frontend experiences to grow to $1B faster than they ever
| have before? Is it possible that UX and psychology account for
| far more of technology's value than you may be considering?
| Just a thought.
| jayd16 wrote:
| Eh, I think it has more to do with the fact the front end is
| the most visible to the product people. You get a lot of poor
| technical decisions to bend to the whims of the product design.
| Backend is usually free to do as they see fit.
| Sevii wrote:
| Yep, I decided to focus on backend to avoid dealing with
| requests to move pixels around arbitrarily.
| reader_mode wrote:
| Frontend has the problem of being stuck with JavaScript and
| DOM, even in the modern iterations it's a patchwork structure
| built on top of a cesspool - no wonder everything smells like
| shit.
|
| Agreed about the tooling, npm and node were basically hacks
| everyone kept building on - there is zero architecture behind
| most of it.
| crazygringo wrote:
| Regardless of whether or not your observation about CS
| graduates is true, I don't think that has anything to do with
| it.
|
| The difference is that with the backend, you have choice over
| what technologies to use. There's competition between languages
| and ecosystems, so a better more elegant one can replace a
| worse crufty one.
|
| But with the frontend, there is no competition. You _have_ to
| use HTML, CSS, and (roughly) JavaScript.
|
| If, when the web had started, it had been based on some kind of
| primitive bytecode for rendering, that HTML+CSS+JavaScript
| compiled to, then we could have had language competition and
| better technologies today. But that's not what happened. Front-
| end is stuck with an old, crufty tech stack that simply can't
| ever be replaced. Back-end doesn't suffer from that.
| zozbot234 wrote:
| What's wrong with HTML+CSS as a rendering primitive? It's
| quite successful in decoupling semantics from presentation,
| which is a requirement for a platform that's as widespread
| and universal as the modern web. JS is a bit crufty, but you
| don't _have_ to deal with it. You could write everything in
| some other source language and compile down to JS /WASM.
| (Even low-level languages like C/C++/D/Rust can support this
| via Emscripten.)
| crazygringo wrote:
| The article is almost entirely about what's wrong with
| HTML+CSS -- the frustration over whether to use tables,
| floats, flexbox, grid, or whatever will come next (as one
| example of many).
|
| HTML+CSS is a soup of overlapping technologies that has
| accumulated into this tangled ball of mismatched paradigms
| from nearly 30 years of "generational" improvements.
|
| I grew up with it from the beginning so I understand the
| reasoning behind it all. But to someone wanting to learn it
| from scratch, trying to decipher tables vs. floats vs.
| flexboxes vs. grids must seem like utter madness -- a
| layout language written by a truly insane person.
| craftinator wrote:
| > If, when the web had started, it had been based on some
| kind of primitive bytecode for rendering
|
| Which is WASM! Well, sorta.
| cblconfederate wrote:
| Most of the web runs php/jquery that's maintainable
| tarsinge wrote:
| For me it's kind of the opposite, the current state of front-
| end is clearly the result of bored overqualified CS graduates
| in overstaffed companies. I keep my sanity by working with
| people with a design background when doing front-end work
| because they usually rightly call out the unneeded complexity.
| xenihn wrote:
| >For some reason, cream of the crop CS graduates usually veer
| towards systems, compiler, DB, back-end infra, language design,
| back-end, ML, etc ...
|
| >But not front-end.
|
| im going to go out on a limb and guess that it's because non-
| mobile front-end work sucks. few people who have options would
| have it as their top pick.
| nrjklk wrote:
| much of the front-end complexity is driven by product people
| and designers who want to jam as much interactivity and visuals
| into the UI as possible. Also complicated front-end layouts are
| necessary to make room for advertisements - the main source of
| revenue on the internet!
| m463 wrote:
| > Things have gotten messy, haven't they?
|
| I have to give him credit though, his web page has zero
| javascript.
| kgin wrote:
| The simple page you could make 20 years ago is the simple page
| you can make today. With a few minor tweaks, it will work as well
| as it did 20 years ago.
|
| If you want to make a complex web app today, that's easier than
| it was 20 years ago. The tools are infinitely better.
|
| If for some reason you decide to use the tools meant for complex
| web apps to make your simple page, you're going to feel like
| everything has gone horribly wrong. But why are you doing that?
| taeric wrote:
| I don't know if I really agree. I want to. But flash was
| supported by much better tooling than what I see in most spots
| today. Dreamweaver, for all the hate we have it, seems
| laughable simple compared to common frameworks today.
| danShumway wrote:
| You can still use your old copy of Dreamweaver if you really
| want to. I think Adobe still sells new versions too. I
| wouldn't advise using website builders in general
| (Dreamweaver was always kind of sketch), and I certainly
| wouldn't advise using _Adobe_ software in general (they 're
| an awful company with overpriced products), but I can't
| imagine modern Dreamweaver has gotten particularly worse than
| it was before.
|
| You can't use Flash, that's fair. But my goodness, you
| wouldn't want to. The small amount of incidental complexity
| we've gained from forcing pizza shops to stop laying out
| their interface in Flash is worth it. And outside of the
| plugins that were absolutely the correct decision to remove,
| everything _else_ you want to use is still available.
|
| What we're getting at is that with a few exceptions (HTTPS,
| Java plugins, Flash), virtually all of the old APIs that you
| used to use on the web are still supported and are the exact
| same to use, if not better. This is not the case everywhere
| with every language and platform. But the web has done a
| reasonably good job at being backwards compatible.
|
| You're worried about deploy processes, and you want to deploy
| a free site on Netlify? You don't need to learn Git, you can
| hand-code your site in static HTML or generate it using any
| program you want and just upload it as a zipped folder. Your
| Dreamweaver builds will still run today. Font faces? Still
| work, you don't need to worry about FOUT. You miss table
| layouts? Hackernews is using that crud _right now._ The
| complexity around build tools, processes, and frameworks is
| all optional. The browser doesn 't care.
|
| If you're missing the old experience of building websites,
| then just do that. I maintain
| https://anewdigitalmanifesto.com. It is hand-coded HTML that
| I wrote in a text editor. It has no Javascript, no build
| process, no minification, nothing. And it works fine; no one
| has ever complained about it to me. If you're adding
| complexity to your engineering process and it's making your
| job harder instead of easier, then take a step back and ask
| yourself why you're adding that complexity in the first
| place. Is it solving a problem? Or do you just feel like you
| need to do things "properly" based on the current development
| style? Because again, the browser doesn't care.
| watwut wrote:
| Oh, you would want to use it. The games and similar mini
| software just don't have anything comparable to it.
|
| The loss of flash is very unfortunate.
| [deleted]
| galangalalgol wrote:
| The Ruffle project is trying to make a flash player with
| wasm. Mayne that at least can return.
| danShumway wrote:
| I loved Flash, deeply, I learned to program in Flash. But
| I am slowly in the process of doing a 180 on this, where
| before I felt like we had lost something with Flash that
| nobody had ever replicated. People have different things
| they liked about Flash. I liked the animation-centered
| workflow (and I still think there's room for innovation
| in this space with modern tools). I miss the ability to
| export vector animations.
|
| There's a technical hole that I still think could be
| filled by other programs today. But often, I hear people
| lamenting the loss of community and the loss of universal
| publishing.
|
| And on that note, aside from the animation-centered
| workflow, I'm less certain that the rest of that stuff is
| actually gone. Unity publishes to websites just as well
| as Flash did, if not better. Unity even lets you publish
| to Linux, which Flash never really supported well.
|
| And honestly, I'm not sure the community is dead either,
| it's just moved on to platforms like Scratch, Pico 8,
| Itch.io, and Roblox. I see very similar energies when I
| interact with people on those platforms. It's a different
| community, it's younger kids with different norms, the
| old generation isn't as welcome anymore. But I'm not sure
| the reason for that is because Flash died. Sometimes
| generations grow up and younger generations go act
| creative in different spaces.
|
| So yes, there is a very specific workflow for a very
| specific type of game that no longer works on the web.
| I've used Unity, and I don't really like Unity, I hate
| it's resource management, I hate that we're still using
| proprietary software after so many years. But I think
| more people are making games with Unity today than were
| making them back then on Flash. It's more accessible.
|
| I'm very, very slowly changing my opinion on this. Part
| of it is that Flash is still available today under
| Animate, and while it is still chained to Adobe I've
| still never heard a really good breakdown of how it's
| worse or what features it doesn't support anymore. As far
| as I can tell, you can still use Actionscript 3.0 with
| Animate. It is proprietary and expensive, but so was
| Flash -- so if it's purely a technical problem, then I'm
| not 100% sure that you _couldn 't_ still make a Flash
| website/game today.
|
| I still think there's a hole here that could be better
| served by Open Source toolchains, but I'm becoming less
| convinced that it is as big of a deal as I previously
| thought. If you're trying to make games, now is a really
| good time to be alive. It could be better, but if you
| give me the option of making games in 1999 or making
| games today, I'm not going back to 1999.
|
| And aside from that, even if Flash is a hole, it's still
| very specifically a hole for games. Even during its
| heyday, building static websites in Flash was a sin.
| Almost everything else you want to use to build a static
| website is still available. Just not that specific sinful
| part :)
| watwut wrote:
| Roblox is not comparable to flash in the ease of
| development. You don't have kids creating mini games and
| sharing them either. Scratch is not comparable either.
|
| The ease of creating something is just not there in
| general. The current tools are harder to use for beginner
| and beginner achieves less with more effort.
|
| And open source have bad track record in terms of
| creating user beginner friendly tools.
| 1vuio0pswjnm7 wrote:
| As an end user, I use "tools" from 20 or more years ago to
| retrieve and extract the needed information from today's
| "complex web apps". Networks and server software are so much
| faster today, "yesterday's" (smaller, simpler) software seems
| to work even better today.
| Jaygles wrote:
| Because sometimes you want to learn the fancy tools but only
| need to make something simple. When the time comes to make the
| complex web app, you are now more prepared.
| astrowilliam wrote:
| Learning fancy tools is outside the scope of building a
| simple website. Simple site is usually HTML/CSS/JS.
| tomc1985 wrote:
| But... so are the complicated sites, once you've reduced it
| to its essence. Everything else are (excessive,
| complicated, arguably unnecessary) abstractions on top of
| that
| austincheney wrote:
| > If you want to make a complex web app today, that's easier
| than it was 20 years ago. The tools are infinitely better.
|
| That's true if the web app is a SPA and uses React and doesn't
| require much accessibility and uses Redux or doesn't manage
| state and, and, and...
|
| Most web developers are limited to those conditions and most
| currently posted front end jobs are limited to those
| requirements. Technically what you said is subjectively correct
| but it depends on a lot of factors and constraints for the
| average developer.
| grishka wrote:
| I'm able to make what people call a "web app", yet I honestly
| have no idea what React and Redux are, besides buzzwords, and
| what they are supposed to solve.
|
| But then there's also the problem of people relying on
| JavaScript _at all_ for websites that would 've been fine as
| a bunch of fully static HTML pages. It's as if these days you
| can't do software development without overengineering
| everything into oblivion.
| pdimitar wrote:
| You haven't at all responded to your parent comment whose
| premise was that many frontend devs cannot utilize the
| freedom that you are apparently enjoying.
|
| IMO it's not the topic here if JS should at all be used.
| You won't catch me arguing with that -- my answer is almost
| always "NO!".
|
| The topic was: "but can you make web pages like 20 years
| ago in the current frontend dev jobs market?" -- the answer
| that is "no" as well IMO.
| austincheney wrote:
| Yes, many things are deliberately over engineered and that
| is largely due to limited capabilities of a specific tool
| or technique.
| midrus wrote:
| I agree with you, but the problem, the big problem, is that
| you're looked down if you propose to use simpler tools.
|
| It is horribly difficult to not use these advanced tools for
| simpler problems. At work my team does just f**ng CRUD forms,
| and for doing this we have the most overcomplicated stack I've
| seen in my life. Go backend with React, Redux,
| Rxjs,custom.webpack craziness, and 32 tons of internal weird
| libraries no one would willingly use ever even if pointed with
| a gun.
|
| If I propose to just use Rails for this and be done with it,
| I'd be declared and heretic and expulsed from the frontend
| team.
| gher-shyu3i wrote:
| I echo this. Currently working on CRUD app in golang. What an
| absolute mess and much slower than using established
| technologies.
| midrus wrote:
| I don't blame the language tbh. I blame the frameworks and
| tools (or the lack of) for web development.
|
| Look, I love node and javascript. But I can't deny it is is
| total mistake to use it in a business context for web dev
| when you have django, rails or Laravel. Same for Go and
| many other trendy tools.... Reinventing the well is not a
| good business unless you're in the wheels business.
| silexia wrote:
| We have been using WordPress for 15 years and it's been
| wonderful and easy the whole time. Occasionally if a
| plug-in gets compromised, it's very easy to roll back and
| fix it. We now have a standard set of safe plugins
| anyways.
| thirdlamp wrote:
| Without knowing your situation, that sounds like job security
| to me. "If we go the simple route I'm obsolete"
| Jiejeing wrote:
| The difference is that now everybody wants complex web apps, a
| split backend/frontend, a SPA, PWA, done usingthe javascript
| framework of the week, etc...
|
| Yes, doing complex things has gotten easier, mostly due to the
| improved tooling, but the number of things developers are asked
| to solve (for no real reason other that "it is now doable")
| have skyrocketed.
| jrockway wrote:
| I'm not sure this is quite true. 99% of early 2000s websites
| can be made by an unskilled operator automatically, by using
| something like Squarespace or Wordpress. The other 1% are the
| hard projects -- desktop quality applications that need to run
| on 5 platforms and 3 Javascript engines. Most people that do
| frontend engineering are being paid to work on those hard
| problems, so the job is going to feel harder than it did 20
| years ago. There is no money in the easy things; it's all been
| automated away.
|
| To some extent, the tooling does make things harder than it
| needs to be; it's converged to a very strange local maximum
| that's very far away from the global maximum. The problem, I
| think, is a complete lack of integration along the entire
| stack. You write your code in a programming language whose
| source code is sent to the user to compile, and there are
| hundreds of minor variants on how the user will interpret that
| code. You have to defensively handle it all. But, developers
| want to reuse code, and those runtimes don't really support
| code reuse, so you have to bolt it on with a fake "compile"
| stage, where you concatenate all your dependencies together and
| split it up into chunks to be served to the end user's compiler
| at just the right time. The language that is used for these
| tools is a little on the outdated side, so this compile stage
| takes 30 seconds on one CPU core, leaving your commodity-grade
| 32 core workstation 96% idle while you sit around waiting. And,
| people don't even like this language for writing their code, so
| they write it in a different language that is compiled to that
| first language. After all that, you have code that can run on
| users' machines, but that's only like 30% of the problem. You
| have to serve that code to them, preferably from a datacenter
| that's physically close to their terminal. You have to serve
| them ancillary assets, like instructions for how to format the
| data your app interacts with, and images. Like the author
| mentions, there are a million different image formats, and you
| have to pick the right one for the end user, relying on a
| single line of text like "Mozilla/5.0 (Windows NT 10.0; Win64;
| x64) AppleWebKit/537.36 (KHTML, like Gecko)
| Chrome/89.0.4389.128 Safari/537.36". That's hard, so there is
| some service you can buy to do that for you, completely
| unrelated to that aforementioned "build process". The TL;DR is
| that there are hacks on top of hacks, and moving parts on top
| of moving parts, that it's a wonder it works at all. But we're
| in this state where we can't even fix it, because there is no
| one party responsible for the end-to-end experience. All you
| can do is bolt on more and more components and hope that you
| get closer to a local maximum.
|
| The takeaway is that in a distributed system of glued-together
| components, no one entity is responsible for the success of
| your users. And, those that manage to build success for their
| users will do it all through very careful glue, that can come
| apart and blow up at any time. That means they have a never-
| ending job that consists only of unnecessary toil. At some
| point, the person that decides "FUCK IT" and throws this all
| away and builds some sort of integrated experience is going to
| make a lot of money. But there are many lifetimes of work ahead
| to achieve this goal, and you'll be dead before you finish, so
| why even try? That's where we are. Good luck.
| HWR_14 wrote:
| > If you want to make a complex web app today, that's easier
| than it was 20 years ago. The tools are infinitely better.
|
| 20 years ago, you could make a complex web app in Java, ActiveX
| or Flash. (There were also more obscure options.) People would
| install a plugin for your app.
|
| Now, it all uses Javascript. There are a lot of advantages, but
| it's difficult for me to say the tooling there is infinitely
| better. I think a reasonable case could be made that the
| _tooling_ is worse than any of the three I mentioned.
| tigershark wrote:
| 20 years ago we were criticising the syntax in JSP and ASP
| pages that allowed to embed code inside an html template. Today
| it seems that you are crazy if you are not writing a JSX SPA
| embedding JavaScript inside a JSX template. We are doing "There
| and back again" for I don't know how many times.. And believe
| me I kind of like React and JSX, but I liked also embedding my
| dirty code in HTML ages ago.
| rossdavidh wrote:
| Amen. If a static web page does what you need, one should not
| be unwilling to just make a static web page.
| recursivedoubts wrote:
| _> simply npm your webpack via grunt with vue babel or bower to
| react asdfjkl;lkdhgxdlciuhw_
|
| I am sorry to spam, but this is exactly the problem
| intercooler.js and now htmx were designed to solve:
|
| https://intercoolerjs.org/2016/10/05/how-it-feels-to-learn-i...
|
| 90+% of the websites being built (and 90%+ of 99% of the websites
| being built) could use a much simpler, traditional HTML-oriented
| REST-ful model at a fraction of the complexity of frameworks
| being used today.
| franklyt wrote:
| Building a non-trivial website in React with halfway decent
| design practices is 100000x easier than doing so in raw
| html/css/jQuery (for argument, the vanilla API back in the day
| was impossible to use).
| megameter wrote:
| Phrases like "the content is what is important" come to mind.
|
| The whole project of graphic design has the same kind of abyssal
| qualities as other arts with a technical element - you can always
| go deeper, more specific. And in a competitive market it's really
| tempting to sell yourself on one-upping the techniques of others.
| With a computer in the mix, you can just add specification
| without end and it will soak everything up like a sponge.
|
| But each layer of that you add gets a little farther away from
| "creative medium" and a little more towards "bells and whistles
| production". The essence of it comes from the content, and this
| is true of everything on the Web too, despite all the
| interference on and around the platform. So it's more like a case
| of modern development being "you have to describe the medium you
| want to work within" because the base layers are this morass of
| vocabulary that isn't conceptually coherent.
| riskable wrote:
| > "the content is what is important"
|
| The only problem there is that users have come to expect
| certain UI elements on any given web page and those things are
| far beyond "content". For example, let's say you want to allow
| comments on articles. Now you have opened an _enormous_ can of
| worms by requiring logins, storing of passwords (hashes! with
| salts! using modern algorithms!), permissions management,
| password reset mechanisms, collection of emails (for password
| reset), and personal data.
|
| You can handle all that the old fashioned way and implement it
| yourself _or_ you can look into the great wild of the Internet
| to see what solutions already exist. That 's where the rabbit
| hole begins!
|
| Now you've got a back-end OAuth infrastructure supporting your
| website. You're using a login module that you were able to
| "easily" install via npm. You used an oauth2 module in your
| back end and everything seems to work fine except now your JS
| code is getting a little crazy with all the "time saving" npm
| stuff you're using so you start to look at "bundlers" like
| WebPack...
|
| Welcome to hell, my friend. This is modern "minimal" web
| development.
|
| Oh but perhaps you could use a static site generator instead!
| Surely someone has created _the perfect_ Markdown
| /ReStructuredText tool for generating your perfect web page
| that has all the features you need!
|
| There happens to be one _that 's close_. It does everything you
| need except that one little thing. So you reach into the npm
| bucket... Then you end up having to deal with bundlers again.
|
| It never ends!
| 8bitsrule wrote:
| >users have come to expect certain UI elements on any given
| web page and those things are far beyond "content".
|
| Usually I visit pages to see if the content is worth my time.
| If the 'UI elements' somehow contribute to that content,
| great. That's rare.
|
| Most pages I hit are hiding poor content in swathes of
| katchi-vatchi. Do I really care if the headline slides down
| that big photo? Am I really going to scan those glaring
| sidebars?
|
| Once again I _sigh_ and mouse-up to Firefox 's 'Reader view'
| to cut through all that bandwidth-wasting crap.
| megameter wrote:
| Right. There's an element cleaving both ways of the
| developer being obligated to do complex and disempowering
| things for users for various reasons, and then users
| rejecting their disempowerment and trying to work around
| it.
|
| And I think if there's a future here it belongs to targeted
| protocols that decouple the use case from the UI, and
| filters like Reader view that reformat content to the
| medium the user wants to work in.
| geerlingguy wrote:
| I have gone back to plain CSS files and dropping Sass and other
| preprocessing techniques just because the past decade of managing
| build chains and dependencies _to marginally improve writing
| styles that change minimally between redesigns_ has soured me on
| more complex build processes.
|
| By the time you actually do a redesign that would take advantage
| of the fact you use mixins, css variables, etc., the whole design
| language changes, and meanwhile you'll have to change
| preprocessors anyways.
| devchix wrote:
| At some point in my organization's press toward Ansible, I came
| to the realization that Ansible the product is yet another layer
| of abstraction that is there for its own sake, and of dubious
| value. I converted a simple script to patch stuff, something that
| is trivial to write and run, and the yum module behaves different
| enough from the command-line yum that I have to learn a different
| way to get and parse the output. AWS logs also behave the same
| way, impossible to take up and read, quickly, trivially. Why do
| people read logs? To find out what happened, and do so quickly.
| Someone will argue that logs are so verbose we need to make them
| machine-friendly vs. people-friendly, so we can make tools to
| process them. Somewhere in the past 5 years we've gone toward
| making things more tool-friendly that humans can no longer
| interact with them in meaningful way. Some time in the future
| when something else supplants Ansible, shell will still be there,
| and still works. Meanwhile, I crib from Ansible docs and
| StackOverflow just to get things to work the way it did, and the
| pay-off is ... what exactly?
|
| Edited to add:
|
| Years ago Solaris10 converted the rc boot scripts to what was
| systemd precursor, SMF. I drank the koolaid, yes! we can build
| dependencies now, we have service-level kernel events now! I can
| get rid of daemons and watchdog scripts now! The innards of SMF
| was indecipherable XML, dependencies grew, you could no longer
| find a good system view when you ask SMF, and you couldn't easily
| find and fix what's wrong with the service file. At the time, it
| was designed to be un-messed-around-with by keyboard-happy
| warrior greybeard sysadmins, judged to be a source of instability
| and inconsistency.
| honkycat wrote:
| I agree ansible is bad, but it is NOT the state of the art.
| Honestly its kind-of old and dead at this point replaced by
| stuff like CDKs.
|
| Programming in YAML sucks. YAML based solutions will always
| come up short because you cannot develop proper abstractions so
| you end up with a big bowl of copy-pasta amd indecipherable
| work-arounds.
|
| IMO the modern web is all based around adding types to systems
| because we've realized the extra toil types require make large
| systems have fewer bugs and more maintainable.
| rhn_mk1 wrote:
| What are CDKs?
| em-bee wrote:
| _cloud development kit_ if i am not mistaken
| em-bee wrote:
| when i evaluated ansible and saltstack a few years ago, i
| went with saltstack because the ansible example felt much
| more like programming in yaml, while the salt example was
| much more declarative.
|
| i am still not happy with yaml, but i haven't seen any better
| alternative than saltstack yet.
|
| cloud development kits seem to target cloud APIs only and
| don't look like they could work for just a bunch of computers
| fpoling wrote:
| This is the my experience as well. For an activist website that
| I maintain I just use a PHP script to install everything and to
| ensure that everything has proper permissions. The site uses
| Wordpress and patching config files in PHP is simpler than in
| bash. I am glad that I have not bothered with Ansible, as I
| would most likely ended up with YAML programming which is way
| worse than bash.
| anthk wrote:
| Perl was made exactly for that.
| ericbarrett wrote:
| I'm with you on logs. The recent trend of "machine-readable"
| logs, encapsulated as JSON structs, adds so much complexity to
| the process, and makes them unscannable to the human eye. And
| yet for general use cases you're not getting anything a regex
| couldn't parse out of the log prefix.
|
| In 2010 I could search a terabyte of logs with grep -F in under
| a minute. With a "modern" setup you can't even _see_ your logs
| until you have Elisticsearch up and running.
| commandlinefan wrote:
| > another layer of abstraction that is there for its own sake,
| and of dubious value
|
| Wait until you see Spring Boot.
| jancsika wrote:
| > For instance, last week I was reading a post about the benefits
| of not using stylesheets and instead having inline styles for
| everything.
|
| Back in the day, this probably meant one of a handful of things:
|
| * manually writing all the HTML and putting the inline styles
| there
|
| * some kind of PHP thingy where you would be essentially rolling
| your own CSS variables
|
| * some kind of Perl thingy where a verySmart dev is trying to
| maintain an entire CMS using only regexes
|
| Today, the user could be "having inline styles" in one of 10,000
| frameworks-- Vue thingies, React thingies, or perhaps a build
| flag in a Javascript thingy that spits out a CSS thingy...
| muglug wrote:
| Previous discussion from 2018:
| https://news.ycombinator.com/item?id=16346039
| commandlinefan wrote:
| Coupled with the expectation that those same things should take
| _less_ time than they used to and be 100% predictable.
| mauvehaus wrote:
| Confession: as a recovering programmer who made a career change
| to non-programming, it took at most 30 minutes to say "fuck it"
| and go with Squarespace.
|
| I've never been on the web side of things, but I knew enough HTML
| in the early aughts to put up a basic informational website.
| After digging in to some sites I admired, I decided that it was
| too much distraction from my actual work to roll my own.
|
| Granted some of this complexity comes from the legitimate need to
| support mobile gracefully, but damn are there layers upon layers
| upon yet more layers of stuff just to get some pictures to show
| up nicely with some text and look consistent across devices.
|
| Props to everyone who does this for reals and does a good job
| achieving that consistency. For my money, I'll hire it out.
| dleslie wrote:
| FWIW, services like Squarespace are devouring the VPS and
| small-site design industry. Rolling your own services, managing
| them with cPanel, and paying local kids to build and design it
| is a quaint throwback.
| [deleted]
| volkk wrote:
| what kind of work did you get into after programming out of
| curiosity? rare to see people go the other way
| inglor_cz wrote:
| Not the OP, but I left professional programming to become a
| writer (in Czech, not in English; pardon my mistakes).
|
| It actually has something in common, you still write
| structured text for living, though your target audience are
| now people, not machines. Some readers commented that they
| find my style clear and understandable; maybe it is a carry-
| over from programming, where you cannot be ambiguous.
|
| But I find writing for people much more enjoyable than
| writing for computers. As a computer programmer, you mostly
| receive negative feedback: something stopped working and the
| users are often angry or frustrated. As a writer for people,
| you receive more than a few thank-you e-mails from your
| readers, which brighten your day.
| kungfuscious wrote:
| Writing human-language and programming indeed have a lot of
| skill transfer. They're both writing after all. But most
| importantly it's the ability to clearly communicate ideas
| and organize thoughts.
| kbenson wrote:
| > As a computer programmer, you mostly receive negative
| feedback
|
| FWIW there are different types of writing and different
| types of programming.
|
| Writing copy for a bank will probably generate a lot of
| feedback about mistakes that need to be fixed.
|
| Writing code to reduce annoying monotonous tasks for
| coworkers so it takes ten minutes instead of two hours will
| get you a lot thank yous from your coworkers, and will also
| brighten your day.
|
| It's all about what your job is, and how close you are to
| the people you are affecting.
| jdkoeck wrote:
| Hi, I'm really curious, what do you write exactly for a
| living? Do you write fiction books, non-fiction books, blog
| posts, technical documentation?
| inglor_cz wrote:
| 1. Political commentary for a local newspaper. They pay
| reasonably well. 2. Popularization of science and
| technology for a few web outlets. 3. Books about
| interesting historical events, these are by far the most
| popular and earn me majority of my writing income. 4. I
| dabbled a bit in fiction, but long forms like novels seem
| to be out of reach for me. My strength is in shorter
| texts that can be written in an afternoon. 5. A free blog
| that comes with an e-shop where my books can be bought.
| nitrogen wrote:
| _rare to see people go the other way_
|
| I suspect this is literally true, but only because we don't
| _see_ them. I 've heard second-hand the story of a top
| developer at a famous unicorn who just couldn't keep up with
| all the stimulants everyone was using to code more and burned
| out, bought a cabin in the woods, and became a hermit.
| ChrisMarshallNY wrote:
| _> all the stimulants everyone was using to code more_
|
| That's interesting. Do you mean Adderall/Ritalin?
|
| That stuff has a relatively fixed useful half-life. It
| doesn't work for as long as people might think. It also
| doesn't _actually_ make thinking clearer. It makes people
| _feel_ as if they are thinking more clearly. I don 't feel
| like looking for it, but this has been studied and
| reported, somewhere.
|
| If you are referring to crank, well, the half-life of that
| stuff is even shorter...
| bnjms wrote:
| Amphetamines, cocoon, and modafinil are the likely
| targets. Other than that look up stimulant nootropics.
| dleslie wrote:
| Cocaine, MDMA and LSD seem to be favourite drugs around
| town, here in BC. I mean, besides the usual marijuana,
| tobacco and beer.
| divan wrote:
| Without clicking the link and reading comments - let me guess:
| it's about JS/HTML/CSS stack, right?
| red_trumpet wrote:
| I think the example of table / grid layout is a weak one. Table
| layouts were not bad because of what they produced, but because
| html tables are semantically different, and shouldn't be used for
| layouts. But they still solved the same problem that grid layouts
| solve.
| mikewarot wrote:
| The source for the page is as clear as I expected, which made me
| happy. I feel the same about programming for applications on
| PCs... things were simple, then they got complex with the arrival
| of windows, then simple again with VB6 and Delphi, and now
| they're a mess again. (Not to mention mobile)
| wcr3 wrote:
| smart to check the source; thanks for pointing that out.
| muglug wrote:
| Customer needs for most websites basically haven't changed in two
| decades.
|
| Outside of a few complex SPAs doing interesting things,
| structurally we're building the same things we were building back
| then (blogs, brochure sites etc) -- it's just that the way we're
| building them has become (optionally) much more complex.
| fpoling wrote:
| 20 years ago one could assume 1024x800 and it would mostly
| work. Then smart phones came with small vertical screens and
| touch input. Then tablets made it necessary to support screen
| rotation. Then retina displays required to support dpi-aware
| images. Then dark/light mode came and general color
| management...
| muglug wrote:
| > 20 years ago one could assume 1024x800 and it would mostly
| work.
|
| IE 5 and 6 and Netscape Navigator 4 would all beg to differ.
| Having made simple websites two decades apart, CSS is much
| less hassle nowadays.
| jacobwilliamroy wrote:
| In my area it seems everybody wants some kind of web app or
| VPN. In the good old days things like file sharing and
| inventory management could be done on the LAN but with COVID
| everybody is scattered all over the place. My clients have this
| expectation that they'll be able to use any random smartphone
| to scan a QR-code in the Phillipines and have that magically
| publish inventory updates to accountants Texas. Everybody wants
| to bring their own phone or computer. Everyone wants all their
| data to be accessible through the web. It's chaos I tell you,
| and a security nightmare to boot.
|
| Personally I think of the web as a highway: great place for a
| billboard, not such a great place to be storing or mutating
| sensitive information.
| nicbou wrote:
| It's good to remind ourselves that all of this is optional.
|
| Most websites could be a simple WordPress do. Many brochure
| websites should be static. There are benefits to straying from
| that, but they come at a cost.
| pjmlp wrote:
| Which is why I keep happily doing .NET and Java Web based
| development with SSR as always, APIs now return REST, GraphQL,
| gRPC instead of XML-RPC/SOAP, or whatever makes the FE team
| happy.
|
| I know enough of Web FE development to jump in and fix a couple
| of bugs when needed, and on my own consulting gigs as side job,
| I only do native desktop development as kind of therapy.
| tiborsaas wrote:
| I'm wondering what he could have learned in the same time it took
| him to write this article. I get it, it's harder to navigate the
| vast jungle of tools and technologies. I also remember 2001 when
| my only reference to HTML was the help files of Home Site 4.0.
|
| We have it much easier today.
| cosmodisk wrote:
| I often feel a lot of things became more complex for the sake of
| it. You'd think by now it'd be just a press of a button and your
| software is deployed and the clients can start using it,but no,
| that'd be too easy. Instead,even getting a simple WordPress
| website up to speed requires endless list of plugins,some
| undocumented configurations and CSS overwrites in random places.
| And it just gets worse and worse.
|
| When you need to spend a few hours just to get the development
| environment somehow ready before first line of code is written,
| you know things aren't going the right direction
| jb3689 wrote:
| On the other hand the one button experience is as far as it has
| ever been. I just pushed up a website on Amplify in a few
| clicks, and the only reason it isn't less is that some people
| want options.
| bigwheeler wrote:
| "I wonder if I have twenty years of experience making websites,
| or if it is really five years of experience, repeated four
| times."
|
| This sums up how I feel about my entire career as eloquently as
| possible.
| papertokyo wrote:
| Frank is right, of course. Staying up to date with the tooling,
| best practices, and user expectations of the web requires an
| unreasonable amount of attention if making websites is only a
| small part of your service offering.
|
| One reason I prefer frontend libraries like Vue and Svelte is
| they feel closer to the grain of the web (HTMLesque templates
| with JS and CSS sprinkled in), and provide a reasonable level of
| abstraction and magic. The learning curve and paradox of choice
| is also much easier to navigate than React especially for solo
| devs who aren't working on a huge app with a team.
| MereInterest wrote:
| And this is exactly why any of my hobby projects that involve
| JS are done with plain JS, with as few libraries as possible. I
| might pull in specific libraries, but I don't want to pull in a
| giant framework that will be outdated the next time I decide to
| work on that particular project.
| lenkite wrote:
| A micro-library like https://redom.js.org/ does make things
| easier though. I have also given up on mega-frameworks - just
| too many things to keep in mind as I get older.
| grishka wrote:
| Here's my "femto-library" for creating DOM dynamically from
| JS: function ce(tag, attrs={},
| children=[]){ var el=document.createElement(tag);
| for(var attrName in attrs){
| el[attrName]=attrs[attrName]; } for(var
| child of children){ el.appendChild(child);
| } return el; };
| winphone1974 wrote:
| Easier through ignorance seems like cheating IMO. you're
| basically saying yes things are harder but I just ignore
| them. How would a newbie decide what's safe to skip?
| rectang wrote:
| Another thing I find weird is how bloated static typical site
| generator tools are. The delivery medium of static HTML is
| timeless. But the odds that a static site generator with
| dozens of dependencies will still work N years from now?
| Grim.
| nanna wrote:
| 'Typically' meaning...? Jekyll? Gatsby?
| nitrogen wrote:
| I have a couple of older static sites (one using
| Jekyll/Octopress, one using Middleman), and if I ever do
| a _bundle update_ something is guaranteed to break. Not
| sure if that 's the "bloat" the parent comment is talking
| about though.
| laurent92 wrote:
| Yes. I was on Jekyll 2 years ago, I don't think I'll be
| able to compile it in two years. It's already on an old
| version of Ruby if I remember, if not Bundle or Gulp
| or... and it's just a simple website.
| enriquto wrote:
| just write html by hand. With html5, implicit and auto-
| closing tags, it's really not more difficult than markdown.
| Then your "generator" is simply the cat program, that
| appends a common header and footer.
| lenkite wrote:
| They all started off lean and mean. Then after adding
| feature after feature they become bloated. Then the next
| lean-and-mean static HTMl generator becomes vogue.
| red_trumpet wrote:
| Bashblog[1] is pretty lean, and doesn't use any
| dependencies.
|
| [1] https://github.com/cfenollosa/bashblog
___________________________________________________________________
(page generated 2021-04-17 23:00 UTC)