[HN Gopher] Building a web app with no framework
___________________________________________________________________
Building a web app with no framework
Author : javarome
Score : 118 points
Date : 2022-03-05 16:13 UTC (6 hours ago)
(HTM) web link (javarome.medium.com)
(TXT) w3m dump (javarome.medium.com)
| itronitron wrote:
| It's funny (not really) that this was written on a platform that
| requires accepting the site's 'privacy policy, including cookie
| policy'
| steve76 wrote:
| twomoonsbysurf wrote:
| gls2ro wrote:
| I really wish people will stop putting equally between
| Rails/Django and React or Svelte.
|
| Rails and Django are indeed web frameworks but you can easily
| have Rails with React or Django with Svelte.
|
| So the article includes them in the list of frameworks and then
| moves on to discuss a FE solution.
|
| If you want to replace Rails or Django with vanilla you need also
| backend API. Of course you can do that with vanilla Nodejs.
|
| But I dare you implement proper security from scratch.
| tmikaeld wrote:
| I'd say that it depends on what you're building and if you work
| in a team - there's so many components that would require a lot
| of work to create in vanilla if used together in the same app.
|
| Like menus, wysiwyg, tables (sorting, search, pagination), tabs,
| photo viewers, modular windows, accordions, form builder,
| notifications, cards, process sliders, color picker, ratings,
| spinners, stepper, uploader.
|
| Then binding all of that together.
| coffeefirst wrote:
| On personal projects, hell yes, this is my favorite way to work.
|
| Across a large team it's trickier. You need to teach and agree on
| all the patterns and organizing principles. I wouldn't attempt
| outside of very specific circumstances.
| Joeri wrote:
| Throwing out frameworks is throwing out the baby with the bath
| water. Frameworks manage component lifecycle in a way the browser
| by itself doesn't.
|
| The author seems to misunderstand why upgrades are forced on you
| by frameworks. It is not the framework that forces the upgrade,
| it's the build tools. If you compile JS or CSS anywhere in the
| pipeline, you need build tools (webpack, sass, babel, typescript,
| ng cli, ...) that support your current OS and node version, and
| that support the latest javascript and css syntax. While browsers
| have perfect backwards compatibility and would support using new
| javascript and css features on old codebases, the build tools
| won't allow it. Sooner or later you have to upgrade them, and
| this forces framework upgrades, which forces application codebase
| rework. You can delay this a bit by dockerizing the build tools,
| but I find this imposes more costs than benefits.
|
| You can either embrace the build tools and the upgrade treadmill
| they force on us, or you can choose a no build tools route. You
| can do the no build tools approach without a framework, but you
| don't have to. For example, back in 2008 I ported a PHP server-
| side rendered application to ExtJS 3 as an SPA. I maintained it
| until 2015 and then another team took it over which has kept it
| in active development to this day, and it's still on the exact
| same version of ExtJS 3. They've never had a good enough reason
| to upgrade it to another framework (mobile UI is done using
| native apps). You could never do this with an angular
| application, because the build tools would force an upgrade long
| before that time.
|
| If you want to follow this no build tools approach using a more
| modern framework, I made a version of Create React App that
| requires no build tools. It's just a cobbling together of a bunch
| of libraries floating out there that enable using react in this
| way, but it works. If you build your web app with that you will
| never have to upgrade the framework if you don't want to, which
| means you will never forcibly have to rework the application's
| codebase either, even if like that ExtJS app you continuously
| develop it for 15 years. https://github.com/jsebrech/create-
| react-app-zero
| coldtea wrote:
| > _Throwing out frameworks is throwing out the baby with the
| bath water._
|
| Yes. But it's a baby snake.
| Arnavion wrote:
| Unless the framework backports fixes (both bugs and CVEs) to
| the major version line you're using, you're forced to upgrade
| the framework to a newer major version line for the framework's
| sake, not the "build tools". And that upgrade will bring in all
| the other API changes that have happened in the new major
| version line.
| thunderbong wrote:
| I love ExtJs. In my opinion, their framework and backward
| compatibility is something other frameworks should strive to
| achieve. Currently, React, Vue, Svelte etc. are still at what I
| consider to be at ExtJs 3 level, where each component was
| defined in a single file. I wish they would open source their
| framework and really only on support subscriptions rather than
| the ridiculous license that they have, although I think that
| ship has long sailed. I just wish there was something even
| somewhat close to ExtJs in the open source world. Sadly, hardly
| any front end developers are even aware of it.
| zdragnar wrote:
| It has been a _long_ time since I looked at it, but (price
| aside) I seem to recall not being too interested in it
| because the actually complicated components (tables and such)
| had too many design and functionality constraints.
|
| Partly, this was due to designers living in their own dream
| worlds prior to development, partly to functionality
| limitations.
|
| When you have a green field to play in, buying into Extjs
| felt like sitting in a tiny pen, even if the grass was very
| nice.
| brimstedt wrote:
| I guess I'm the rare oldie that don't agree that the
| frontend/html was/is better without modern js frameworks / spa
| apps.
|
| Maybe because I built SPAs already pre -10 and I think that
| finally (as Vue entered the scene) even frontend development can
| be fun, structured, testable, etc.
|
| But the reason I write is this: When it comes to SSR, I still
| think node/js is absurdely slow.
|
| Compared to almost any java rendering backends, where I'd expect
| no more than 50ms response time/thread I see 200-300ms/instance
| of nodejs.
|
| What are your experiences? I'm I just doing it wrong :-)
| BenoitEssiambre wrote:
| fastify.io is supposed to be pretty fast. They do it by
| minimizing memory allocation. If you're not careful it's very
| easy to create tons of objects in javascript a common source of
| slowdowns.
| root_axis wrote:
| > _Compared to almost any java rendering backends, where I 'd
| expect no more than 50ms response time/thread I see
| 200-300ms/instance of nodejs._
|
| Have not had this experience. Our apps average about 40ms in
| typical traffic and 70ms under heavy load using SSR with react
| 16.8, and this is for a full render - in many cases we can
| serve static or interleaved cached components using ESI to SSR
| pages in ~20ms.
| brimstedt wrote:
| Thanks, in gonna have to do some digging :-)
|
| Which brings me to the next topic: profiling nodejs apps...
| Any tips there?
| human wrote:
| I use a framework even when it's not 100% necessary because it's
| easier to collaborate with other developers. The framework
| documentation and best practices helps a lot. What's more, 5
| years ago I started a simple app that didn't require a framework.
| Then it grew and grew and grew. Today I would need to rewrite it
| in a framework but it would be a huge job.
| drawkbox wrote:
| The only framework people need is standards at the browser
| level, javascript and the DOM (shadow dom now). Same with on
| the backend .NET/Java/Node, there is already a framework.
|
| Now for teams maybe you need to have a web framework but to say
| that makes things easier to understand is largely unproven,
| every project/product gets hairy over time, I have seen it more
| actually on Angular/React/Vue/Svelte etc sites than vanilla js.
|
| Long term, maintaining a web framework, especially after the
| hype is gone, is always seen as more verbose and bloat as well
| as a maintenance nightmare. One day your web framework that
| made it "simple" will be a complexity spot and maintenance area
| you will see as a chore where other devs don't want to deal
| with it and the true complexity will show. Maintaining a
| javascript only site long term is much, much easier than a
| framework. In many cases javascript is supported much longer
| than frameworks that had their hype cycle fade.
|
| In the meantime the abstraction of the complexifying web
| framework took you away from learning the actual simpler
| standards and framework, web standards, javascript and the
| parts of that actual framework.
|
| React for instance jumped ahead and front ran WebComponents and
| ShadowDOM, those are both part of the browser and standards
| now. The killer feature phase of React is over.
| xupybd wrote:
| I'm investing in the F# safe stack. So far it's amazing how
| quickly I can build something. It's also amazing how clean and
| readable I can get the code. But I feel like there is a horrible
| mess of complexity just under the hood. If any of the amazing
| maintainers choose to stop my app has it's legs cut off.
|
| That said I've found that with every other project I've worked
| on. I still maintain a B2B sales site on PHP 5.4 with Zend 1.1.
| There is no hope of migrating that anytime soon. Ironically that
| has no J's framework. The front end is such a mess and will never
| get the funding to clean up.
|
| I think building with tools that allow such a great developer
| experience might be worth it. However F# makes it hard to find
| developers to maintain it in the future.
|
| I hate the lack of longevity in our industry. I work with 30 year
| old CNC machines that are still supported by their manufacturer.
| I can't wait until our field gets that mature.
| JaggerJo wrote:
| We also use F# end to end (Fable + .NET). 3 years in I could
| not be happier.
| tasha0663 wrote:
| *lose
|
| "loose" rhymes with "goose" and is the opposite of tight.
| [deleted]
| pbreit wrote:
| It continues to boggle my mind how difficult it is to set up a
| simple crud app with user reg/logins, record creation, record
| search and list of records (ie, 90% of apps).
| shane_b wrote:
| the benefits of vanilla implementation fix the problems that come
| with lack of training. like not understanding the low level api
|
| training means so many things but in general, if it's not "how we
| do work here" then it's lacking at most orgs i've seen
| LAC-Tech wrote:
| I feel like people severely over-estimate the level of
| abstraction some frontend tools give you.
|
| Out of boredom once I went through the redux tutorial, and coded
| an alternate version with vanilla JS. My vanilla code was
| actually shorter, including the code needed to implement
| something like the observer pattern.
|
| JS in 2022 is a really powerful language, and the DOM APIs have
| improved tremendously. Now people will hit back with "well you'll
| just end up re-inventing a framework" - but do you really? You
| just write an app against the abstraction of the DOM, instead of
| the parallel abstraction of the react VDOM.
|
| I'm sure at a certain scale it makes a lot of sense to
| standardised on a framework so you can easily replace people who
| burn out after spending half their time updating libraries. But
| for smaller projects - I'm just not seeing it.
| xigoi wrote:
| One think I'm missing in vanilla JavaScript is reactivity.
| What's the simplest way to make it so that the page will always
| display the current value of a variable (or something
| calculated from the current value)?
| LAC-Tech wrote:
| Something like the observer pattern:
|
| https://en.wikipedia.org/wiki/Observer_pattern#JavaScript
|
| If you look at it from another angle, you might see that
| `setState` could take a function oldState => newState instead
| of a raw value. Then you have a `reducer` in the sense of
| redux.
|
| You could also just make the list of observers functions,
| instead of objects with the signal method.
|
| All easily done in about 20 LOC.
| veganhouseDJ wrote:
| This is why I just love Sveltekit. There is just not that
| much to even learn beyond vanilla JS.
| xigoi wrote:
| I once tried to learn Svelte, expecting to be able to write
| a simple webpage in HTML and JS and having Svelte make it
| interactive, but it asked me to clone a whole template
| repo. No, thanks.
| divbzero wrote:
| Proxy [1] is one way to do it using vanilla JavaScript.
|
| [1]: https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| eric4smith wrote:
| Wow. The author is speaking about Javascript front-end
| frameworks.
|
| I'm an old guy now, and I've rarely seen a need for a front-end
| framework. I know that sounds like heresy.
|
| I've never bothered to learn Angular, React, NextJS, Svelte or
| any of the alphabet soup named frameworks. Normal javascript
| works fine these days for a sprinkling of front-end
| interactivity. jQuery is not even necessary anymore.
|
| And with more recent technologies like Phoenix LiveView, there is
| very little need to use any of those front-end frameworks.
|
| Count me as old-fashioned, but very few apps really need those
| kinds of frameworks. They could mostly do without them.
|
| Frameworks are mostly necessary on the backend.
| nicoburns wrote:
| > And with more recent technologies like Phoenix LiveView,
| there is very little need to use any of those front-end
| frameworks.
|
| I think I'd argue that Phoenix LiveView _is_ a frontend
| framework. Albeit a non-traditional one.
| [deleted]
| holoduke wrote:
| Frameworks van be useful in any large dev project. It can bring
| structure. Things like routers, http request processors, object
| binding, ui components and many more.
| 6510 wrote:
| While I agree, I always use vanilla (never used jquery either)
| but I don't do opinions about things I'm not familiar with. No
| doubt all the framework research produced useful abstractions
| that we now have in js or should have.
| GordonS wrote:
| Another old'ish guy here, and I feel the same way.
|
| I have done a few projects using Knockout and Angular, and I've
| used Svelte a little too. My conclusion is that SPAs definitely
| have their place - but that place is in the minority, mostly
| for web apps with complex UI/UX.
|
| In SSR (Server-Side Rendered) projects (typically ASP.NET Core
| for me nowadays, but I've used others too), things are just
| _so_ much simpler, with fewer moving parts. A sprinkling of
| JavaScript is all that 's needed, and even then a lot is
| reusable between projects. And now IE has finally died, jQuery
| is no longer needed, and browser support for ES6 is good, even
| writing JavaScript is less miserable than it used to be.
| [deleted]
| robertoandred wrote:
| Having to refresh the page every time you make a change or
| open a modal is a terrible user experience.
| sidlls wrote:
| Watching widgets/components freeze after an interaction
| because of a poorly-handled race condition in the
| JavaScript, dropped or mis-handled/scheduled async
| requests, and inconsistent cross-component state management
| isn't any better. It's arguably worse, because now the user
| has to guess as to whether something is wrong with the
| application or not and then refresh anyway.
| bingo-bongo wrote:
| What makes it a terrible user experience?
| GordonS wrote:
| This is trivial with a sprinkling of JavaScript - our pages
| _do_ update as required after form POSTs, for example.
| YuukiRey wrote:
| https://sr.ht/ is faster than most SPAs I know and it
| refreshes the page a lot
| zdragnar wrote:
| Is it not simpler because the applications themselves are
| simpler? I mean, when you say that client frameworks like
| angular and svelte have their place with complex UX/UI
| interactions.
|
| Of course SSR is simpler- request in, send / receive from a
| database, markup out. It isnt anything to do with SSR- your
| domain is simpler.
| bob1029 wrote:
| I find deep joy in constraining my web development toolset
| these days.
|
| I remember what it was like to be faced with the task of
| building a new website from zero, and the temptation to reach
| out and consume other peoples' components/code/ideas. I don't
| know that you could actually master the art of vanilla web dev
| without first taking a ride on someone else's rollercoaster a
| few times.
|
| > Frameworks are mostly necessary on the backend.
|
| Sounds like I might be a double-heretic now...
| commandlinefan wrote:
| > I've rarely seen a need for a front-end framework
|
| I feel the same way about both front-end and back-end
| frameworks - or at least the sorts of things that call
| themselves frameworks. Struts was kind of useful in its time,
| but in the end didn't save you much effort _as code_. Usually
| when people talk about Java server side frameworks these days,
| they mean Spring, which is worse than useless, because it
| actively makes development harder.
| ravenstine wrote:
| > And with more recent technologies like Phoenix LiveView,
| there is very little need to use any of those front-end
| frameworks.
|
| Sure, if you choose to buy in to a _backend_ framework.
|
| I'm not knocking Phoenix, but it's a tradeoff. I'd rather be
| able to write the backend without a framework and use the
| framework where I want to spend the least amount of time
| figuring things out, which is usually on the frontend/GUI. But
| everyone is different.
| bizdatblyat wrote:
| black3r wrote:
| > Normal javascript works fine these days for a sprinkling of
| front-end interactivity. jQuery is not even necessary anymore.
|
| If you just need a sprinkling of front-end interactivity, you
| don't need a framework and you never needed it. If you're
| building a web application with lots of features, re-used
| components, complex data structures, etc., a framework helps
| you a lot. And the web today is full of complex web
| applications, since most of what used to be desktop
| applications 15 years ago are now web applications.
| austincheney wrote:
| https://github.com/prettydiff/share-file-systems
|
| That is my application that creates an OS GUI in the browser.
| Plenty of features with o framework.
|
| * Code size (on the front-end) 2mb unminified.
|
| * Load time in the browser (including state restoration)
| about 120ms.
|
| * The first version took 15 days to write from scratch.
|
| When people claim there MUST be a framework its clear they
| have no idea what they are talking about. It is clearly a
| case of Dunning-Kruger effect where they can compare their
| experience with frameworks on one hand... and they have
| nothing to compare it to, because its all they know.
| itronitron wrote:
| No, you still don't need a web UI framework for rich front-
| end interactivity. That assumes however that your developers
| know how to write a callback function.
| onion2k wrote:
| "You don't need a framework" assumes your developers will
| write code that operates with everyone else's code nicely,
| without accidently writing something that will be painful
| to remove in a year's time.
|
| Frameworks generally enforce a pattern where things are
| quite well encapsulated, don't pollute global spaces, don't
| mess with prototypes, and manage callbacks well. Code
| written by one person, or a group of well-organised
| experts, also does that, but as soon as you have a less
| talented team, or a couple of juniors who aren't being
| overseen because the seniors are too busy, things creep in
| to the code that have the potential to blow up later.
| Frameworks help your team avoid those footguns (and
| introduce some different ones, but at least they're usually
| easier to manage).
| sidlls wrote:
| This is true. The question is whether it's necessary or good
| (for consumers, for businesses, for the software engineering
| profession, etc.).
|
| The answer is subjective and lies within a spectrum, surely,
| but I tend toward the negative end of that spectrum. I don't
| believe the complexity in web applications is good (for
| anyone, except possibly browser makers, front-end developers
| and framework makers) and therefore it's not really
| necessary.
|
| The browser today is mostly a terrible, inefficient, and
| limited functionality VM over the host OS, and that provides
| an inconsistent user experience across devices and even minor
| browser versions. What I've seen over the last 20 years of my
| lifetime has been an unfolding of a sort of tragedy of the
| commons in this context. We have a seeming endless supply of
| computational resources, "everyone" wants to exploit it in
| the most ruthless way possible, and it has lead to a
| deplorable state in the industry where bad practices and
| inefficiencies are not only tolerated but sought (for resume
| building, fast releases, whatever), and ultimately it results
| in terrible abuse/misuse of the resources we have.
| ozim wrote:
| It is necessary and good.
|
| We are re-implementing complex "excel apps" into web
| applications. Amount of money I have seen lost because
| people were using different versions of excel sheets that
| were not up to date is staggering.
|
| Users expect full interactivity and instant calculations as
| they change values (just like in excel), doing it with
| "posting forms to back-end and recalculating" will not sell
| at all because it will be worse UX than excel. Having
| complex calculations over multiple fields require use of
| framework because making it with vanilla js is just pain
| with no MVVM and observables and two way bindings.
|
| Then of course if you have web app you have one database
| all your employees are working on and all price items can
| be updated easily in some admin panel for every new
| customer.
| 9wzYQbTYsAIc wrote:
| > Amount of money I have seen lost because people were
| using different versions of excel sheets that were not up
| to date is staggering.
|
| Similar opportunity losses can be found through not
| keeping npm libraries up-to-date or through not doing
| full refactoring when there is a mainline change in a
| framework's coding styles.
|
| .NET, React, and Angular all suffer from that problem, to
| this day, in regular enterprise, and I'm sure Java does
| too.
| sdoering wrote:
| > Amount of money I have seen lost because people were
| using different versions of excel sheets that were not up
| to date is staggering.
|
| Isn't that a processual problem? An organizational and
| structural problem?
|
| I have seen the same with Google Sheets as with Excel. I
| know Excel isn't liked in a lot of tech circles but I
| personally think MS came a long way with it.
|
| But yes - it can't solve organisational problems.
| ozim wrote:
| Yes but as my experience shows process/structural
| problems are quite easily solved with software.
|
| Then if someone has problem with process you tell them
| "it is software that requires it" and they comply.
|
| Organizational problems are mostly problematic to
| translate to software and make projects die. Because if
| company is not organized, they won't have possibility to
| organize their requirements which will lead to problems.
| HNHatesUsers wrote:
| zdragnar wrote:
| One established business and another startup I worked at
| absolutely thrived explicitly because we built web
| applications rather than native ones.
|
| In the first case, we kept it narrowly tailored to two
| pages that absolutely needed that level of interactivity.
| In the second, requiring customers' employees to install an
| app on their phones would have been a non-starter during
| the sales process, and the lack of an app was a major
| selling point for others.
|
| YMMV- oddly enough, both made use of the canvas element in
| critical parts (these were not simple CRUD websites).
| 7sidedmarble wrote:
| Well not everyone is building websites on the web. Building
| an app for the web is not some horrible thing. Google docs,
| sheets, etc are all perfect examples of the kinds of apps
| suited to the web: ones that benefit from the ability to be
| accessed from anywhere on any device, and encourage
| collaboration.
| [deleted]
| sidlls wrote:
| We had this functionality before web apps were a thing.
| I'm not going to claim it was some golden era/glory days
| in a bug-free, seamless cross-device nirvana, but it's
| not like it was a wasteland, either. And for all the
| promise of cheaper, better apps that the webapp paradigm
| has been suggested to bring, we still pay a lot for
| armies of developers to write this stuff, and it's almost
| uniformly worse in both quality and feature completeness.
| FpUser wrote:
| Hear hear. We have zero problems not using web frameworks for
| our SPAs. Just a couple of libs and we write web components
| here and there to solve particular tasks when needed.
|
| Using the power of modern JS I fail to see the value of things
| like React. Maybe it has for the orgs of FB size but I do not
| operate at that level.
|
| My backends are semi-stateful C++ servers with no frameworks
| either. Just some libs and std.
| jesselawson wrote:
| My favorite front-end framework is [VanillaJs](http://vanilla-
| js.com/).
| croes wrote:
| Is it open source?
| cto_of_antifa wrote:
| throwaway_4ever wrote:
| removed
| teg4n_ wrote:
| That is literally what the site is about.
| [deleted]
| pbreit wrote:
| There's a growing school of thought of the exact opposite: end
| users expect the UX that frameworks deliver and the back-end is
| simply an API in front of a DB.
| ozim wrote:
| I don't know if it is growing thought of school. I think it
| is just obvious direction.
|
| Take for example excel and if you change value in one cell
| you get all calculations in sheet updated automatically.
|
| Implement something like that without a framework and only
| plain js with dozens of fields having dependencies on each
| other, good luck :)
|
| Implement something like that with cute "recalculate" button
| on the bottom of 3 screen scroll and no one will use your
| solution.
| [deleted]
| ralusek wrote:
| > I've rarely seen a need for a front-end framework. I know
| that sounds like heresy.
|
| No it sounds like the comments on every post on HN remotely
| related to JS.
|
| > I've never bothered to learn Angular, React, NextJS, Svelte
| or any of the alphabet soup named frameworks
|
| That makes your opinion definitionally uninformed. If you had
| bothered to learn any of them, you would see that they have
| many benefits. Nobody is saying that you _need_ any of them,
| but they are very useful.
|
| The single greatest advantage to using any of the frameworks,
| however, is that they provide _a_ relatively definitive way of
| solving any of the problems that you _will_ have to solve,
| building an SPA. Routing, caching, state management,
| reactivity, inputs...There is no way around solving these
| problems, so you 're either going with what they've got, or
| reinventing the wheel. But by reinventing the wheel, you're
| probably going to do a worse job than the team that has spent
| years solving these problems, and more importantly, you're
| losing access to a definitive way of doing things that you (and
| others) can refer to.
|
| And that's the real kicker, is working with others. I worked as
| a contractor for years, and I can tell you the ease of jumping
| on a project using a front end framework vs a home baked JQuery
| or vanilla solution was practically immeasurably vast. Even
| jumping on a project using a framework I'd never heard of, but
| still had documentation and an online community, would have me
| up and running within a day or two at most.
| virtualwhys wrote:
| Your entire argument is predicated on building an SPA; if you
| don't need an SPA then you de facto do not _need_ a frontend
| framework (which is what the OP is implicitly saying, do as
| much as possible server-side).
|
| Now, saying that, there is something to be said for
| separating UI from the backend. Yes, it adds ( a great deal
| of) complexity compared to server-side applications, but the
| reactive programming model is quite powerful, and useful even
| if you could build the application entirely on the server.
|
| And obviously if you do need an SPA (e.g. wrapping WebView
| for iOS/Android) then you don't have a choice, or if you do
| you'll be reinventing the wheel, poorly.
| onion2k wrote:
| _Your entire argument is predicated on building an SPA_
|
| There are frameworks that don't deliver an SPA - Next,
| Nuxt, Remix, etc. They also do a lot of work to remove as
| much frontend JS as they can, and more effort is going in
| to that delivery architecture at the moment. The idea is
| that devs write React or Vue based pages, and the framework
| figures out what the page actually needs and delivers only
| that code to the user. Routing is done on the server. They
| work very well.
| ipaddr wrote:
| The ease of working with a react version from 2015 vs jquery?
|
| jQuery is very easy to understand and edit in notepad. It
| doesn't require getting the right npm version / maintaining
| dependencies of specific package versions that may be
| depreciated.
|
| Routing is better handled in the backend.
|
| Backend frameworks have been around longer. By treating them
| as an api only you end up reinventing the wheel. Caching,
| state management, reactivity have been handled in the backend
| for awhile.
| cto_of_antifa wrote:
| dewey wrote:
| > Count me as old-fashioned, but very few apps really need
| those kinds of frameworks. They could mostly do without them.
|
| Probably true if you look at it in a vacuum. I think if there's
| a big team a framework is certainly helpful to keep thing's
| organized and the borders a bit more defined. You also benefit
| from a community, best practises and documentation about how
| things should be structured and work.
| mirekrusin wrote:
| Frameworks are mostly necessary on the backend.
|
| ...not really, we're running high stake trading application
| (constellation of services) without framework and it works
| really well. Shallow/no-dependencies is great. We've been
| throwing complexity at it for 4 years+ and there is no fatigue,
| things are crafted to fit the purpose, it works, really, really
| well. I get personal satisfaction from removing code necessary
| to do the job.
| amelius wrote:
| Modern frameworks help to separate state from code. And also to
| reduce the amount of work in case of a state update.
|
| For large applications (or small ones that may grow large one
| day), you absolutely need a framework.
| JakeAl wrote:
| I feel the same about single-page applications. Give me good
| old fashion static HTML and CRUD database calls on a single
| production server with a back-up server, development server and
| live-test mirror server and using 1995 hardware it could handle
| 250K simultaneous users easy. Things have gotten insanely
| bloated and big-tech dependent with a huge price tag to build
| and maintain.
| domenukk wrote:
| I've seen projects like this in the past - either you have
| skilled people and use a strict CSP from the start, or the
| footguns of dynamiically crafting objects ultimately leads to a
| bunch of XSS that (probably) wouldn't have happened with mature
| frameworks
| slim wrote:
| sometimes XSS is not a threat
| TruffleLabs wrote:
| Any one saying they are not using a framework is not being honest
| with themselves.
|
| They may not be using a formal published framework like those
| mentioned in the article, but they have a personal set of tools,
| techniques, and methods on which to design and build things.
|
| To maximize flexibility, minimize dependency, & maximize
| performance means you have to use some set of tools & methods
| (aka framework) that have been designed to reach those goals.
| Sateeshm wrote:
| Yeah, vanilla js for large projects only makes sense if you
| don't agree with with the way existing frameworks are doing
| things, because you are going end up creating a framework for
| the project anyway.
| kilroy123 wrote:
| Yup back in the day when I first started doing frontend work in
| ~2009. Everything was vanilla JS / jQuery.
|
| What did we end up with? A custom build framework.
| jmull wrote:
| Yup^2. It has ever been thus.
|
| I started in the early '80s and of course built up a personal
| collection of BASIC routines to solve the common problems and
| get a quick start on the games I made. LOL, I still have to
| stop myself from calling the symbol to reference the upper
| left of a drawing surface "L".
|
| I got to pick the brains of my Mother (RIP), who got her
| start in the '50s, and it was the same. So between us we have
| three long generations.
|
| I don't really have illusions about these common frameworks.
| They are so full of drawbacks and unnecessary complexities,
| and you need to understand them pretty well to use them
| effectively in production for even slightly successful
| projects.
|
| But they solve many of the problems you'd have to solve
| anyway, and in a way that may already be documented and maybe
| even well understood by others. Unless you're really going
| for something bespoke/unique/different, the advantages are so
| large it's usually worth it.
|
| I'm starting a project for a client now, and I'm using a
| popular framework of today... _because_ it's a popular
| framework of today. E.g., if it's successful, I don't want to
| be making tweaks to this 5 or 7 or 10 years from now, and if
| I'm using a popular framework, maybe I won't have to. (And if
| it's not successful, it doesn't matter what I used.)
| gspr wrote:
| I code solely for the CLI. Python, C, C++, Rust. Recently I
| thought I'd learn some web programming, especially since it's no
| longer tied to writing JS. I gave up when it seemed there's
| seemingly not a single text that describes how to start simple!
|
| Like: I have a compiler that can target wasm32-unknown-unknown,
| how can I write a hello world in a language that said compiler
| compiles? Instead I'm presented with a barrage of frameworks and
| magical "bundlers". Help!
| forgotmypw17 wrote:
| I've also written a framework while trying to not use a
| framework.
| jmull wrote:
| This is the "drop the mic" comment of the thread.
| BenoitEssiambre wrote:
| The article links to writing your own router in less than 100
| lines of javascript. This is based on outdated code supporting
| old browsers like IE11. For modern browsers, I was able to reduce
| it to less than 50.
| [deleted]
| tillinghast wrote:
| Totally get it, huge not-a-fan of the endless JS framework race.
| _However._
|
| - Constructing a House Using Only Wood Glue
|
| - Removing That Appendix Yourself
|
| - Boiling an Ocean with Two Sticks
|
| - Granting Your Own Wishes Without a Genie
|
| - Hosting Your Own Funeral
| timmg wrote:
| When I'm writing web stuff "for fun", I try to avoid frameworks.
| It seems a lot more enjoyable.
|
| When I do, though, I use vanilla Javascript. I'd really love to
| do framework-less Typescript. In theory, you can, I guess. But it
| is all wrapped up in NPM. Which, for some reason, I just don't
| like.
|
| NPM-less Typescript seems like it would be pretty cool.
| have_faith wrote:
| That's a lot of words to extol building your own framework for
| each project you start. I know the articles ends with saying this
| isn't what is being suggested... but it looks like it.
|
| With regards to the stated drawbacks of frameworks:
|
| > comply with their API
|
| Is a fair point I guess. It's also the obvious tradeoff that
| everyone is willingly accepting. It also isn't strictly true
| either In most frameworks, like React, there are escape hatches
| to do things however you want. I've written React components that
| hand over control of the rendered element to some pure JS code to
| do some animation with a library that doesn't speak React for
| example.
|
| > upgrades are effectively forced
|
| I guess so. These updates often come with perf improvements, new
| features and only rarely do they remove existing API's. Not
| having to maintain an impromptu custom framework means someone
| else is focusing on optimising for me while I focus on business
| logic.
|
| > train to learn how they work
|
| Isn't this exactly the same as bringing in a new developer to
| work on your custom web app build that does everything
| differently to everyone else? he has to learn your strategies for
| routing, caching, state propagation, etc, and has no external
| resources to help him.
|
| > compromise with the drawbacks implied by delegating control
|
| I think this is a good point for web apps with a very high
| performance requirement. I don't see the problem with almost
| everything else though.
|
| > lose skills. A number of developers either don't know much
| about the lower-level APIs (because they always used the
| framework layer instead) or live in the past
|
| This has been true since before all of the big web app frameworks
| became popular. I don't see the frameworks themselves being
| responsible for lazy developers.
| thrashh wrote:
| I wouldn't call React a framework personally. To me it's a
| library like moment.js or ramda.
| have_faith wrote:
| React is a sort-of-library that exposes an API to plug in the
| missing pieces to produce a framework. OP of the article
| would probably actually like it. Want to write your own
| routing or state management? by all means go ahead.
| simonw wrote:
| I know the React team like to claim that it's a library, not
| a framework, but I don't buy that at all.
|
| My definition of a framework is code which defines the
| architecture of the rest of your application.
|
| React as practiced in the real world absolutely does this.
| Theoretically you could plug it in as just the library that
| does the templating, but I've never seen a real-world
| codebase for which that appears to be true.
|
| I'm ready to be convinced otherwise!
| mikeryan wrote:
| I was on team "React is a Library" but for the most part
| that changed when the hooks and context API were added. The
| addition of those, relatively simple, tools made it
| possible to not need the additional state management
| libraries like Redux/MobX etc that, up until then, were
| necessary add-ons to manage state and data. This made React
| more of a full Framework in my opinion.
|
| That being said React can still be dropped into a
| relatively static page to add small bits of interactivity.
|
| So at this point React seems to span both Framework and
| Library depending on the use case.
| optymizer wrote:
| React is a framework, not a library.
| LAC-Tech wrote:
| In every react project I've worked on, the majority of the
| business logic was written inside components (the old "code
| behind" anti-pattern from WinForms days), and about half the
| files had the extension "jsx" or "tsx". It also required the
| use of a react specific browser extension to debug
| effectively.
|
| React is a de-jure library, but a de-facto framework.
| boredtofears wrote:
| React defines the shape of most of the code in your code base
| in a way that neither moment.js or Ramda does. You can call
| it a library, but it sure quacks like a framework.
| tashoecraft wrote:
| I'd call it both. There's the use case of adding small react
| components sprinkled through an application, in this case
| it's a library.
|
| Then there's the use case of having everything be a react
| component, and you use lots of react specific libraries, and
| a react router, react form handler, etc etc. that's react the
| framework.
| shane_b wrote:
| > Isn't this exactly the same as bringing in a new developer to
| work on your custom web app build that does everything
| differently to everyone else? he has to learn your strategies
| for routing, caching, state propagation, etc, and has no
| external resources to help him.
|
| it does seem that way. i'd add that even with established
| technologies, a company should have a set way to do stuff that
| is trained internally. frameworks et al frequently have
| multiple strategies or you want to extend a framework
| primitive.
| ozim wrote:
| You overestimate knowledge retention.
|
| At one point there is a new hire who instead of learning why
| and how stuff was done starts overdoing everything because
| "previous people were shitty developers".
|
| You will have easier time hiring people with standard stack
| as well, no one wants to work on hodgepodge of code where
| some dev 2 years ago did something and left never to be found
| again. Developers don't want to invest in some magic stack
| because it will be easier for them to switch jobs if they
| keep doing Angular/React.
|
| If someone would be claiming he was building web apps without
| frameworks I assume he was not working in teams or at least
| not in teams of big companies. Which would be a red flag for
| me.
| shane_b wrote:
| i don't think building your own framework is a good idea.
| react still has plenty of possible patterns to decide
| between even after making the decision to use it. a team
| should have decided upon ways to do stuff even inside of a
| framework/technology/language.
| ozim wrote:
| I agree with all points in comment and would add:
|
| - frameworks forcing updates is good, your custom code still
| having that XSS for 20 years you don't even know is liability
| not a "saving of money"
|
| - frameworks are bringing XSS protections, navigation fixes, do
| a lot of things better than would be done by random devs from
| scratch
|
| - loosing skills is just Plato saying "if kids start writing
| things down, their memory will deteriorate" or people who pride
| in writing SQL by hand that ORMs are bad and I saw enough of
| "proud SQL writers" making more problems for the project than
| helping and I still know how to write SQL and the same I could
| use JavaScript browser API by reading some documentation if I
| need to
| ng12 wrote:
| Yeah, count me out. This is the world we used to live in when all
| we had was jQuery. It was miserable and no medium blog will ever
| convince me to pine for those days.
| eyelidlessness wrote:
| Funny enough, just yesterday I did a spike into introducing one
| of the mentioned frameworks (SolidJS) into a no-framework legacy
| app, and I'm almost certain it's the right move. The app is over
| a decade old, with a variety of different approaches and the
| tangled data flow that you'd probably expect of that... despite
| effectively having evolved an informal framework internally.
| Solid is a perfect fit for a couple reasons:
|
| 1. Its "components" compile away to plain DOM operations, so it's
| well suited for a gradual transition story: existing behavior can
| wrap and be wrapped by new/replacement components without a need
| to reconcile between them.
|
| 2. Its reactive state model fits the app's requirements very
| well, particularly in terms of needing to maintain two related
| but quite different representations of the data in tandem.
|
| Solid's performance being about as near to vanilla JS as possible
| is just bonus points to me, but certainly will ease concerns on
| my team.
| ericsilly wrote:
| I've been working on an SPA built with no frameworks, a lot of
| WebComponents, and almost zero 3rd party code, and it's
| fantastic. Package managers and frameworks have a lot of holdover
| momentum from an era when they were far more necessary, and I
| think a lot of teams and individuals have unacknowledged PTSD
| that prevents them from stripping out these legacy comfort &
| safety nets. Plus, it's likely also a comfort for managers to
| believe a team is working within some sort of opinionated 3rd
| party-supplied guardrails.
| divbzero wrote:
| I am proponent of avoiding frameworks wherever possible.
|
| How did you go about incorporating structure and patterns that
| are typically enforced by frameworks? Was Web Components a big
| piece of that or were there other major patterns you
| established?
| drawkbox wrote:
| The biggest crimes of web frameworks is they take you away into
| abstraction land away from the actual standards and they
| complexify simplicity, all of that under the guise of being
| more "standard" and more "simple". It is one of the greatest
| lies ever sold.
|
| I remember how .NET WebForms and lots of Java boilerplate
| frameworks did that early on, or browsers breaking standards,
| they wanted developer lock-in just like web frameworks of
| today. They wanted to keep developers dumb by being "simple" as
| long as you stay in their walled garden where they handle the
| standards. No thanks...
|
| I have been developing javascript for decades and I actually
| liked the original less Java like boilerplate of the previous
| iterations, and you can still do that. The people that push
| frameworks aren't always trying to make things more simple,
| they want control, lock-in and domain ownership. The last tool
| to really simplify in javascript was jquery and most of that is
| browser level now including selection the killer feature of
| jquery across all those document.all/document.layer days of
| pain. Those days are over, simplicity is being complexified
| now.
|
| Tools like jquery and even Flash or other plugins were platform
| pushers that got the web to the place we have now which is
| better than ever for web standards, yet we have all these
| bloated frameworks on top now. In a way it is a bit like the
| xkcd comic with so many standards, just to not do javascript
| people built thousands of frameworks on top to "simplify" the
| standards that are simple now.
|
| While web frameworks may have been needed for a time, and in
| certain team based scenarios, they are a crutch, a maintenance
| problem long term, they take actual standards out of experience
| and the worst is they make the simple complex. Web frameworks
| have become the DLL hell or dependency deepend that used to be
| used to attack other platforms. .NET and Java have less bloat
| now and are moving more standard, while javascript web
| frameworks only pretend to.
|
| The web standards of today are amazing and take away the nee
| for frameworks today: from templating to html templates [1],
| vanilla javascript with classes [2] and async [3] and better
| api access like fetch [4] and browser support for vdom with
| shadow dom [5], components with WebComponents [6][7], css now
| with lots of additions like variables [8]
| transitions[9]/animations[10], flex and media queries,
| canvas/svg/etc for interactivity, and so much more. There is
| little need to use frameworks except to sell books and
| conferences and keep developers locked in.
|
| As developers/engineers, the job is taking complexity and
| simplifying, ask yourself if your framework abstraction is
| doing that above actual standards that is a pain long term to
| maintain. Web frameworks were supposed to work together, they
| are now behemoth monoliths that limit dynamic and fluid systems
| that scripting are supposed to bring. People went out and made
| a scripting language for glue into Java boilerplate...
|
| In areas like targeting a certain javascript ECMA version or
| polyfills, those are still worthy, the other pile of verbose
| bloat abstraction that is there is just that, a pile of
| "verbloat". "Verbloat" is a new word to define frameworks of
| today sold in as small helpers to replace jquery, that have
| grown to the size of dev lock-in tar pits. No developer in
| their right mind would use this for products/projects they
| control unless they have to at this point.
|
| Basically this video summarizes the absolute unnecessary
| adventure of web frameworks and provides some comic relief to
| the absurdity of it all. [11]
|
| [1] https://caniuse.com/template
|
| [2] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| [3] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
|
| [4] https://developer.mozilla.org/en-
| US/docs/Web/API/Fetch_API/U...
|
| [5] https://caniuse.com/shadowdomv1
|
| [6] https://caniuse.com/custom-elementsv1
|
| [7] https://developer.mozilla.org/en-US/docs/Web/Web_Components
|
| [8] https://developer.mozilla.org/en-
| US/docs/Web/CSS/Using_CSS_c...
|
| [9] https://developer.mozilla.org/en-US/docs/Web/CSS/transition
|
| [10] https://developer.mozilla.org/en-US/docs/Web/CSS/animation
|
| [11] https://www.youtube.com/watch?v=Uo3cL4nrGOk
| 9wzYQbTYsAIc wrote:
| The problem of not using a framework, however, is that as the web
| app scales, you'll end up needing to build a framework.
| [deleted]
| AtlasBarfed wrote:
| You know what should be practically illegal? Foisting yet another
| web framework without a standardized reference implementation. A
| sort of rosetta stone or PLEAC for web frameworks.
|
| - login
|
| - registration
|
| - db views / grids
|
| - forms
|
| - api invocation
|
| - navigation
|
| - menus
|
| - tabs
|
| - lightbox
|
| - forum
|
| - wiki
|
| - ecommerce
|
| etc, etc, etc... I'm leaving out probably about 50 things.
|
| Yeah, not just a "widget zoo" or something similar.
|
| The reference implementation should be pretty big. Annoyingly
| big. It shouldn't be easy. Don't foist your web framework and
| push it until you do the work to show how it does and does not
| work well. It should have four or five levels of complexity in
| menus, forms, grids, navigation, tabs, and the like.
|
| Because at this point there are likely several thousand web
| frameworks. Java alone likely has 200 since the old days of
| Struts.
___________________________________________________________________
(page generated 2022-03-05 23:00 UTC)