[HN Gopher] Breaking up with JavaScript front ends
___________________________________________________________________
Breaking up with JavaScript front ends
Author : hdjjhhvvhga
Score : 289 points
Date : 2022-12-10 17:35 UTC (5 hours ago)
(HTM) web link (triskweline.de)
(TXT) w3m dump (triskweline.de)
| Mountain_Skies wrote:
| Two arrows until the concept was too annoying to bother with
| indulging.
| francisofascii wrote:
| > Looking for developers to maintain 150K lines of Angular 1.5
| and 7000 abandoned npm packages.
|
| I completely get that reason. Any front-end framework app is on
| live support in a few years. It feels like the equivalent of
| buying a cheap refrigerator that will break in 4 years, that is
| easier to get a new one rather than try to fix the old one.
| TheRealDunkirk wrote:
| I don't understand why so many people are dismissing this because
| the post is from 6 years ago. Looks like the project is still
| actively maintained, which, after the 3 lifetimes that 6 years
| represents in development timelines, seems to be a stroke in its
| favor.
| crystaln wrote:
| They were using Angular - enough said.
| nixpulvis wrote:
| Stop breaking my god damn back button!
| TheRealPomax wrote:
| This appears to be from 2016, so probably needs a [2016] in the
| title.
| pacomerh wrote:
| your site needs JS to work though. People love the sensational
| headlines
| Erikun wrote:
| Am I missing something? They say to "Start classic" or "Start
| enhanced" on the first page of the demo app but neither is there
| for me.
| triskweline wrote:
| Author here. The link is a 6 years old presentation. The demo
| app has since been rewritten.
|
| The old demo app focused on the downsides of classic multi-page
| apps (MPAs), i.e. the reason the world moved to SPAs all these
| years ago. In an MPA clicking a link loses all transient state,
| like focus, scroll positions and unsaved form state. This can
| all be solved with updating fragments instead of full pages,
| while still keeping rendering logic on the server.
| Erikun wrote:
| Ah, mystery solved. Thanks.
| l1n wrote:
| http://youtube.github.io/spfjs/ seems like it does much of this
| for me
| pjmlp wrote:
| As someone that pretty much has stayed with Java and .NET SSR
| frameworks, with snippets of dynamic content where it makes
| sense, this kind of back and forth is kind of ironic.
| mtoddsmith wrote:
| Problem: we hate frameworks Solution: creates new framework
| 22289d wrote:
| If this page is a demonstration of what a future without
| JavaScript would look like, it's an unintentional advertisement
| for sticking with JavaScript.
| futureproofd wrote:
| I think the intention was to spark conversation loosely around
| SPAs vs SSR. It seems we're at yet another turning point and
| frankly, I'm enjoying the debate.
| JohnFen wrote:
| I can't tell, because their site won't render without JS
| enabled, and I'm not willing to enable it for them.
| cgrealy wrote:
| The title is poorly chosen at best and misleading at worst.
| They're not abandoning JavaScript, they're just abandoning
| client side rendering (angular, etc)
| synergy20 wrote:
| I still think separating frontend from backend makes life easier
| even though frontend has been chaotic for a decade, and it shows
| no sign to slow down
| oblak wrote:
| Depends on what you're doing. There is great value in SSR but
| how does one even make anything dynamic/interactive without JS?
| You can't, so you start adding pure non-spa tainted js. Then
| you add features until your amazing purist solution is an
| unworkable mess stuck in the mid 2010s.
| omnimus wrote:
| This is just problem of structure. I am not convinced that
| there is particularly higher chance to end up with
| "unworkable mess" with SSR compared SPAs (of course most
| projects end up being a mess).
|
| If you look at the hottest trend of the "island
| architecture". New frameworks like Astro
| (https://astro.build/) and Fresh (https://fresh.deno.dev/).
| They are basically what are you describing. All SSR but with
| dynamic parts. Seems like these "islands" by their nature are
| less entangled than full SPA.
| noidiocyallowed wrote:
| Nice font usage.
| awesomegoat_com wrote:
| Good job. This is the next trend out there.
|
| Although, this solution feels to be heavily inspired by
| https://hotwired.dev/ Is there a reason, why new framework (with
| some extra cool features) have been developed as opposed to
| contributing to hotwired/turbo frames?
| coin wrote:
| What an annoying website to navigate. Almost unusable on an iPad.
| poisonborz wrote:
| Much of this and more was achieved with NextJS. Yes, javascript,
| but you have absolute control of what you want to render server-
| or client-side. You don't have to write APIs. And you still have
| the massive Node or React catalog at your fingertips. I don't
| think there is a better realisation currently for what they aimed
| for in this presentation.
| bottlepalm wrote:
| Yep started a new project after a month of getting up to date
| with all frameworks old and new.. Next.js really is the best
| option right now it seems.
| throwaway0x7E6 wrote:
| if you really have the spaghetti clusterfuck pictured in #11,
| then your devs are re####ed, to put is as mildly as I possibly
| can.
|
| I gave up reading because I really can't take it seriously after
| that slide
| tail_exchange wrote:
| And the solution was to turn their website into a powerpoint
| presentation?
| omnimus wrote:
| Don't want to break this to you but this is a presentation not
| their website.
| [deleted]
| LAC-Tech wrote:
| I got very excited at the premise and the first few slides,
| thinking someone was going to talk about what a secret weapon
| vanilla JS is for productivity...only to find out they're
| advocating use of a front end library much larger than react or
| Vue.
|
| At this point I'm getting a bit tired of backend people claiming
| that the cure to the frontend mess is a big library that pretends
| to be html.
| satvikpendem wrote:
| Looks very similar to what NextJS is doing, especially with their
| app directory API [0], ie have everything on the server with
| React Server Components but then stream in client-side JS as
| necessary. It's basically the "sweet spot" that TFA talks about.
|
| [0] https://beta.nextjs.org/docs/routing/fundamentals
| Waterluvian wrote:
| Warning: if you want to look at the content of this page, say
| goodbye to your back button.
| omnimus wrote:
| This is not a website. It's a presentation made with reveal.js
| framework. This has been made as slides for a talk. It is very
| much feature that people accidentally don't back out of their
| presentation while they are doing it.
| viraptor wrote:
| You can easily disable it with "history: false" in the reveal
| config. (As an author unfortunately)
| Waterluvian wrote:
| There's a browser API for preventing people from leaving
| pages if they are in a context like that. And unlike this
| method, it works for the first page, works if you try to
| close the tab, and works if you try to navigate to a
| different link. And it doesn't become entangled with browser
| navigation.
| omnimus wrote:
| Well my point is that it's a bit unfair to blame the
| authors of the presentation for this functionality.
| Reveal.js is pretty much the standard open-source
| javascript presentation framework. It's used and developed
| by slides.com. I don't know why it works like it does. But
| mind you this is 6 year old presentation with reveal.js
| from 2015.
| Waterluvian wrote:
| Who blamed the authors and what did they blame them for?
| qudat wrote:
| This was pretty brutal.
| simple10 wrote:
| Yep. Browsed the slides and then couldn't go back to HN using
| the back button. Is there a max history depth setting per
| domain in Chrome? I haven't run into this issue in awhile and
| forget why it happens.
| tobyhinloopen wrote:
| Yeah found that out the hard way. Horrible design
| ledauphin wrote:
| yeah, this was particularly ironic.
|
| The back button has evolved alongside SPAs, and users mostly
| don't expect or want their back button to take them back
| through the hundreds of small state changes they've caused by
| interacting naturally with a UI.
| omnimus wrote:
| Because it's not website. It's a reveal.js presentation. It's
| on purpose so you don't get out of it when presenting.
| WesSouza wrote:
| Not secure
| Aaronmacaron wrote:
| Micro dependencies and dependency hell are two of the Javascript
| ecosystem's most frequently mentioned issues. Anyone aware of any
| initiatives to lessen dependencies in important projects? For
| instance, the typical number of dependencies in a JS project
| would probably decrease significantly if large libraries and
| frameworks like webpack, babel, react, etc. all stopped using
| dependencies like left-pad or is-boolean (and also a bit more
| sophisticated ones). It would probably be sufficient if the top
| 1% of packages tried to remove as many dependencies as they
| could, because those are the dependencies that 90% of developers
| use. Additionally, large packages likely have the resources to
| implement helper libraries on their own rather than relying on
| them.
| skilled wrote:
| I think innovation needs to happen in package management. Has it
| happened yet? Because I don't know for sure, so I am asking
| because I might have overlooked it.
|
| Even projects from a few months ago can be become unusable unless
| you are willing to sit down and spend a couple of hours fixing
| the problem. And don't get me started on packages that have been
| abandoned altogether but are like glue to functional software.
|
| (I am talking about npm)
| bottlepalm wrote:
| Innovation isn't going to prevent people from abandoning
| projects.
|
| You have to make smart decisions when adding dependencies based
| on how mature and supported is it. This often means sticking
| with the big names even if the little project has more hype.
| olingern wrote:
| Like others have mentioned, this seems to be from ~2016. The lack
| of HTTPS on the provided link ages this some for me, but the use
| of coffeescript really dates this[1]. I even thought coffeescript
| had been deprecated, but it does seem that the project is being
| kept alive[2] which is really cool.
|
| Perhaps, what is most interesting is that it took nearly 4-5
| years for the front-end community to collectively come to the
| conclusion that SPAs are not _always_the answer. I don't think
| the zeal for SPAs came from a bad place either. I can remember
| how poorly ASP.NET and other frameworks of the 2008-2012 era
| packaged an overcomplicated way to pass data to view layers.
| There's lots of curmudgeon-ining from non-frontend folks but, in
| my opinion, the lack of performance and ergonomics with existing
| frameworks, combined with the newness of Node.js is what brought
| about the explosion of tooling and frameworks.
|
| There is a place for SPAs, though. VS Code, Spotify, and other
| apps that need a desktop / browser experience to feel like a
| mobile app are great candidates. Twitter, for example, shouldn't
| be a SPA or SPA-like application. I find that it frequently over-
| caches content and will randomly refresh my feed at times while
| I'm browsing. It feels as if a simple web page that needs to
| deliver more JSON responses as I scroll is trying to do too much.
|
| 1 - https://github.com/unpoly/unpoly
|
| 2 - https://coffeescript.org/#changelog
| jrochkind1 wrote:
| It's interesting that they appear to plan to use with Rails as a
| back-end (they mention Rails bindings), as Rails 7 release
| corresponded with a solution which appears somewhat similar to
| me, turbo/stimulus. (I want to provide a link to it, but I
| honestly don't know any great docs for it!)
|
| But I haven't used stimulus/turbo myself. I'd be interested in a
| compare/contrast between Rails' Stimulus/turbo and "Unpoly"
| covered here.
|
| There also seem to be a number of other non-Rails-related
| offerings in this space too. They seem to be really multiplying,
| which I think shows the exhaustion with JS front ends and desire
| for things in this space (I am not sure quite what to call it).
| But I wonder if we can converge on one or two instead of creating
| more and more. One of the benefits of a popular layer is that you
| can start building share-able re-usable solutions which compose
| with it -- you can find lots of solutions for certain things for
| React, like you used to be able to for JQuery, but splitting
| between stimulus/unpoly/htmx/etc...
| ransom1538 wrote:
| "I want to provide a link to it, but I honestly don't know any
| great docs for it!"
|
| I setup a demo, rails7/mysql[1]/turbo/docker - one command
| setup you are playing with it. https://github.com/james-
| ransom/rails7-on-docker-mysql. Give me a star you have a friend
| for life!
|
| * not Postgres!!
| jrochkind1 wrote:
| I don't consider a demo app with no docs (that presumably
| uses stimulus and turbo?) to be anything to close resembling
| good overview docs on what stimulus and turbo are, but
| thanks.
| NegativeLatency wrote:
| The readme seems to give a pretty good overview of turbo:
| https://github.com/hotwired/turbo-rails
| jrochkind1 wrote:
| Perhaps. And here's stimulus' official web page.
| https://stimulus.hotwired.dev/
| TranquilMarmot wrote:
| It's worth noting that this presentation is from 2016, so it is
| over 6 years old now
| andrewmutz wrote:
| I agree that Rails 7 has fantastic options for achieving
| fantastic "UI Fidelity" with traditional Rails high developer
| productivity.
|
| The official docs are decent:
|
| https://turbo.hotwired.dev/
|
| https://stimulus.hotwired.dev/
| togaen wrote:
| lol, and yet the page doesn't load with JavaScript disabled
| holysantamaria wrote:
| I still don't consider myself a veteran but I saw the web evolves
| from 2010 up til now. And imho we took a wrong direction. Web
| apps and pages have become so bloated and complex that's crazy.
|
| I'm just starting to recover from my previous work. I had to
| maintain migrate and add features to a legacy system (built in
| 2017) which had initially a GraphQL api and a SPA, but that was
| later split in 12 microservices (with cycling dependencies
| because hey why not) and 3 Big react applications, all of that in
| Javascript + Typescript (added later with all the gradual typing
| stuff that makes you think that your code is correct).
|
| All of that to serve 300 monthly users between 35 and 50 years
| old, who just cared about filling forms here and then and have
| some charts over data. 0 rocket science.
|
| So far I remember history going like this: - 2010 Clean SSR with
| rock solid boring technologies and some vanilla JS where it made
| sense, I remember page load where crazy fast and you could not
| feel the need for an SPA. - 2012 NodeJS arrives. It came to save
| us from slow blocking IO apparently (??) - 2016 React arrives. It
| came to save us from boring old SSR apps - 2017 All React + SPA
| frameworks (in house often) - 2017+ Someone has the brillant idea
| to do SSR with React. "It's a revolution" - 2017 GraphQL arrives.
| You are saved. - 2020 Nextjs arrives. You can now do static
| generation for SEO and SSR and apis ! That's great. Thank you
| Next ! - 2022 Someone wants now to do Server Component that will
| make your page load going insanely fast (which we already did in
| 2010 when we carefully loaded vanilla JS at the time)
|
| I learned a bit of ASP.net core recently, and I think that boring
| razor pages are still relevant.
|
| I remember my first lead in 2010 telling me that ORMs and SPA
| where completely overrated. I didn't agree with him at that time.
| Now 12 years later I think he might have been correct.
|
| I'm not saying SPA have not their place. Some apps can't do
| without it. I'm saying that we are victims of "hype driven
| development" which involve having some trendy hashtags in your
| resume and convince your manager that you have seen an incredible
| new tech that will make the business incredibly wealthy. Except
| it does not and you end up with a legacy system that nobody wants
| to maintain because too complex.
|
| Maybe like Jonathan Blow stated in one of his videos, we make a
| confusion between going forward and progress. Now all the new
| kids learn React in some boot camp or online but have no idea how
| to implement a map function. And I feel old and grumpy. And tired
| by all this.
| etchalon wrote:
| This slideshow is relatively old, and frameworks have gotten
| better, not worse, since then.
|
| Server-side DOM mutation is deeply interesting, but I don't think
| it can be grafted onto existing server-side frameworks. Someone
| will need to rethink the MVC model with client-side state in
| mind.
| rickreynoldssf wrote:
| TL;DR: We did JavaScript wrong and now we're going to do it even
| more wrong.
| MForster wrote:
| Unreadable on a phone...
| xutopia wrote:
| While I don't know that I'd go that route to build my own thing
| when Rails 7 already has turbo_streams and Stimulus I understand
| wholeheartedly why they'd move away from SPA-for-everything. I
| can't help but feel that the whole industry is under the spell of
| React and other single page application frameworks and use them
| even if other ways would have been faster to build, cheaper to
| maintain and less complex.
| cldellow wrote:
| It's worth noting that this presentation is from July 2016, and
| Rails 7 was released in December 2021.
| [deleted]
| spritefs wrote:
| > We're breaking up with JavaScript front ends
|
| > Site doesn't load properly with javascript disabled
|
| They should put their money where their mouth is
| dpacmittal wrote:
| I think it was about breaking up with SPA frameworks/libraries.
| The whole slideshow is about unpoly which is a JS library which
| provides SPA like experience without the complexity of a full
| blown SPA
| ncr100 wrote:
| Maybe this is an abandoned site?
|
| - Site does not support HTTPS https://triskweline.de/unpoly-
| rugb/#/ => breaks
| aussieshibe wrote:
| Maybe it's just me, but needing to press "back" twenty or so
| times to get back to HN after viewing some of this presentation
| really made me question the author's authority when it comes to
| "how the web should work".
| quickthrower2 wrote:
| Not sure. Does everything on a public url need to be friendly
| to random forum shares? Maybe this is good enough for the
| people who needed to see it.
| whoIsYou wrote:
| huh? this page is unusable. is this a spoof?
| locallost wrote:
| The key question for me is not whether there is too much
| complexity, but whether or not this complexity is something that
| adds value for the actual user. Too many things do not actually
| do that. I use too many pages where I know it's some kind of an
| SAP simply because the user experience is buggy, clunky and
| shitty. Why that is, is a really big topic and there could be
| many reasons, but it's not really discussed.
| jesprenj wrote:
| https://xkcd.com/927/
|
| There are fourteen competing standards ...
| account-5 wrote:
| I haven't scroll the whole way through, and am a complete novice
| to webdev but this is reminding me of htmx a little. Is it just
| me?
| qrohlf wrote:
| Seems like a half-baked agency-built version of htmx[1], no?
|
| I'm actually very intrigued by the whole "let's take a step back
| and move a lot of our logic back to the server" approach to
| modern dev, but IMO when you need more than statically rendered
| pages, it should look a lot more like htmx or Phoenix LiveView
| (if you're using a framework) or something ultra-minimal like
| Slimvoice[2] if you want to go the bespoke route. Not this.
|
| [1] https://htmx.org/.
|
| [2] https://javascript.works-hub.com/learn/a-javascript-free-
| fro.... https://slimvoice.co/
| boxed wrote:
| I've tried to use htmx exactly two times. Both times it just
| ran directly into a brick wall, because it's so limited and has
| no escape hatch where you can put your own logic. Their
| solution to this is their half baked new language, which isn't
| ready, a new language, and seems very much unclear. All they
| needed was proper hook points.
| 0xblinq wrote:
| In my opinion Unpoly does this in a very nice way, with what
| they call "compilers".
| t8sr wrote:
| Alternatively, web developers could calm down and just write
| mostly HTML with some plain javascript where warranted.
|
| I've recently done some web development for the first time in
| 12 years, and I was horrified at all these pointless frameworks
| that break every usability win web browsers have made in the
| past 20 years, cost extra bandwidth and have atrocious
| performance. Like, why? Can web devs really not learn the 4
| functions that make up the websockets API? Do they really need
| a special framework named after a coffee bean?
|
| This kinda crap is why the gmail tab uses a GB of memory.
| waboremo wrote:
| Tools like htmx aren't the reason the gmail tab uses a GB of
| memory. You'll find the majority of cases where pages are
| using way more resources than it should, are due to reasons
| forced on web developers, like a billion different trackers
| and several different ad networks, and workarounds to ad
| blocking to sell more subscriptions, etc.
|
| This is what is so shocking to me when HN spends such an
| absurd amount of time rallying around this idea that
| frameworks are the reason sites are bad. Mind you, I do think
| a lot of them are misused, but 99.9999999% of poor websites
| aren't because of the framework chosen.
| smaudet wrote:
| If you can limit yourself to exactly one, maybe two
| external deps, which are really just to make your dev life
| eaiser, you may have something of a point.
|
| You have to remember that a large chunk of "web apps" means
| "electron apps" which are absolute bloated pieces of junk
| next to their desktop cousins.
|
| You also have to remember a 'framework' typically doesn't
| stand in isolation - tens, hundreds, thousands of
| dependencies typically lurk.
|
| We all agree tracking junk makes it even worse, but the
| whole thing is already overcomplicated before you get to
| that point.
| ryanbrunner wrote:
| > You also have to remember a 'framework' typically
| doesn't stand in isolation - tens, hundreds, thousands of
| dependencies typically lurk.
|
| While this is true, at least by having a large number of
| people commit to the same set of dependencies, you stand
| a higher chance of complications between those
| dependencies being ironed out, either directly by the
| framework maintainers or by the user base of the
| framework.
| t8sr wrote:
| According to my browser, the default view in gmail needs
| 8.32 MiB of javascript spread over 90 files to render.
|
| While IDLE, the gmail tab uses 10-30% of an M1 CPU core.
|
| That stuff is not down to tracking - it's because the damn
| thing keeps messing with the DOM, because it has some
| insane structure where javascript controllers are attached
| as strings to DOM elements, because it uses about 100 divs
| to render every row in the list of messages, and because
| every message is nested literally 15-30 layers deep in a
| pointless tree of divs.
|
| I am sorry, but web frontend is an insane dumpster fire.
| smoldesu wrote:
| What browser are you using? Having Gmail open doesn't
| even use half of a percent of a single core on my machine
| (Linux, x86, Chromium).
| nicoburns wrote:
| Gmail is just poorly written. The old version of Gmail was
| still an SPA, and it was perfectly quick.
| t8sr wrote:
| Yeah, I agree - the old version of gmail was perfectly
| reasonable. But the current version is IMO representative
| of trends in web dev. Google is both influential and tends
| to follow the recent trends. Gmail is by no means unique -
| every web app created in the past few years is the same
| insane jumble of frameworky js code and a DOM 100 layers
| deep, just because someone can't be bothered to learn CSS
| and plain JS.
| nicoburns wrote:
| Google's frontend engineering tends to be pretty poor and
| out of step with wider industry practice in my
| experience. They have created not one, but 3 of their own
| frameworks (Angular, Angular 2 and Polymer), two of which
| (Angular and Polymer) were rather poorly performing, and
| the third of which is kinda ok but doesn't seem to be
| that widely used internally. They tried to create their
| own frontend language (Dart), which nobody uses.
|
| Meanwhile most of the industry is using React, which is
| actually pretty well engineered and perfectly fast (you
| may well find yourself using a slow React app, but that's
| not React's fault).
|
| P.S. Talking layer of DOM nodes, I actually did a few
| samples of this the other day. Gmail has 34, which was by
| _far_ the deepest of any website I checked and probably
| isn 't helping it's performance.
| 0xblinq wrote:
| Well, get ready for it. GitHub is moving towards React,
| Next, etc. I bet it will be another disaster like Reddit.
| neoberg wrote:
| As a side note; iirc the old version of Gmail was the first
| big scale example of SPAs.
| 0xblinq wrote:
| To me it looks like the opposite. It's more batteries included,
| easier to use and has been around for longer. I like htmx too,
| but too me it's only better on the marketing side.
| caseyf wrote:
| More like a hotwire but instead of being extracted from
| Basecamp's work it feels like it could have been extracted from
| Makandra's work maintaining many different Rails apps.
|
| I think it's very good and for me, the best of the bunch. I'm
| moving a very large app to it (from old school RJS) and it
| seems to have thought of everything that I need.
| dinkleberg wrote:
| Just want to point out that unpoly has been around for ages
| (looks like since 2015). This isn't a copy of htmx.
| smrtinsert wrote:
| I had this going back around late 2000s with jQuery and Spring
| Web Flow. It was absolutely glorious. Server side declarative
| navigation (great for dev coordination), seamless transitions,
| less bandwidth consumed, super simple client side rendering, no
| more issues with the PRG pattern and user interference, and I
| even think I put in even listeners to execute animations based
| on the return fragment.
|
| Never was allowed to put it into prod - "didnt need it". Oh
| well.
| cphoover wrote:
| My problem with liveview IMHO is that it requires an active
| internet connection and doesn't have offline support, which is
| a step in the wrong direction in terms of UI performance to me.
|
| It makes sense for a subset of applications that require
| connectivity but many apps or tools should be able to work
| offline or without a constant connection.
| 0xblinq wrote:
| Livewire is intended to be used where you'd otherwise need to
| do an API call anyway. It is not intended to handle every
| single click and toggle and key press. You still do that on
| the front end, usually with Alpine.
|
| It is a way to avoid writing backend APIs.
|
| If you're sending every click or every key press then it's
| not the tools fault. I agree though, that this should be
| better explained in their docs.
| ramesh31 wrote:
| >I'm actually very intrigued by the whole "let's take a step
| back and move a lot of our logic back to the server" approach
| to modern dev,
|
| What's old is new again.
|
| There's an entire generation of developers now who have no
| concept of the old world. They started with React/Angular/Vue
| and have no idea that SSR was the standard default for decades.
| And now it's a "new idea" that is held up against JS
| development with no understanding of why and how we got to
| where we are, and the tradeoffs that were made along the way.
| whatever1 wrote:
| SPAs solved a labor problem I think. It was the reason that
| front end development grew so fast.
|
| It is much faster to train people on a combo js+css framework
| rather than training someone on backend languages, databases,
| queues, authentication, scaling + html & css for server side
| rendering.
| claytongulick wrote:
| Or maybe people don't like waiting for a page to load each
| time they click a button?
| yetanother12345 wrote:
| IMHO this is a false argument.
|
| Ask yourself: Do "people2 prefer looking at "spinners" or
| more-or-less animated "page loading..." texts?
|
| Waiting time is the issue, the technology is not.
|
| A server generated page that loads fast beats a
| Framework-generated page hanging every time!
|
| As for technology:
|
| With "classic" server generated pages "people" will know
| what is going on (browser indication tht page is loading)
| and they will know what to do (wait a few seconds at
| most). With frameworks "people" are left out in the cold
| with no indication what the problem really is and no
| apparent remedy or path for solution as a page refresh
| might interfere with state logic or whatnot bringing
| totally undesired results.
| jrochkind1 wrote:
| That seems strange to me as being an "old school" developer
| I have a _lot_ more trouble trying to get a hang of the new
| front-end stuff than I do learning a different back-end
| framework.
|
| But I guess that is just me/generational? Ironically, I
| feel like there are a lot more job openings for front-end
| than for back-end now, and I'm much more comfortable on the
| back-end.
| AtlasBarfed wrote:
| Then why is every JS-bro "full stack"?
| knightofmars wrote:
| IMO, I think this is a valid question (though asked a bit
| crudely). To generalize, it's because someone who has
| done JavaScript programming can point to NodeJS and say,
| "I'm full stack." Which, while technically true, skates
| over the reality of NodeJS as a less than ideal backend
| (see Ryan Dahl and the dawn of Deno). Second, it's more
| lucrative to bill oneself as "full stack" even if in
| reality a person isn't. At one point in my career I would
| have considered myself "full stack". Over time I realized
| that a "full stack" engineer is a jack-of-all-trades
| type, which in theory, can be valuable in the right
| circumstances as an individual doing work alongside non-
| full-stack engineers. Asking a room full of "full stack"
| engineers to design and build a product of any complexity
| above CRUD will naturally lead to a self-sorting of UI/UX
| and server side engineers.
| strife25 wrote:
| Labor wasn't the issue, it was UX.
|
| Users wanted responsive UIs and Gmail showed the power of
| AJAX in the browser. In the mid-2000s, server power,
| network latency, and maintaining state were the challenges.
| The UX was more powerful when the client tracked state,
| only requested the data it needed, etc.
|
| Things have flipped. SPAs became bloated as abstractions
| were introduced. Network latency and server power is not an
| issue anymore. Rendering a bunch of HTML is as quick as
| rendering JSON.
|
| As a vet of the IE7 days, I love this trend. Leveraging the
| best of server compute and browsers is going to simplify
| web app development a LOT.
| pjmlp wrote:
| Ajax was created by Microsoft to show Outlook on the
| browser....
| t8sr wrote:
| AJAX in early Gmail was a massive improvement. It was
| mostly hand-coded javascript in a relatively thin page
| and it was the sweep spot. Today's version of gmail is
| the most bloated pile of spaghetti framework code
| imaginable and is far less responsive and usable than the
| plain HTML version.
| _gabe_ wrote:
| We use SPAs and a pretty strict typescript/react stack. And
| I still have to know:
|
| Cloud Tech (AWS) which also includes, lambdas, Iam
| management, dynamoDB, cdk or serverless, API gateway, S3,
| secret managers etc.
|
| Add to that list the technologies that often get thrown in
| for extra monitoring testing etc. Jest or mocha/Chai for
| unit tests. Dynatrace for monitoring. Kibana or something
| for logs. Some tool for analytics. Github actions for
| setting up deployment and CI. Maybe you need redis for
| intermediate caching, etc.
|
| In addition, before you kind of sort of had an intuition of
| how the data flowed through your basic stack from the
| database to the web page. Nowadays who the heck knows
| what's happening. You'll hit some api gateway endpoint
| which auths through a random lambda who knows where on what
| server, then it will go hit the actual lambda that holds
| the function you want to call which may reach out to a
| database but get intercepted by the redis cache etc etc
| etc.
|
| Yes modern web dev is definitely much simpler /s.
| misterpurple45 wrote:
| I see this "AWS for everything" Well-Architected stuff
| everywhere. AWS benefits greatly from inserting itself in
| between all our architectural layers.
|
| There's nothing stopping companies from using the cloud
| for its primitives (compute and storage), maybe with
| managed FOSS services (RDS Postgres). We don't _need_ to
| go all in on AWS to build a 'modern' web application. Yet
| somehow much of the industry dances to AWS' tune on how
| to architect software.
| 0xblinq wrote:
| And good luck with having a development environment or
| even decent end to end/integration testing once you start
| using all those services.
| __jem wrote:
| You may work at a company that requires fullstack
| expertise, but there are plenty of other companies where
| frontend developers are fully insulated from all those
| cloud technologies. I'm not sure what your point is here
| tbh.
| 0xblinq wrote:
| A friend of mine moved to a company where they use plain
| Laravel (with just some sprinkles of js using Alpine) and
| they deploy to heroku. A team of 10 devs, no
| systems/devops/Infra and he's fascinated how well things
| go and how fast they ship stuff compared to where we
| worked together before (with all the usual react/redux
| stuff and an elixir backend on kubernetes)
| whatever1 wrote:
| I wouldn't say modern web dev is simpler, I just think it
| is more decoupled. This helps with training for &
| staffing the more specialized roles that emerged.
| [deleted]
| qrohlf wrote:
| I both agree and disagree with this take.
|
| I started out hand-coding static html pages, graduated to
| Drupal and Wordpress php stuff circa 2009 (glad that's
| over!), then worked on a largely server-rendered Rails SAAS
| in the APM space that I guarantee you've interacted with if
| you've been in the web game for more than a couple years.
| These days, I may sling React for my 9-5 but a lot of my
| personal projects and internal tools are vanilla express apps
| with very little client-side code.
|
| It's true that a lot of newer devs really don't have a great
| deal of context for why React & company became the de facto
| default for building websites and how much we used to get
| done with largely server-based architectures. I wish we did a
| better job of teaching fundamentals here rather than
| bootcamping everyone straight into building SPAs.
|
| However, it's also true that the baseline expectation for web
| experiences is a lot higher in 2022 than it was in 2009 in
| terms of the level of responsiveness, interactivity, and
| overall "app-like-ness", to the point where I think that even
| with the massive improvements in bandwidth, latency, and web
| protocols, we still need to accept that there are many cases
| where just shoving full HTML documents over the wire isn't
| enough to satisfy user & stakeholder expectations. That's
| where stuff like LiveView, htmx, and Web Components become
| interesting to me. The web has evolved, and finally the
| server-side-application paradigm feels like it's starting to
| evolve along with it, and these evolutions do feel like
| they're novel & useful enough to deserve being called "new
| ideas".
| t8sr wrote:
| > However, it's also true that the baseline expectation for
| web experiences is a lot higher in 2022 than it was in 2009
| in terms of the level of responsiveness, interactivity, and
| overall "app-like-ness", to the point where I think that
| even with the massive improvements in bandwidth, latency,
| and web protocols...
|
| What? The exact opposite is true: the average web app
| (including ones like gmail) is far less responsive, slower
| and heavier than it was 10 years ago. On my M1 Pro, gmail
| renders at about 20 fps and takes 2-3 seconds to load on
| gigabit fiber. The web has never been shittier than it is
| today.
| chiefalchemist wrote:
| Yes "app-like-ness" when that's appropriate. But a lot of
| the web isn't that. Yet devs / agencies are using a
| sledgehammer (e.g., React) when a Phillips head screwdriver
| is what's need.
|
| Users get experiences they don't need (nor want). Site
| owners gets a maintenance dependency they don't want (nor
| need).
| 0xblinq wrote:
| From my experience, this problem is also rooted on
| designers and product owners.
|
| My own team "modernized" a forum/blog tool used for
| internal documentation by moving a lot of it to react and
| SPA architecture and added ton of "app like" features,
| and I just hate the thing now. The old version, which we
| still run on some installations, is way, way faster,
| easier to use, more responsive and more reliable.
|
| But hey, it looks so App-like now...
|
| Sigh...
| TranquilMarmot wrote:
| I think the basic divide is something like "CRUD forms"
| vs "interactive applications".
|
| I've built basic CRUD forms with ASP.NET MVC. I've built
| them with Rails. I've built them with React (+ a hundred
| random libraries). I've also built interactive "apps" in
| those languages.
|
| Looking back, the amount of "interactivity" that React
| adds to a CRUD form is NOT worth the added complexity.
| But! Right now my dayjob is creating an _insanely_
| complex app that you could not have done five years ago
| with Rails (or, like this presentation is about,
| something like Unpoly).
|
| I think a problem is that React is just more _fun_ to
| work with than basic server stuff so devs want to work in
| it. The added complexity is worth it to have more fun.
| Maybe that's just me, though. I know a lot of people see
| React as a hammer to hit every nail with, and I was like
| that for a long time, but I'm starting to come back
| around to more server-driven use cases for simple sites.
|
| I've been messing with Fresh a lot lately and it's a nice
| middle ground of defaulting to rendering _most_ stuff on
| the server, but you can have "islands" of interactivity
| that get sent to the client as JS. I'm not sure if it
| will end up gaining traction, but it's pretty nice.
|
| https://fresh.deno.dev/
| 0xblinq wrote:
| I agree with everything you said up to the part about
| fresh and deno, where it looks like you're falling in the
| same trap of those wanting to use react. You don't even
| notice it but this is the problem. Always thinking the
| next shiny tool will solve the problems.
|
| Rails, Lararavel and similar frameworks are great for
| crud apps. No need for fresh or demo or svelte or next.js
| for that.
| 0xblinq wrote:
| > However, it's also true that the baseline expectation for
| web experiences is a lot higher in 2022 than it was in 2009
|
| Is it?. I think this expected behavior and increased
| complexity comes more from designers and product owners
| than from real actual users.
|
| I, as a user, still enjoy a lot more the old Reddit
| (old.Reddit.com) than the new one. I even prefer hackernews
| than many other more "modern" forums that feel slow and
| bloated. And I also prefer the current GitHub to what I bet
| it will become the moment they start moving it to React.
| duxup wrote:
| > What's old is new again.
|
| I work on some old ColdFusion apps.
|
| Some aspects feel very modern.
| dmix wrote:
| The way it componentized the different 'cards' or fragements
| with URL-style lego blocks seems to be the primary novel
| feature that's layered on top of HTMLX.
|
| This is already the direction that Remix and Deno's Fresh
| framework seem to be taking, at least spiritually. Isolated
| server-rendered-first approach and only bare minimum JS loaded
| for fragments/islands that need to be interactive beyond what
| can be loaded on pageload.
|
| The html attributes vs JSX style templates is really a matter
| of taste IMO. Although I haven't used htmlx I get the feeling
| it would be limiting for more complex cases and involve a lot
| of hackery or pigeonholing complexity better served by straight
| up Typscript.
| sph wrote:
| Unpoly is pretty good, and operates on a slightly different
| level than htmx, which is all about AJAX. Also, this slideshow
| is from 2016, when htmx was pretty much unknown.
| zozbot234 wrote:
| I'd try to optimize logic on the client before moving more
| logic back to the server. This is essentially what Svelte and
| SolidJS do - they clean up a lot of the existing overhead of
| SPA solutions. Of course, rendering server-sent HTML as in the
| HTMX model (or perhaps HTML generated in-client via WASM)
| instead of doing costly fine-grained DOM updates could then be
| added as a further optimization.
| quechimba wrote:
| Nice, though it would be nice to eliminate the need to write any
| JS. I disagree with page 17, I think server side apps could
| handle those things fine if they were made to support them.
|
| I've been working on a Ruby framework with all the fancy stuff
| (reactive VDOM, hot reloading, scoped css) but it's 100% server
| side. Imagine React, but with Ruby and Haml instead of JS, and
| all logic runs on the server.
|
| The GitHub link can be found in my comment history. It's not
| ready to be used for anything serious, but I think it's an
| interesting approach and maybe there is someone who would like to
| play with it.
| matchagaucho wrote:
| Web front ends have been expanding, per Parkinson's Law, to fill
| the bandwidth allotted.
|
| If it's not an explosion in JS/CSS from frameworks, it's the
| content image/video size.
|
| Upside is that a "fast" user experience is easily achieved by
| defaulting to first principle JS capabilities of the browser, and
| delivering compressed content from the CDN edge.
| [deleted]
| kyleyeats wrote:
| This is so overdue. I'm ecstatic to see this finally happening.
| The frontend framework bloat trend honestly went on ten years too
| long. It was like the thin client and thick client debate turned
| into the thick client and thicker client debate.
|
| People will roll a gigantic create-react-app mess for the tiniest
| of frontend projects. Yes, it's an instant codebase! But that's
| all code you have to maintain. Stuff like hotwire and htmx can't
| come fast enough.
| dmix wrote:
| This isn't the only one... JS frontend world as a whole has
| been moving back to SSR for the last 5yrs. But importantly
| while still maintaining the benefits of desktop-style
| interactivity, instant page transitions, componentized code
| organization, treeshaking/ + lots of small JS/CSS files only
| loading what's needed vs one massive asset, cached/offline
| friendly JSON data streams, etc, etc.
|
| It is still SSR but it's much much more than just going back to
| 2005. Combining the lessons of the last 15yrs with the as much
| of the past SSR world as possible. It's not simply throwing it
| away and regressing to the old ways.
| tobr wrote:
| I don't see the difference. Isn't backend code code you have to
| maintain too?
| PKop wrote:
| You need a backend anyways. Shifting to a server-side
| codebase is eliminating duplication, and arguably server
| languages have better DX so win win.
| tobr wrote:
| That might sound convincing to someone who already prefers
| working on the backend, but you can basically invert your
| statement to describe a typical serverless setup: "You need
| a frontend anyways. Shifting to a client-side codebase is
| eliminating duplication, and arguably browsers have better
| DX so win win."
| spoils19 wrote:
| Most backend developers are used to maintaining high
| quality codebases, however. On the other hand...
| personalidea wrote:
| Uhh. Cheap shot, very constructive...
| PKop wrote:
| You still have to connect with data somewhere which often
| means running an api server connecting to database.
| There's certainly options to outsource this to managed
| services, but "serverless" and distributed systems can
| often be "more complexity" unnecessarily, without any
| corresponding productivity or functionality gain.
|
| There's a clear trend back to the server to _some degree_
| , so on the margin what I'm saying seems to have some
| basis in many people's experience, where the sweet spot
| of many apps does not require the added complexity of
| SPA's or lack of expressiveness of writing so much app
| code in javascript, building distributed systems, or
| having to use Firebase style non-relational database
| services. Moving much of this to the server reduces some
| of this complexity often with productivity gains.
| quonn wrote:
| > or lack of expressiveness of writing so much app code
| in javascript,
|
| ???
|
| Modern SPAs are typically written in TypeScript which is
| very expressive and using frameworks to structure them.
|
| One may like or not like the tooling around it, but the
| language and code is just as robust and clean as any
| backend code.
| kyleyeats wrote:
| Yeah it's gonna be somewhere. I guess it's really about the
| sweet spot that minimizes the complexity on both sides. This
| captured it: https://imgur.com/a/mx7Y0uD
| dajonker wrote:
| The project is originally from 2014 and the presentation seems
| to be from 2016.
| kyleyeats wrote:
| Hence the 'finally'!
| dougdonohoe wrote:
| Sort of sounds like Apache Wicket (https://wicket.apache.org/). I
| used it for a few projects in the mid-late 2000s. I really liked
| it being server side and the concept of having object-oriented
| HTML (code paired with HTML snippets). I haven't had a need to
| use it since 2014, so haven't kept up with the project.
| sph wrote:
| Needs a (2016) in the title. The situation is even worse now.
| riskable wrote:
| At this point web development has become _so_ complex and fast-
| changing that by the time you 're done explaining how
| everything works the whole world has moved on to the next
| generation of complexity. We're almost at the point where web
| development is becoming "unknowable"; like knowing the position
| of an electron... You can know where it _was_ at some point
| (maybe) but really the best you can do is estimate its rough
| position in _the cloud_.
| black3r wrote:
| Is it really worse now though? As a full-stack developer since
| 2013 (Django on backend since the start, React on frontend
| since 2015), I think it's finally getting better in the past
| couple of years, and I think it was worst between 2016-2019...
|
| After years of not knowing what to use because the libraries
| I've used 2 years ago are no longer maintained or their APIs
| changed 3 times since then, there's now Next.JS which seems
| like a well supported, batteries included, opinionated
| framework with good documentation...
|
| with vite and esbuild on the rise, the days of fiddling with
| webpack and other complicated build configurations may soon be
| behind us...,
|
| typescript vs. flow seems to have ended with typescript being
| the clear winner and having great support in most libraries,
| frameworks and IDEs... (although I'm a bit scared that the JS
| native type annotations proposal may again fragment the typing
| world here...)
|
| browser-side APIs are no longer evolving so rapidly, IE11 &
| EdgeHTML are dead and there aren't that many features/bugs
| specific to Firefox/Chrome/Safari anymore...,
| arcturus17 wrote:
| Does Nextjs make you use Django less? I think my basic
| process going forward is going to be Nextjs + something like
| Supabase as default and only add a more complex backend as
| needed.
| hn_throwaway_99 wrote:
| > The situation is even worse now.
|
| Is it really? I have the exact opposite opinion. I mean, I feel
| like the industry has pretty well standardized on React in
| Typescript for the front-end on web apps. Sure, there are other
| technologies that do different things (e.g. Svelte, and someone
| else mentioned Phoenix LiveView), but for the standard "I'm
| building a CRUD-focused web app", there are simple choices to
| make and it's easy to "do the right thing". I contrast this
| with 2016, when things were still in flux so it was much easier
| to make what turned out, in hindsight, to be the "wrong" choice
| (e.g. Angular or Flow). Plus, tooling support is _much_ better
| now.
| mattlondon wrote:
| React is used a lot, but it is _certainly_ not the standard.
| Angular is still used extensively, especially in enterprise
| hn_throwaway_99 wrote:
| I'd still argue that React is very much the default for
| _new_ applications where legacy interop or existing team
| familiarity isn 't a factor.
|
| I mean, this is obviously an extreme example, but COBOL is
| also still used extensively in the enterprise, yes it's
| still not really used for any new projects.
| vladstudio wrote:
| Probably worth mentioning that the submitted link is just the
| presentation by the author of Unpoly, with some history and
| reasoning, but the better explanation of Unpoly itself is on
| their website:
|
| https://unpoly.com/
|
| Essays on HTMX website also help a lot:
|
| https://htmx.org/essays/
| mr90210 wrote:
| GOOD FUCKING LUCK
| anujdeshpande wrote:
| Genuine question : Is anyone building a 10 year JS framework?
|
| Something similar to how we've had C standards - we had c99 and
| then c11 (followed by c17)
| holysantamaria wrote:
| http://vanilla-js.com/
| 29athrowaway wrote:
| (2016)
| 29athrowaway wrote:
| I summon @dang in attack mode.
|
| Can you add (2016) to the title? Thanks
| blubberblase42 wrote:
| This is a published presentation not a blog post. That was the
| reason to use this format.
| tannhaeuser wrote:
| Since TFA is from 2016, it's pretty silly to discuss about trends
| here isn't it? There's certainly no less JS today, except due to
| being there less web sites in the first place.
|
| What's with this htmlx shilling anyway? If you want an app, just
| use JavaScript; what's the point of arbitrary syntactical
| barriers between page content and logic, except for maybe CSS
| done by UX experts - though if you're bad at CSS then why tf are
| you into web frontends anyway?
|
| If OTOH you think about content-heavy sites, document-oriented
| workflows, and publishing (ie. what the web was originally made
| for) then just use a competent markup processor. HTML is based on
| SGML after all, giving you templating, markdown processing,
| stylesheets, pipelines, toc and search indexing, and whatnot;
| there's a wealth of SGML/XML-based tools available.
| deafpolygon wrote:
| I wonder how much traction we could get with a no-JS approach.
| quickthrower2 wrote:
| Modern browsers make a no-JS (and that means not even HTMX)
| fairly nice. Live updates might be an issue but if you don't
| need those...
|
| When the browser can reason about your site it opens up nice
| cool stuff like right click to open in a new tab, bookmarks
| always working, fast load times, caching, etc.
| simonw wrote:
| What's the accessibility story for Unpoly?
|
| I'm always interested in ways of building partial page fetches,
| dropdown menus etc in a way that is thoroughly tested to work
| well with common screenreaders.
|
| I'd love to see a frontend framework that includes detailed
| documentation (and ideally video demos) demonstrating how
| effective their ARIA screenreader stuff is.
| omnimus wrote:
| Why would the story be different than SPAs? The screenreaders
| read final html in the browser. It shouldn't matter if comes
| from server rendered template OR javascript template rendered
| on the client.
|
| Seems like it depends on how you code the html/templates not
| how they are rendered?
| triskweline wrote:
| Unpoly lead dev here
|
| Unpoly takes special care to always move the focus to the next
| relevant element in an interaction. E.g. when a link updates a
| fragment, the focus is moved to that fragment. Or when an
| overlay is closed, focus is returned to the link that
| originally opened that overlay.
|
| More details can be found here:
| http://triskweline.de/unpoly2-slides/#78
|
| Feel free to install a screen reader and play with the demo app
| (https://demo.unpoly.com/).
| mattlondon wrote:
| This is where Angular shines Vs React et al. One "batteries
| included" library that does everything, no external dependencies
| unless you go out of your way to add them.
|
| I have (and still do) written SPAs that _only_ use Angular and
| nothing else. I don 't even have NPM installed.
| jokoon wrote:
| Why can't anybody talk about the fact that HTML was not designed
| for being dynamic?
|
| Isn't there any format that is a real alternative to HTML, which
| is truly interactive, lighter than the DOM, use text as a mediu,
| is multi usage and platform agnostic, can use whatever scripting
| language, and be easily rendered?
|
| It's not another new format, it's just that a new format is
| needed to make things simpler.
|
| I have zero patience when it comes to learn angular and its
| framework model thing. I don't want framework, I want formats and
| protocols.
|
| I don't even know gopher but something new and fresh and
| different is really needed. Maybe as long as it's used in a
| controlled environment for internal/pro software.
| grishka wrote:
| Whenever I build something on the web, I can't help but feel
| like I'm dealing with a word processor. A very advanced one,
| but nevertheless still a word processor at its heart. Coming
| from native apps, I despise the idea of text _just being out
| there_ without a TextView or something.
|
| I also miss Flash.
| spideymans wrote:
| That's exactly what it feels like. A word processor distorted
| into an application development platform. With nearly 30
| years of technical debt as well.
|
| This is becoming untenable. The web has only gotten more and
| more difficult for novice users and developers alike to
| publish onto. That spells doom for the web in the long run.
|
| I wish we had a clear path out of this trap.
| wefarrell wrote:
| No markup format will support interactivity well, you need a
| full scripting language with all of the standard features.
|
| I don't think it's possible to couple the interactivity and
| visual layout in a single language and have it make sense. We
| can certainly do better than JavaScript, HTML and CSS but I
| think there will still need to be at least two languages to
| describe layout and interactivity.
| temporallobe wrote:
| HTML wasn't designed to be dynamic but it certainly evolved to
| be, and personally I don't think it's that bad per se, but
| modern frameworks such as Angular and React have added so many
| unnecessary layers of complexity, that most developers have to
| reason about and work with several layers of abstraction just
| to make simple things work. There isn't a real alternative
| because all the popular modern browsers only fundamentally
| understand HTML, and have been evolving and refining this over
| the past three decades or so. What would be nice is to have a
| new markup that is natively rendered and handled by the browser
| and that behaves similar to the document/page model everyone is
| used to but with built-in persistence, session handling, and
| dynamic rendering with a very simple and intuitive API.
| Obviously we have all of these already in one form or another
| but it's all just hacked-together HTML/JS/CSS under the hood.
| Edit: minor corrections because mobile devices suck
| npilk wrote:
| Have you tried htmx? Maybe HTML wasn't designed to be dynamic,
| but IMO htmx does a great job extending it to provide
| interactivity in a way that feels natural and simple.
| artursapek wrote:
| You should break up with web based front ends and write them in
| Rust. :-)
|
| https://iced.rs
| rawrenstein wrote:
| > It is inspired by Elm, a delightful functional language for
| building web applications.
|
| That killed my interest instantly.
| sheerun wrote:
| For me it's TODO all over
| awesomegoat_com wrote:
| That's the correct answer!
|
| Btw, client can run rust in WASM, so no reason to keep
| javascript in there either!
| satvikpendem wrote:
| Soon Flutter will have WASM support too, so it'll be a great
| time. I've been looking into stuff like Iced, Yew, Tauri etc
| but the multiple client situation for cross platform isn't
| too great, unlike with Flutter.
| [deleted]
| im_down_w_otp wrote:
| I would love a way to view this exact same content as a long form
| vertical scrolling article/post rather than as a virtual slide
| deck.
| ramesh31 wrote:
| Yeah, perhaps if only there were a structured markup language
| that could be used to provide this information in an accessible
| manner with separation of concerns between content and display.
| krapp wrote:
| impossible!
| ostenning wrote:
| The biggest problem facing the front-end space today isn't so
| much of complexity of a particular library, rendering technique,
| or view/model architecture, but rather lots of bad ideas glued
| together, creating nightmare scenarios for companies trying to
| maintain products.
|
| A micro dependency system with never ending breaking changes to
| glue different tools and libraries together - bad idea.
|
| Using un-opinionated "libraries" that don't scale well, but at
| scale - bad idea.
|
| Technology organizations trying to stay relevant by simply
| adopting every next hyped fad out there, rather than stepping
| back to get a bigger picture of what the front-end space actually
| needs - bad idea.
|
| The list goes on, for quite a long time.
|
| And all of these issues are further exacerbated by an army of
| junior developers entering the front-end development space, along
| with recruiters subscribing to buzzwords to hire them.
| hinkley wrote:
| To me one of the unsung skill sets of the industry is tool
| selection. The ability to look at a tool and imagine how it's
| going to behave for different pay grades of coworkers,
| different specialties, and to predict how that will pan out in
| the future.
|
| Sometimes you pick the simpler tool, and hope it has legs.
| Sometimes you tweak your product roadmap to dovetail with the
| tool's. Sometimes you push to get 25% of a feature set released
| so you can make progress. Sometimes you temporarily add another
| tool, and sometimes you fork for a while.
|
| What most people just do though is measure power of the system,
| ignoring the Principle of Least Power for third party code, if
| not in fact for the entire project. Approachability is often
| better than power. Quickly knowing what a tool can or cannot do
| is generally more productive and results in less politics (who
| hasn't worked on a project where person A keeps criticizing
| Group B for not knowing the framework can just do the thing
| they wrote, but it's not immediately obvious that it can?
| That's someone tearing down the team to boost their own ego. I
| don't like it. I liked it even less when I was the one doing
| it. Don't be That Guy, he's an asshole)
| dmix wrote:
| Any project that changes often is going to break often. When it
| involves dependencies that are constantly upgrading or being
| added it doubly adds risk of breakage.
|
| Test coverage and being conservative with adding new
| dependencies/concepts is always a valuable culture to develop
| for any frontend team working with junior devs. A good
| CTO/senior dev can clamp down on this behaviour.
| arcturus17 wrote:
| I agree with everything you say, but I'm in the camp that
| thinks that front-end is stabilizing.
|
| I feel many web projects can go a long way with something like
| NextJS, a few classic libs (eg, lodash/underscore/ramda), maybe
| a few libraries for handling data if you really need them. The
| design frameworks (MaterialUI, Tailwind, etc.) are also fairly
| stable.
|
| Perhaps that's one dependency too many for some?
| aristofun wrote:
| Breaking up with JavaScript frameworks by creating another
| JavaScript framework, really?
| 0xblinq wrote:
| C'mon, put a minimum effort to understand what it's all about
| before making useless comments.
|
| It is not a framework to organize your own JavaScript (like
| react, vue, etc). It is a framework so that you don't have to
| write JavaScript in the frontend.
|
| Of course it is written in JavaScript, because that's the only
| thing that can run on the browser.
___________________________________________________________________
(page generated 2022-12-10 23:00 UTC)